Loading ...
Sorry, an error occurred while loading the content.

Re: [decentralization] VoIP/P2P/Zennstrom

Expand Messages
  • Wes Felter
    ... The problem with iChat is that it s using AIM for identity/lookups; apparently it won t connect to anything if you don t have an AIM account. (I think I am
    Message 1 of 16 , Jul 31, 2003
    • 0 Attachment
      On Thursday, July 31, 2003, at 05:51 PM, brandon@... wrote:

      >> Yay, it's not based on SIP so there will be no interop. :-(
      >>
      >> Quick, someone hack together some open source DHT, pet names, and SIP
      >> components.
      >
      > Okay Wes, I'll do this if you will make it interop with the iChat
      > voice chat thing.
      > I already have a DHT and pet names, so SIP was the next logical step.

      The problem with iChat is that it's using AIM for identity/lookups;
      apparently it won't connect to anything if you don't have an AIM
      account. (I think I am the last person on earth without an AIM account.)

      Wes Felter - wesley@... - http://felter.org/wesley/
    • Wes Felter
      http://www.skype.com/ The claimed advantages over stuff like FWD are better-than-phone quality (see http://wmf.editthispage.com/2003/08/07 ) and end-to-end
      Message 2 of 16 , Sep 2, 2003
      • 0 Attachment
        http://www.skype.com/

        The claimed advantages over stuff like FWD are better-than-phone quality
        (see http://wmf.editthispage.com/2003/08/07 ) and end-to-end hard
        crypto.

        --
        Wes Felter - wesley@... - http://felter.org/wesley/
      • Robert Welbourn
        Well, the FWD service as such is really just a SIP signaling relay. The quality of the call is down to the endpoints and the intervening network
        Message 3 of 16 , Sep 2, 2003
        • 0 Attachment
          Well, the FWD service as such is really just a SIP signaling relay. The
          quality of the call is down to the endpoints and the intervening network
          characteristics. There's nothing to stop the endpoints using a wideband
          codec such as G.722.x, which will automatically give you better perceived
          voice quality. There are SIP phones out there that claim to support
          wideband codecs, and the Windows RTC Client also supports G.722.1.

          I wonder how Skype are handling NAT -- is this really P2P or are they
          bouncing the VoIP media stream off a relay with a public IP address?

          Rob

          (robert at welbourn dot com)

          At 11:19 AM 9/2/2003 -0500, you wrote:
          >http://www.skype.com/
          >
          >The claimed advantages over stuff like FWD are better-than-phone quality
          >(see http://wmf.editthispage.com/2003/08/07 ) and end-to-end hard
          >crypto.
          >
          >--
          >Wes Felter - wesley@... - http://felter.org/wesley/
        • brandon@blanu.net
          ... I don t know about Skype, but I know that Packet8 uses some mysterious technology to allow NAT-to-NAT calls without a relay. The details of how this works
          Message 4 of 16 , Sep 2, 2003
          • 0 Attachment
            > I wonder how Skype are handling NAT -- is this really P2P or are they
            > bouncing the VoIP media stream off a relay with a public IP address?

            I don't know about Skype, but I know that Packet8 uses some mysterious technology to allow NAT-to-NAT calls without a relay. The details of how this works are
            unclear as this is the proprietary part of their service and phone. They swear they are 100% pure SIP other than this magical NAT circumvention.
          • Julian Bond
            ... This is something that bothers me about Skype and actually bothers me about Kazaa as well. Something like a VoIP client really needs to use public
            Message 5 of 16 , Sep 3, 2003
            • 0 Attachment
              Robert Welbourn <robert@...> wrote:
              >I wonder how Skype are handling NAT -- is this really P2P or are they
              >bouncing the VoIP media stream off a relay with a public IP address?

              This is something that bothers me about Skype and actually bothers me
              about Kazaa as well. Something like a VoIP client really needs to use
              public protocols. If it doesn't it may still be successful but we will
              end up getting dragged into the same mess as IM with it's lack of
              interop between services and the current attempts by all the commercial
              parties to hold on to their own patch by what ever means possible.

              The similarity with Kazaa is that I'm hugely impressed with what they've
              done, but irritated that it's so closed. I really thought we'd see some
              reverse engineered clients and servers that use the Kazaa network by
              now. Napster -> Opennap/napigator was a much shorter time than
              Kazaa -> Now, wasn't it? Or have I just missed the apps and everyone
              else knows about them?

              --
              Julian Bond Email&MSM: julian.bond@...
              Webmaster: http://www.ecademy.com/
              Personal WebLog: http://www.voidstar.com/
              M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433
            • Michael Iles
              There s GiFT (Gnu Isn t Fast Track), who reverse-engineered the protocol fairly quickly but have since been locked out. (The FastTrack network started
              Message 6 of 16 , Sep 3, 2003
              • 0 Attachment
                There's GiFT (Gnu Isn't Fast Track), who reverse-engineered the protocol
                fairly quickly but have since been locked out. (The FastTrack network
                started requiring centrally-delivered encryption keys.)

                I haven't followed GiFT much, but it appears to have morphed into a
                general-purpose file-sharing platform that interfaces with the 'Open FT'
                network (modeled after the closed FastTrack network) and also the
                Gnutella network.

                Regarding Packet8's 'magic'... could it be something like the next-port
                tricks that are possible with some NATs, i.e. A and B use a relay to
                co-ordinate their timing and port numbers so they each initiate
                connections to the other's NAT at the same time on port+1 and rely on
                the fact that the other's NAT will (probably) assign the next sequential
                port to the outgoing connection. If it works, A and B can then talk
                directly even though they're mutually NAT'd. What else could it be?

                Mike.

                -----Original Message-----
                From: Julian Bond [mailto:julian_bond@...]
                Sent: September 3, 2003 3:13 AM
                To: decentralization@yahoogroups.com
                Subject: Re: [decentralization] Skype (was VoIP/P2P/Zennstrom)

                Robert Welbourn <robert@...> wrote:
                >I wonder how Skype are handling NAT -- is this really P2P or are they
                >bouncing the VoIP media stream off a relay with a public IP address?

                This is something that bothers me about Skype and actually bothers me
                about Kazaa as well. Something like a VoIP client really needs to use
                public protocols. If it doesn't it may still be successful but we will
                end up getting dragged into the same mess as IM with it's lack of
                interop between services and the current attempts by all the commercial
                parties to hold on to their own patch by what ever means possible.

                The similarity with Kazaa is that I'm hugely impressed with what they've

                done, but irritated that it's so closed. I really thought we'd see some
                reverse engineered clients and servers that use the Kazaa network by
                now. Napster -> Opennap/napigator was a much shorter time than
                Kazaa -> Now, wasn't it? Or have I just missed the apps and everyone
                else knows about them?

                --
                Julian Bond Email&MSM: julian.bond@...
                Webmaster: http://www.ecademy.com/
                Personal WebLog: http://www.voidstar.com/
                M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433

                To unsubscribe from this group, send an email to:
                decentralization-unsubscribe@egroups.com

                Announce or discover P2P conferences on the P2P Conference Wiki at
                http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences

                Your use of Yahoo! Groups is subject to
                http://docs.yahoo.com/info/terms/
              • Clay Shirky
                David Beckemeyer of Earthlink says of skype, from another list: Interesting. But since they apparently went with proprietary protocols it looks like they will
                Message 7 of 16 , Sep 3, 2003
                • 0 Attachment
                  David Beckemeyer of Earthlink says of skype, from another list:

                  Interesting. But since they apparently went with proprietary
                  protocols it looks like they will not be interoperable.

                  One huge advantage of going with a SIP-based service (or running
                  your own SIP-based service) is that you have interoperability
                  across providers. We have this today, where users on FWD,
                  IPTEL.ORG, and SIPhone, among others, can all talk to each other,
                  as well as (in most cases) users on a generic or home-grown SIP
                  network.

                  This is the key difference between the VoIP we saw all these
                  years, all proprietary, closed, systems, and the future of VoIP.
                  Other than the fact that there are more broadband users now than
                  in 1996, VoIP is mostly the same as it was then, except that now
                  SIP is mature enough to enable real-world interoperability, which
                  is something we have never had before (don't get me started with
                  H323). SIP isn't a technological wonder, but it doesn't have to
                  be, any more than HTTP had to be a technological wonder (which it
                  wasn't, especially HTTP/0.x, yet look what it achieved).

                  Skype brought a knife to gunfight, IMHO.
                • brandon@blanu.net
                  ... Well my box arrives on Friday, so I ll let you know.
                  Message 8 of 16 , Sep 3, 2003
                  • 0 Attachment
                    > Regarding Packet8's 'magic'... could it be something like the next-port
                    > tricks that are possible with some NATs, i.e. A and B use a relay to
                    > co-ordinate their timing and port numbers so they each initiate
                    > connections to the other's NAT at the same time on port+1 and rely on
                    > the fact that the other's NAT will (probably) assign the next sequential
                    > port to the outgoing connection. If it works, A and B can then talk
                    > directly even though they're mutually NAT'd. What else could it be?

                    Well my box arrives on Friday, so I'll let you know.
                  • Robert Welbourn
                    Ah, yes, brokered UDP traversal of a NAT. Bryan Ford of MIT describes this here: http://www.pdos.lcs.mit.edu/~baford/nat/draft-ford-natp2p-00.txt and here:
                    Message 9 of 16 , Sep 3, 2003
                    • 0 Attachment
                      Ah, yes, brokered UDP traversal of a NAT. Bryan Ford of MIT describes this
                      here: http://www.pdos.lcs.mit.edu/~baford/nat/draft-ford-natp2p-00.txt and
                      here: http://www.pdos.lcs.mit.edu/~baford/nat/. The technique requires the
                      NAT devices keep a constant mapping between public and private address/port
                      pairs, and do *not* allocate new port mappings for different
                      destination/port pairs. (This is sometimes known as "full cone NAT".)

                      SIP has various modifications to allow a session description to distinguish
                      between public and private addresses, so that it will effectively broker
                      the direct connection between the two endpoints. Presumably Packet8's
                      service does this. As for Skype, presumably their proprietary call
                      signaling protocol does something equivalent.

                      The alternative is to use something called a Session Border Controller,
                      which sits in the public address space, does address mapping and acts a
                      relay for the media stream. However, these devices are not cheap
                      (requiring as they do a great deal of packet forwarding capacity for VoIP),
                      and the media streams have to go via the VoIP service provider's bandwidth,
                      which adds to the cost.

                      On the other hand, if the FBI get their way under the CALEA regulations, a
                      VoIP service provider will have to be able to tap the voice stream, and in
                      a manner undetectable to the wiretap subjects. That might mandate using
                      SBCs, as I believe Vonage (for example) does.

                      The fact that Skype is P2P and encrypted is probably giving the Feds heartburn.

                      Rob

                      (robert at welbourn dot com)

                      At 10:07 AM 9/3/2003 -0500, brandon@... wrote:
                      > > Regarding Packet8's 'magic'... could it be something like the next-port
                      > > tricks that are possible with some NATs, i.e. A and B use a relay to
                      > > co-ordinate their timing and port numbers so they each initiate
                      > > connections to the other's NAT at the same time on port+1 and rely on
                      > > the fact that the other's NAT will (probably) assign the next sequential
                      > > port to the outgoing connection. If it works, A and B can then talk
                      > > directly even though they're mutually NAT'd. What else could it be?
                      >
                      >Well my box arrives on Friday, so I'll let you know.
                      >
                      >
                      >To unsubscribe from this group, send an email to:
                      >decentralization-unsubscribe@egroups.com
                      >
                      >Announce or discover P2P conferences on the P2P Conference Wiki at
                      >http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
                      >
                      >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                    • Robert Welbourn
                      Well, the Skype site now has posted some limited technical info. It looks like they are doing application level routing using relay peers which have public IP
                      Message 10 of 16 , Sep 3, 2003
                      • 0 Attachment
                        Well, the Skype site now has posted some limited technical info. It looks
                        like they are doing application level routing using relay peers which have
                        public IP addresses, and aren't behind a firewall. Given the current state
                        of the world, I would imagine that the number of users that are in that
                        particularly category is diminishing! That could account for some of the
                        overloading they have been experiencing -- a full-duplex VoIP connection
                        with 20 millisecond sampling and no silence suppression generates a load of
                        around 100 packets per second, not to mention the bandwidth it uses.

                        If they're smart, they'll optimize it so that those calls that can go
                        through NATs directly do so (using UPnP or brokered hole punching with
                        full-cone NATs), and use relaying for the rest. Otherwise, it may require
                        the Internet to be seeded with powerful relay peers on fat pipes.

                        Rob

                        (robert at welbourn dot com)
                      Your message has been successfully submitted and would be delivered to recipients shortly.