Subject: [p2p-sip] SIP, ICE, and an Overlay Network

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 14 Mar 2006 13:20:13 -0800

Ok, so if I understand this discussion:

1) The only problems we're trying to solve are decentralizing the SIP proxy
and STUN/TURN services.  Anything that doesn't relate to these problems is
out of scope.  (Specifically, the whole topic of NAT traversal between UAs
for media streams is entirely out of scope.)

2) While solving the problems in (1), we can make no significant change to
SIP itself.  In other words, our solution must seamlessly interoperate with
non-P2P SIP clients (for some definition of 'seamless').

3) We must craft our solution using the best of breeds techniques available
from the P2P community.  Thus we're focused on the *engineering* problem,
not the *research* problem.  (Specifically, problems that haven't been
clearly solved by the research community won't be tackled by us, including
many desirable security topics.)

Is this about right?

If so, I like the proposal of just focusing all our energy on creating a
top-notch overlay layer, and then documenting the "best practices" and
bindings in order to use this layer for SIP addressing, ICE resource
location, etc.  Thus we have a clean separation between our overlay service,
and the SIP service.

Unfortunately, because we're barred from modifying existing protocols
(beyond specific bindings, such as address types), that leaves us no choice
but to roll our own entirely new protocol from scratch.  Clearly we can
choose a model, or even standardize one that is already in use, but it's
still a bigger task than just piggypacking atop of SIP.  

But on the upside, it gives us a lot of flexibility, and simplifies the
problem space.  It nicely cleaves the work into:
- Creating an overlay service with a clean external interface
- Documenting how to use this overlay service by SIP and ICE

Does this sound about right?

-david

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 14 Mar 2006 15:45:19 -0600

> for media streams is entirely out of scope.)

maybe I'm confused, but I see "STUN/TURN services" as key components  
of "NAT traversal between UAs for media streams".

--
Dean

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 14 Mar 2006 15:11:06 -0800

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis at softarmor.com]
> Subject: Re: [p2p-sip] SIP, ICE, and an Overlay Network
> 

Ah, sorry, I merely meant to mean we'd provide a decentralized directory of
STUN/TURN servers.  Thus our overlay network doesn't "understand" STUN any
more than your hard drive "understands" a Word doc.  Both are just storage
mechanisms that are used by other services.

-david

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 14 Mar 2006 16:35:08 -0800

> From: David Barrett

Oh, I should also add that in this proposal, the overlay network doesn't
"understand" SIP either.  It's just a service that happens to work really
well with SIP.  Furthermore, SIP doesn't "understand" the overlay, it just
happens to work really well with it.

The hairy junction would be in what I'm calling the 'bindings', which is the
glue code that converts SIP requests/responses into a series of overlay
requests/responses, and back.  For example, the SIP binding would define how
a REGISTER command is converted into a series of GETs and PUTs into the
overlay, and vice versa.  The ICE binding would specify how a node uses the
overlay to both register and locate TURN and STUN servers.

In theory there could be other bindings as well (presence information, for
example), but those aren't the focus.

Is this what we have in mind?

-david

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Tue, 14 Mar 2006 19:52:33 -0500

> Is this what we have in mind?

I think there are a number of competing ideas on this point.  It's one
of the major issues we need to evaluate and address in a WG.  My
personal opinion (as you can probably guess from
draft-bryan-sipping-p2p) is that the overlay maintenance can, in fact,
benefit from being based on SIP.   The primary reason for is that if
we're targeting SIP devices, they already have a SIP stack, with all
the associated benefits of the work that's gone into that addressing
various challenges.  If we build an entirely new protocol for overlay
maintenance from scratch, that's a lot of work.  It will take time and
will have a lot of problems that SIP has already addressed  Our SIP
devices already have that protocol, so it makes sense to build on top
of that.  Our draft tries to do that with as few modifications to SIP
as possible (a few new headers and parameters, essentially),
essentially trying to see what can be done with this approach.  The
new version adds a cleaner separation between "p2p" operations and
"cs" operations (so that one never jumps to the other type in a
redirect of the same transaction, for example).

Some people are bothered by our SIP extensions and would prefer to
introduce an entirely new method rather than use REGISTER. 
Personally, I think REGISTER makes sense here, but it's an interesting
question.  Other people don't want to see any new headers introduced
in SIP at all, and therefore want an entirely new protocol.  I don't
see the need for that, personally, but they can probably argue quite
correctly that SIP wasn't originally intended to have some of the
semantics we're giving it.  It's also asking for an awful lot of work,
vs something that we can build on and get running quickly.

The point is that we all want to support P2P resource registration,
discovery, and session setup for SIP endpoints.   We need to form the
WG around those goals.  Then we need to evaluate what the best path is
to get there.

Bruce

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 14 Mar 2006 17:32:55 -0800

> From: Bruce Lowekamp
> benefit from being based on SIP.   

Hi Bruce.  Actually, I like this plan.  I think SIP would be better off with
distributed resource location and NAT traversal built in.  I totally agree
these could be accomplished with minor, localized improvements to SIP
itself.  And I think it could further be done in a way that doesn't break
interoperation with non-extended clients.

But I've heard a lot of opposition to this point.  ICE has already set the
precedent of creating a separate system to handle the separate problem.
I've made it very clear I disagree with this precedent, but I'm willing to
accept it if that's what it takes to move forward.

So I'm fine with either building distributed resource management and NAT
traversal:

1) Into the SIP base with minor changes
2) Into a separate layer as a totally new protocol

The same reasoning that delegated NAT traversal to ICE is what keeps
resource management out of SIP.  I'd *love* to reconsider that reasoning.
But if not, I'd like to move forward.

-david

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Tue, 14 Mar 2006 21:51:39 -0800 (PST)

> accept it if that's what it takes to move forward.

ICE is a proven solution for establishing media
streams, but P2P SIP needs more. In classic SIP, the
end points can exchange signalling through proxies.
The proxies themselves don't have to traverse NAT. In
P2P SIP, the end points have to be able to send their
signalling messages directly, crossing NAT if needed.
I don't get how that can be done without adding some
NAT traversal capability to SIP itself. 

-- Karst

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 15 Mar 2006 00:06:01 -0800

> From: Karst Bjorgson [mailto:karstbj at yahoo.com]
> Sent: Tuesday, March 14, 2006 9:52 PM
> To: David Barrett; 'Bruce Lowekamp'
> Cc: 'P2P-SIP'

I totally agree -- NAT traversal is a natural fit into the baseline SIP
syntax.  I think it can be done with only very minor changes.  The outline
of my proposal is here: (with the summary plucked out)

https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-January/000289.html

> In summary, I suggest:
> - SIP be expanded with a STUN command that proxies MUST implement
> - User agents REGISTER multiple (ip:port) tuples with the proxy
> - Proxies respond "300 Multiple Choices" to INVITE, to which UA's
>   holepunch
> - Proxies append all of A's (ip:port) tuples when forwarding to B
> - B replies "200 OK" direct to all of A's (ip:port) tuples

In essence, every P2P-SIP proxy becomes a rendezvous service (and
non-P2P-SIP proxies work as before).  And a distributed P2P-SIP proxy
naturally becomes a distributed rendezvous service.  

Is this (or something along these lines) what you had in mind?

(Incidentally, ICE could still play its standard role in negotiating media
streams; this above solution only sets up the SIP signaling stream.)

-david

---

From: jh at tutpro.com (Juha Heinanen)
Date: Wed, 15 Mar 2006 10:49:50 +0200

> > - SIP be expanded with a STUN command that proxies MUST implement

last time i checked and tried, STUN didn't work if SIP UA was behind
symmetric NAT.  since most NATs are symmetric, i found STUN to have very
little value and we turned the service off.  has something changed?

-- juha

---

From: aki.niemi at nokia.com (Aki Niemi)
Date: Wed, 15 Mar 2006 10:57:24 +0200

> little value and we turned the service off.  has something changed?

I think it still has value in SIP, as in being able to register the
public IP/port instead of the private ones. Of course, with symmetric
NATs, redirects won't work, but forwarding ought to work.

However, aren't we talking about RFC 3581 here?

Cheers,
Aki

---

From: jh at tutpro.com (Juha Heinanen)
Date: Wed, 15 Mar 2006 11:08:33 +0200

Aki Niemi writes:

 > public IP/port instead of the private ones. 

any decent proxy can detect if a UA is behind NAT and register
automatically both public and private addresses/ports.

-- juha

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 15 Mar 2006 01:09:04 -0800

> From: Juha Heinanen [mailto:jh at tutpro.com]

Well, it partially works.  STUN will still correctly return the external
mapping.  The problem is that mapping will only be valid for that one STUN
server -- nobody else can 'call back' through that hole in the NAT.
However, it does give us a sense of what the 'latest' mapping is, and
thereby give us a starting point for port prediction.  Taken all together,
assuming one or both of us are behind symmetric NATs:

1) You and I connect to the proxy
2) I pick a random STUN server (proxy) and figure out my latest mapping
3) I send INVITE to the proxy, including my latest mapping
4) The proxy replies with a list of your last known mapping
5) The proxy forwards my INVITE to you with my latest mapping
6) You pick a random STUN server (proxy) and figure out your latest mapping
7) You reply to the proxy's INVITE indicating your latest mapping
8) The proxy returns your latest mapping back to me
  --- At this point we both have a good guess of the other's mapping ---
9) I start scanning all your mappings (and predict some more)
10) You start scanning all my mappings (and predict some more)
11) Eventually our scans overlap and we establish a direct connection

It's not a pretty process, and it's not guaranteed to work (that's what TURN
is for), but it's been made to work with extremely high success rates in the
real world.  Basically, the proxy accumulates a list of (ip:port)
combinations that it thinks you can get contacted at.  If you're on a
non-symmetric NAT, this list will never grow.  If you're on a symmetric NAT,
we'll constantly discard the old entries and replace it with the latest.
Regardless, it's the same algorithm for both symmetric and non-symmetric
NATs.  (Though by guessing the NAT type we can optimize even further.)

The key, of course, is having a large pool of STUN servers to draw from,
because you'll need to re-STUN before each new connection.  Otherwise you'll
lose track of your 'latest' mapping and make port prediction (which, in its
most basic form, is just linearly trying a range of N ports ahead of the
remote user's 'latest') work poorly.

-david

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 15 Mar 2006 15:45:58 -0600

> little value and we turned the service off.  has something changed?

Yes. You'd also add a TURN component (see latest draft) into your  
proxy, and voila, symmetric NAT traversal.

In my P2P-SIP fantasy world, all the supernodes provide STUN/TURN  
services. They MAY also provide "SIP proxy" interfaces that adapt  
regular SIP client-nodes to the overlay network.

Another model moves the STUN/TURN services (and maybe the proxies)  
into a layer of extraordinary but not super (well-connected but lack  
full route participation) nodes, each of which provide named resource 
(s) in the overlay.

--
Dean

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 15 Mar 2006 15:49:49 -0600

Almost completely off-topic here, but if ICE incorporated your port- 
prediction approach in between the
"stun" and "turn" phases, would it satisfy your requirements?

--
Dean

---

From: jh at tutpro.com (Juha Heinanen)
Date: Thu, 16 Mar 2006 00:18:18 +0200

> proxy, and voila, symmetric NAT traversal.

dean,

today there are large number (perhaps hundreds) of open source
ser/openser SIP proxies deployed today that achieve NAT traversal
without any need for STUN in the UAs or in the network.  

they automatically detect from via and contact headers and source IP
addresses/ports if an UA is behind any kind of NAT and if so, start
sending requests and replies to its public IP address.

since this is currently working well (equal to Skype), what added values
(complexity does not count) does STUN offer here?

-- juha

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 15 Mar 2006 16:57:39 -0600

> (complexity does not count) does STUN offer here?

Try talking to a college-boy who's behind a double-NAT, which is  
happening a lot now at universities (one at the University level, one  
for the dorm room), and I'll bet you find Skype works a lot better.

Off-topic for P2P, perhaps, but we've found any number of deployments  
(I've been supporting UA design for Vonage, AT&T, and other  
deployments that use some Linksys gear) where this doesn't work all  
that well. The main issue is keepalive, and STUN (in combination with  
the "outbound" draft) gives us a much better answer for keepalive  
than sending a REGISTER request every 20 seconds does.

That said, what you're using in SER is essentially a mini-STUN. STUN  
uses the same fundamental NAT detection technique, gives feedback  
also to the UA about its NATness, and generally just solves a few  
more cases, while maintaining good efficiency levels.

This stuff is finally starting to come together into a generally- 
workable solution. No perfect, but much better than the amalgamated  
glop that has hampered broad-scale deployments for the the pas few  
years.

--
Dean

---

From: jdrosen at cisco.com (Jonathan Rosenberg)
Date: Wed, 15 Mar 2006 17:59:02 -0500

There is a lot of misinformation floating around on these threads about 
how traversal for signaling itself works.

Please read:
http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-02.txt

which deals with this problem.

The net/net is that it allows clients to register to the proxy their 
current TCP connection and/or UDP 5-tuple, and to use keepalives to keep 
the bindings open for incoming calls. The mechanism works through 
symmetric nat as well. Note that it uses STUN messages for the 
keepalives themselves. Please do not confuse this usage of stun with 
'classic' stun in rfc3489 where the stun messages are sent to a separate 
stun server for discovery of nat type and learning of bindings. Here, 
they are used to keep bindings alive and to detect change in bindings. 
The notion of differing stun usages reflects the reality of its 
deployment over the years and is described in rfc3489bis.

Now, in terms of p2p nat traversal for SIP itself, the sip-outbound 
mechanism works just fine for p2p sip as well. The difference is that 
the proxy is just another host in the mesh. Of course, it better be one 
on the public network so everyone can reach it, else you will not be 
able to get incoming calls from everyone.

Now, the only issue as I see it, is that the current sip-outbound 
mechanism requires that proxy to record-route, and to act in proxy mode. 
I can imagine that, for p2p-sip, there would be a desire to not have it 
record-route. I see nothing gained from only using redirection for the 
initial invite; if the client is keeping a binding to the proxy open 
then may as well use that for the initial rendezvous.

To eliminate record-routing and go direct if you can, that is something 
that we can't do with today's sip specs that would be a worthy 
extension. The gruu spec postulated the need for such a thing in the 
future, in fact.

One solution there is that the 200 OK from the UAS include multiple 
contact values, each representing a potentially reachable IP address and 
  a stun username/password. You then, ICE_like, check connectivity to 
each of those, and whichever one works, you use that as the contact for 
direct mid-dialog signaling. If none work, you use the proxy for 
mid-dialog requests too.

-Jonathan R.

David Barrett wrote:

> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen at cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: jdrosen at cisco.com (Jonathan Rosenberg)
Date: Wed, 15 Mar 2006 18:00:47 -0500

The sip-outbound mechanism provides a standards-based way to get sip 
signaling nat traversal to work. Today what people are doing is a hodge 
podge that sometimes doesnt work and is always expensive (frequently 
large sip message retransmits).

-Jonathan R.

---

From: jh at tutpro.com (Juha Heinanen)
Date: Thu, 16 Mar 2006 01:11:35 +0200

> for the dorm room), and I'll bet you find Skype works a lot better.

openser NAT traversal solution works fine for to users behind double
NATs.  can you be more specific here?

 > The main issue is keepalive, and STUN (in combination with  

openser is not sending REGISTER requests as keepalives, but dummy UDP
packets.  it is a bad idea from scalability point of view to make the
proxy to send any kind of keepalives that require establishing a SIP
transaction.  it might be ok for the UA to do so, in which case it would
suffice for the proxy to simply reply statelessly.

 > more cases, while maintaining good efficiency levels.

i agree with you here that it might be a good idea for the proxy to
somehow inform the UA that it is behind a NAT so that the UA could
itself handle the keepalives.  but for that purpose, would it simply
suffice for the proxy to a add an indication about NATing in register
reply?  then the only new thing the UA would need to do is to start
sending the keepalives.

-- juha

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 15 Mar 2006 17:59:18 -0600

> NATs.  can you be more specific here?

Probably not, but I'm sure somebody can. I haven't gotten SER to work  
in that configuration with Linksys UAs. Maybe Im just doing it wrong,  
but my media always gets black-holed.

> suffice for the proxy to simply reply statelessly.

Cool. How does this detect and correct for NAT resets?

> reply?  then the only new thing the UA would need to do is to start

yes, I think that could work. We're essentially moving the outbound- 
stun functionality into the REGISTER transaction. We might still have  
keepalive and reset-detection issues to work out.

--
Dean

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 15 Mar 2006 17:02:22 -0800

> From: Jonathan Rosenberg [mailto:jdrosen at cisco.com]

I think I like this solution, but I'm not sure I understand it.  Can you
give a start-to-finish message list (REGISTER, INVITE, 200OK, etc) between
two peers and a proxy?

-david

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 15 Mar 2006 17:11:52 -0800

> "stun" and "turn" phases, would it satisfy your requirements?

First, it's not really "my" port prediction approach.  It's been well
documented for years, so I don't want to take credit for it.

Second, the issue with ICE isn't so much one of features, but whether those
features should be built into SIP or a supporting protocol.  ICE takes the
supporting protocol approach; I'd prefer it were in SIP itself.

At the very least, it seems straightforward to add NAT traversal for SIP
signaling into the basic SIP protocol itself (like I think is in Jonathan's
latest proposal). 

-david

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 15 Mar 2006 17:11:54 -0800

> proxy, and voila, symmetric NAT traversal.

Ah, I was unclear.  By 'NAT traversal' I meant the direct establishment of a
connection between two peers.  TURN is clearly the most reliable fallback
position, but it routes traffic through a central relay node -- something
that is costly for the relay, and adds latency to the connection.

-david

---

From: jh at tutpro.com (Juha Heinanen)
Date: Thu, 16 Mar 2006 06:55:33 +0200

> large sip message retransmits).

jonathan,

i'll read the outbound draft and if it sounds ok, i have no problem of
implementing it in our proxies.  what comes to the current NAT traversal
in openser, i don't consider it hodge-podge and i have never experience
any kind of large sip message retransmits,

-- juha

---

From: jh at tutpro.com (Juha Heinanen)
Date: Thu, 16 Mar 2006 07:15:48 +0200

> but my media always gets black-holed.

you mean the ones that used to be called sipuras?  they work very well
here.  you just turn off all NAT claverness if they have any and let the
proxy handle rest.  of course you need to figure out, how to configure
your proxy correctly.

 > Cool. How does this detect and correct for NAT resets?

how often does your NAT reset itself?  if very often, buy a better NAT
or get an UPS.  it also helps to set REGISTER interval so something
reasonable, like 15 minutes or so.

 > > but for that purpose, would it simply

if that is what outbound STUN does, then yes.  if keepalives require
response from proxy, which i'm not sure about, then such a SIP keepalive
request would need to be defined.  but why would thr UA need a response?
in openser NAT traversal, keepalives are one way.

reset detection i would not worry about.  just use reasonable short
REGISTER intervals.

-- juha

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Wed, 15 Mar 2006 22:31:42 -0800 (PST)

> able to get incoming calls from everyone.

I am sorry, but I don't get it. If the "P2P" in P2PSIP
has any meaning, we are speaking of a network where
there are no proxies. To establish a session, one
would:

- Learn the SIP URL of the peer;
- Use a discovery protocol of some kind, maybe a DHT,
to learn the address:proto:port tuple(s) at which the
corresponding SIP UA is reachable;
- Send SIP packets directly to one of the specified
address tuples;
- After the initial signalling exchange, establish the
media streams.

There is an obvious role for STUN, TURN, or for that
matter Teredo: provide a SIP UA with a list of
address:proto:port tuples that might be reachable by
the peers. The list will have to be obtained before
the tuples are published in the discovery service, be
it a DHT or something else. Obviously, to do that, one
will have to discover the adequate servers, or maybe
super-nodes willing to act as servers.

By the way, running a DHT system across multiple NAT
is an interesting challenge...

-- Karst

---

From: marc.bailly at gmail.com (Marc Bailly)
Date: Thu, 16 Mar 2006 10:57:11 +0100

On 3/16/06, Karst Bjorgson <karstbj at yahoo.com> wrote:
> there are no proxies.

In case where a UA is behind a NAT (and can't take part in the P2P overlay),
an ordinary node / super node architecture could be set up. A super node
would act as a proxy (with outbound support) for a set of ordinary nodes in
order to traverse NAT for SIP signaling.

Marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060316/a83a9f29/attachment.html

---

From: jh at tutpro.com (Juha Heinanen)
Date: Thu, 16 Mar 2006 13:51:21 +0200

jonathan,

i read the outbound draft (not all glory details yet) and i was pleased
with it.  the main reason being that in addition to NAT traversal (which
openser can handle already now satisfactorily without any new
standardization), it also tackles the redundancy problem.

there is one thing though that i can't accept:

   UAs are configured with one or more SIP URIs representing the default
   outbound-proxy-set.  The specification assumes the set is determined
   via configuration but future specifications may define other
   mechanisms such as using DNS to discover this set.

we MUST have a DNS based way for the UAs to figure out the default
outbound proxy set BEFORE this spec is published as an RFC.  if not
done, there is yet another thing to be configured in the UA, which is
exactly what Skype lovers hate in SIP.

-- juha

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Fri, 17 Mar 2006 17:31:32 -0600

> exactly what Skype lovers hate in SIP.

I think there is some overlap here.

The UA has to have SOME sort of configured information, or it has no  
place to start.

RFC 3263 already defines how a UA can use DNS to find a proxy, based  
on the name of the proxy (if configured) or a registrar (based on the  
domain of registration, if configured). If you don't have SOME of  
this information in the UA, there's no clue where to start looking.

The problem is that DNS is NOT going to tell you about the local  
firewall proxy built into your residential router/firewall/access  
point/media server box.

--
Dean

---

From: jh at tutpro.com (Juha Heinanen)
Date: Sat, 18 Mar 2006 10:05:49 +0200

> The UA has to have SOME sort of configured information, or it has no  

yes, AoR, username and password.

 > this information in the UA, there's no clue where to start looking.

today, most SIP UAs query DNS based on host part of AoR and this has
worked very well in practise.  the same should work for
outbound-proxy-set.  if you have some special requirements, a good UA
lets you override the default behavior.

-- juha

---

From: aki.niemi at nokia.com (Aki Niemi)
Date: Wed, 22 Mar 2006 18:49:42 +0200

> direct mid-dialog signaling. If none work, you use the proxy for 

Good suggestion.

Isn't this enough to fulfill the "ICE for signaling" requirement also
voiced in today's meeting?

Cheers,
Aki