Subject: [Sip] issue with oubound and the used transport protocol

From: "Leis, Peter" <[email-masked]>
Date: Fri, 17 Nov 2006 14:59:50 +0100

hi,

after review of draft-ietf-sip-outbound-05 I have the following
questions related to the used transport protocol

It appears that Outbound-05 does not allow to switch the transport
protocol over which SIP is used. Outbound-05 says that a User Agent
terminating SIP request has to be sent to the User Agent over the flow
on which the REGISTER was received. The definition of flow in
Outbound-05 includes also the transport protocol. Now there seems to be
a problem when the REGISTER was sent over UDP and, at some point later,
a SIP INVITE request is too long to be sent over UDP, so that it needs
to be sent over TCP (see RFC 3261 section 18.1.1). This seems not
possible with Outbound-05. The switchover from UDP to TCP is a strong
requirement and in case this is not supported the usability of the draft
seems to be rather restricted. 

Peter

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Fri, 17 Nov 2006 09:43:33 -0600

> seems to be rather restricted.

A UA that is expecting to engage in this behavior would need to  
establish TCP and UDP bindings via outbound registration.

I suppose one could extend the system to add a management message  
that would tell a UA that had registered using UDP to build up a new  
registration using TCP, but we don't have anything quite like this  
now. There have been some suggestions from the systems management  
people that there would be interest in using SIP to tell a UA to  
establish a "management connection" on demand, and what you're  
suggesting is fairly similar.

Or we could just deprecate UDP. Folks know where I stand on that  
one . . .

--
Dean

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 17 Nov 2006 07:53:38 -0800

Hi Peter,

The primary motivator for outbound is traversal of NATs and firewalls.  
There is no technical way that an inbound TCP connection through these 
NATs would work. However, outbound allows multiple flows to be 
established.  A UA could establish both a UDP flow and a TCP flow to 
allow for switchover.

I will point out that the initially the outbound spec only addressed 
stream-oriented flows.

thanks,
-rohan

---

From: Fredrik Thulin <[email-masked]>
Date: Fri, 17 Nov 2006 16:52:30 +0100

Dean Willis wrote:
...
> Or we could just deprecate UDP. Folks know where I stand on that one . . .

To me it sounds like we have to, at least for UACs using Outbound. Let's 
do it! ;)

/Fredrik

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 17 Nov 2006 18:20:56 +0100

The outbound draft needs to say: "if a UA establishes a flow using an 
unreliable transport, it MUST also establish one over a reliable transport" 
(to support switch over). Moreover, I would suggest to add "it is 
RECOMMENDED that the UA establishes a flow using a reliable transport"

Regards,
Jeroen

Rohan Mahy wrote:
>> terminating SIP request has to be sent to the User Agent over the
>> flow on which the REGISTER was received. The definition of flow in
>> Outbound-05 includes also the transport protocol. Now there seems to
>> be a problem when the REGISTER was sent over UDP and, at some point
>> later, a SIP INVITE request is too long to be sent over UDP, so that
>> it needs to be sent over TCP (see RFC 3261 section 18.1.1). This
>> seems not possible with Outbound-05. The switchover from UDP to TCP
>> is a strong requirement and in case this is not supported the
>> usability of the draft

---

From: Fredrik Thulin <[email-masked]>
Date: Sat, 18 Nov 2006 12:57:33 +0100

> established.  A UA could establish both a UDP flow and a TCP flow to 

Can it, in case of an edge proxy being used? An incoming request that 
has passed the authoritative proxy is already destined for a _specific_ 
flow between the UA and the edge proxy.

This means the authoritative proxy needs information about the transport 
used for each flow, and use this knowledge when it decides which edge 
proxy and which flow it should send an incoming request towards. Seems 
impractical to say the least.

/Fredrik

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 18 Nov 2006 23:44:29 -0500

Peter - this is a good point.

I don't think outbound changes SIP in any way on this. If your UA  
supports TCP and UDP and your proxy had deployed both, then using TCP  
or both is a *real good idea*. This is as true in 3261 as it is with  
outbound. If your UA does not support TCP or your proxy does not  
allow TCP to be used for whatever reasons - then switching does not  
work. Again outbound is same as 3261 here.

The gist of this is that deprecating UDP is a very separable problem  
from outbound and that I think outbound is the wrong place to go have  
this debate.

I have no problem pointing out that when doing outbound, if you don't  
register withy TCP, the proxy can't switch from UDP to TCP.

For better or worse, I do expect to see lots of UDP only usage of  
outbound in the next few years.

On Nov 17, 2006, at 10:43 AM, Dean Willis wrote:

>> flow
> that would tell a UA that had registered using UDP to build up a  
> new registration using TCP, but we don't have anything quite like  
> this now. There have been some suggestions from the systems  
> management people that there would be interest in using SIP to tell  
> a UA to establish a "management connection" on demand, and what  
> you're suggesting is fairly similar.
>

---

From: Rohan Mahy <[email-masked]>
Date: Sat, 18 Nov 2006 21:28:07 -0800

Hi Fredrik,

I was thinking that the UDP flow would fail and the proxy would try the 
next flow (which happens to be CP), but I realized that we have no 
response to convey this semantic.  The 430 Flow Failed response code 
won't work here because the flow hasn't failed, it just can't be used 
for this transaction.

thanks,
-rohan

On Nov 18, 2006, at 3:57, Fredrik Thulin wrote:
> Rohan Mahy wrote:
>> Hi Peter,
>> The primary motivator for outbound is traversal of NATs and 
>> firewalls.  There is no technical way that an inbound TCP connection 
>> through these NATs would work. However, outbound allows multiple 
>> flows to be established.  A UA could establish both a UDP flow and a 
>> TCP flow to allow for switchover.
>
> has passed the authoritative proxy is already destined for a 
> _specific_ flow between the UA and the edge proxy.
>
> This means the authoritative proxy needs information about the 
> transport used for each flow, and use this knowledge when it decides 
> which edge proxy and which flow it should send an incoming request 
> towards. Seems impractical to say the least.
>
> /Fredrik

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 20 Nov 2006 06:57:47 +0100

Hi, 

>The outbound draft needs to say: "if a UA establishes a flow using an
unreliable transport, it MUST also establish one 
>over a reliable transport" (to support switch over).

I think it's enough to have a recommendation. In some cases it may not
be possible/feasible to establish a TCP connection - no matter if you
use outbound or not.

Regards,

Christer

>Moreover, I would suggest to add "it is RECOMMENDED that the UA
establishes a flow using a reliable transport"
> firewalls.
> >> usability of the draft seems to be rather restricted.
> >>
> >>
> >> Peter
> >
> >
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 20 Nov 2006 07:04:36 +0100

I agree with Cullen.

Regards,

Christer 

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 19. marraskuuta 2006 6:44
> To: Leis, Peter
> Cc: SIP; Rohan Mahy; Dean Willis
> Subject: Re: [Sip] issue with oubound and the used transport protocol
> 
> 
> I don't think outbound changes SIP in any way on this. If 
> your UA supports TCP and UDP and your proxy had deployed 
> both, then using TCP or both is a *real good idea*. This is 
> as true in 3261 as it is with outbound. If your UA does not 
> support TCP or your proxy does not allow TCP to be used for 
> whatever reasons - then switching does not work. Again 
> outbound is same as 3261 here.
> 
> The gist of this is that deprecating UDP is a very separable 
> problem from outbound and that I think outbound is the wrong 
> place to go have this debate.
> 
> I have no problem pointing out that when doing outbound, if 
> you don't register withy TCP, the proxy can't switch from UDP to TCP.
> 
> For better or worse, I do expect to see lots of UDP only 
> usage of outbound in the next few years.
> 
> 
> > I suppose one could extend the system to add a management 
> message that 
> > would tell a UA that had registered using UDP to build up a new 
> > Or we could just deprecate UDP. Folks know where I stand on 
> that one . 
> > . .
> >
> >
> > --
> > Dean
>

---

From: Fredrik Thulin <[email-masked]>
Date: Mon, 20 Nov 2006 08:50:52 +0100

Cullen Jennings wrote:
...
> supports TCP and UDP and your proxy had deployed both, then using TCP or 
> both is a *real good idea*. This is as true in 3261 as it is with 
> outbound. If your UA does not support TCP or your proxy does not allow 
> TCP to be used for whatever reasons - then switching does not work. 
> Again outbound is same as 3261 here.

I don't agree with the "or both" part of your recommendation above.

As I see it, if your UA and your proxy both support TCP (or TLS) you 
SHOULD NOT use UDP since that would increase the probability of 
something failing. Such failures will be fairly hard to diagnose too, 
and will lead to UAs being written in a way where they retry say a 
re-INVITE until it succeeds or the user aborts.

Also, I don't think that outbound is 100% the same as 3261 in this 
aspect. Outbound actually prevents (edge) proxies from picking a 
transport themselves, since requests they receive can/will be targeted 
at a _specific flow_.

 > from outbound and that I think outbound is the wrong place to go have

I guess some people don't want to have that debate anywhere at all.

Is there someone that wouldn't agree that it is easier for a client to 
get the desired properties of outbound with TLS/TCP than with UDP? The 
desired properties here is to get through NATs.

If there are no one that objects to this, then why would it be so hard 
to say that a UA that wants these properties MUST (or at least SHOULD) 
NOT use UDP? This is not the same as deprecating SIP over UDP.

/Fredrik

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 20 Nov 2006 09:08:26 +0100

Hi, 

>>supports TCP and UDP and your proxy had deployed both, then 
>>using TCP or both is a *real good idea*. This is as true in 3261 as 
>>it is with outbound. If your UA does not support TCP or your proxy 
>>does not allow TCP to be used for whatever reasons - then switching
does not work.
>As I see it, if your UA and your proxy both support TCP (or 
>TLS) you SHOULD NOT use UDP since that would increase the 
>probability of something failing. Such failures will be 
>fairly hard to diagnose too, and will lead to UAs being 
>written in a way where they retry say a re-INVITE until it 
>succeeds or the user aborts.
> 
>Also, I don't think that outbound is 100% the same as 3261 in 
>this aspect. Outbound actually prevents (edge) proxies from 
>picking a transport themselves, since requests they receive 
>can/will be targeted at a _specific flow_.

The edge proxy can return a error code (whatever the value will be), and
the one actually choosing the flow can choose another flow.

Then we need to think whether the one choosing the flow knows which flow
will be TCP, or if the information needs to be provided in some
header/header parameter.

>>The gist of this is that deprecating UDP is a very separable problem
from outbound and that I think outbound is the wrong place 
>>to go have his debate.

For SIP/2.0, I think it's too late to have that debate.
 
>Is there someone that wouldn't agree that it is easier for a 
>client to get the desired properties of outbound with TLS/TCP 
>than with UDP? The desired properties here is to get through NATs.
> 
>If there are no one that objects to this, then why would it 
>be so hard to say that a UA that wants these properties MUST 
>(or at least SHOULD) NOT use UDP? This is not the same as 
>deprecating SIP over UDP.

You can have NATs even if you don't use outbound.

Regards,

Christer

---

From: Fredrik Thulin <[email-masked]>
Date: Mon, 20 Nov 2006 09:31:59 +0100

Christer Holmberg (JO/LMF) wrote:
...
> will be TCP, or if the information needs to be provided in some

This will be neither simple nor fast, and therefor not good. So let's 
not go that way.

> You can have NATs even if you don't use outbound.

So what was your point exactly? Did you object to my statement that UAs 
that wants to get through NATs would be better off using TLS/TCP?

/Fredrik

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 20 Nov 2006 09:46:59 +0100

Hi,

>>>Is there someone that wouldn't agree that it is easier for a client 
>>>to get the desired properties of outbound with TLS/TCP 
>>>than with UDP? 
>>>The desired properties here is to get through NATs.
>>>
>>>If there are no one that objects to this, then why would it be so 
>>>hard to say that a UA that wants these properties MUST (or 
>>>at least SHOULD) NOT use UDP? This is not the same as deprecating SIP
over 
>>>UDP.
>So what was your point exactly? Did you object to my 
>statement that UAs that wants to get through NATs would be 
>better off using TLS/TCP?

I am not objecting.

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 20 Nov 2006 10:02:33 +0100

Hi, 

>>>The outbound draft needs to say: "if a UA establishes a 
>>>flow using an unreliable transport, it MUST also establish one
>>I think it's enough to have a recommendation. In some cases 
>>it may not be possible/feasible to establish a TCP connection - no 
>>matter if you use outbound or not.
> 
>Please enumerate the cases.
> 
>Unless there are concrete cases where TCP simply does not 
>work, I would strongly recommend we drop UDP from outbound 
>altogether. Remember, UDP already kind of works in presence 
>of NAT; this is why we have for instance rport.

Outbound is not an alternative to rport. Outbound provides you with
keep-alives, and multiple flows (in case one fails), which rport
doesn't. rport simply tells you where to send some stuff.

>Dropping UDP as a choice in outbound will make the decision 
>to drop it from SIP a lot easier in the long run. Then again, 
>keeping it in outbound will all but guarantee it will be 
>absolutely tedious ripping it out later on.
> 
>Oh, and if we did drop UDP, then the choice of the keepalive 
>mechanism becomes, well, interesting. ;)

It can also become interesting with certain security mechanisms, can't
it?

I remember, from the good old days of the SIP-versus-H.323
"discussions", PowerPoint slides showing how great SIP is because you
can use it with both UDP and TCP.... ;)

Regards,

Christer

---

From: Aki Niemi <[email-masked]>
Date: Mon, 20 Nov 2006 08:25:30 +0000

ma, 2006-11-20 kello 06:57 +0100, ext Christer Holmberg (JO/LMF)

Unless there are concrete cases where TCP simply does not work, I would
strongly recommend we drop UDP from outbound altogether. Remember, UDP
already kind of works in presence of NAT; this is why we have for
instance rport.

Dropping UDP as a choice in outbound will make the decision to drop it
from SIP a lot easier in the long run. Then again, keeping it in
outbound will all but guarantee it will be absolutely tedious ripping it
out later on.

Oh, and if we did drop UDP, then the choice of the keepalive mechanism
becomes, well, interesting. ;)

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Mon, 20 Nov 2006 15:23:35 +0200

ma, 2006-11-20 kello 10:02 +0100, ext Christer Holmberg (JO/LMF)
> doesn't. rport simply tells you where to send some stuff.

I never said it was a replacement. However, the world is full of
deployments that use UDP and work through NAT just fine (kind of); some
use rport, some use something else. Clearly, these folks aren't holding
out their deployments waiting for outbound to finish.

Many (including me) here have said TCP/TLS offers UAs superior ability
to traverse NAT compared to UDP. Yet, we insist on keeping UDP around
claiming it's needed because TCP doesn't sometimes work in outbound.

But unless someone can clearly explain where and how TCP fails to work
in a show-stopper manner, such claims are hogwash, and we should just
bite the bullet and make sip-outbound TCP-only.

> can use it with both UDP and TCP.... ;)

Right. And now RealLife is showing that sometimes when it comes to
transports (among other things), having too many options is a Bad
Thing. ;-)

Cheers,
Aki

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 20 Nov 2006 14:45:44 +0100

Hi,

>I never said it was a replacement. However, the world is full 
>of deployments that use UDP and work through NAT just fine 
>(kind of); some use rport, some use something else.
>
>Clearly, these folks aren't holding out their deployments waiting for 
>outbound to finish.

I don't think they have to. They can add outbound in future releases,
together with whatever other new fancy SIP extensions...

Regards,

Christer

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 20 Nov 2006 16:51:39 +0200

> together with whatever other new fancy SIP extensions...

provided that outbound provides any value add to what we currently
already have implemented and is deployable, i.e., there is a
standardized dhcp-free discovery mechanism (like the one that jonathan
proposed).  

on another topic, i read jonathan's ice slides and while it provides a
little bit more than what we currently have (no need for relay in some
scenarios), its complexity was overwhelming and would thus not warrant
implementing.

-- juha

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 20 Nov 2006 07:50:19 -0800

Hi Folks,

I'd really like to finish outbound.  Up until a few days ago, I had 
incorporated all the comments I'd received except for some style 
comments I was reviewing from Keith.

The problem I see is that we have two separate communities using the 
outbound draft:

1) folks that want to get through NATs and Firewalls in the public 
Internet at large - they want to use TCP and TLS with double CRLF for 
keepalives. One "flow" is always one connection.  The milestone for 
this would read "Make TCP and TLS work in the Internet".

2) folks that want UDP to work through specific NATs even if the edge 
proxy, NAT, or interface hiccups - some of these folks want to treat 
multiple IPsec SAs so the definition of "flow" becomes terribly fuzzy 
to everyone else, and they need to use STUN keepalives.

<soapbox>
I would like to use this opportunity to point out that if we said "out 
of scope for now" to outbound over UDP then we would already be done 
now and there would already be multiple implementations, including one 
that I started for the repro open source proxy.  We would have 
sidestepped the fuzzy "flow" terminology and all the endless debates 
about STUN keepalive usage and discovery, since double CRLF is fully 
backwards compatible with even RFC 2543 implementations.  I am bringing 
this up on the list because I hope the WG can look back on this and not 
make the mistake of snowballing complexity to preserve UDP parity again 
in the future.
</soapbox>

At this point, I believe that these decisions are water under the 
bridge.  I would like to explore ways forward:

FASTEST (hold nose and swallow):
Normatively RECOMMEND using congestion-safe transports for outbound.  
Point out that if you only use UDP flows you can't switch over to TCP, 
and that using a UDP flow when you have a perfectly good TCP flow is 
complete silliness.  I'll point out that TCP has been mandatory to 
implement in both UAs and proxies for 4 years.

CLEANEST (the 2 more years! approach):
Split outbound up so that we have at least three drafts:
a) an update to Path that uses a reg-id to store multiple 
bindings/paths back to a UA regardless of transport.  this is useful in 
the multiple radio interface use case for example even if there are no 
NATs.
b) a STUN keep-alive draft - with or without discovery.  I'm not 
writing it--I think it is a terrible idea.
c) outbound *connections* draft for TCP and TLS over TCP only.  (If you 
want outbound for SCTP you can write your own damn draft).
d) possibly a SIP over UDP NAT traversal draft.  Again, I have no 
interest in working on a draft with this kind of draft.

If you think you have a clever/better proposal than one of these, 
please send me private mail or phone me.

Please send comments to the list or directly to me.  If you support one 
of these two approaches, please put FASTEST or CLEANEST in the first 
line of the message.

thanks,
-rohan

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 20 Nov 2006 22:37:10 +0100

Rohan,

Minor issue for outbound-05: section 3.1 (and the references) refers to STUN 
as "Simple Traversal of UDP through NATs". It's now "Simple Traversal 
Underneath Network Address Translators" (in 
draft-ietf-behave-rfc3489bis-05.txt)

Not that "underneath" makes much sense here (to me), but I guess they wanted 
backwards compatibility for the acronym while including other transports

Regards,
Jeroen

---

From: "Rohan Mahy" <[email-masked]>
Date: Mon, 20 Nov 2006 16:44:10 -0800

Hi Jeroen,

Its already fixed in my working copy.

many thanks,
-rohan

---

From: "Leis, Peter" <[email-masked]>
Date: Tue, 21 Nov 2006 08:29:44 +0100

CLEANEST

Rohan, 

thanks for presenting the alternatives so clearly. I support CLEANEST, as this allows people to use the "OUTBOUND techniques" as appropriate for their environment.

Peter 

> -----Ursprüngliche Nachricht-----
> Von: Rohan Mahy [mailto:[email-masked]] 
> Gesendet: Montag, 20. November 2006 16:50
> An: Aki Niemi
> Cc: Jeroen van Bemmel; Leis, Peter; [email-masked]; Rohan 
> Mahy; [email-masked]; ext Christer Holmberg (JO/LMF)
> Betreff: Re: [Sip] Re: issue with oubound and the used 
> transport protocol
> 
> Hi Folks,
> 
> flow using an
> work, I would
> to drop it
> > outbound will all but guarantee it will be absolutely 
> tedious ripping 
> > it
> > out later on.
> >

---

From: "Aki Niemi" <[email-masked]>
Date: Tue, 21 Nov 2006 09:47:04 +0200

CLEANEST

(But I sincerely hope it won't be another two years ;) 

Cheers,
Aki

>From: ext Rohan Mahy [mailto:[email-masked]] 
>Sent: 20 November, 2006 17:50
>To: Aki Niemi
>Cc: [email-masked]; Rohan Mahy; [email-masked]; Leis,Peter; 
>ext Christer Holmberg (JO/LMF)
>Subject: Re: [Sip] Re: issue with oubound and the used 
>transport protocol
>
>Hi Folks,
>
>I'd really like to finish outbound.  Up until a few days ago, 
>I had incorporated all the comments I'd received except for 
>some style comments I was reviewing from Keith.
>
>The problem I see is that we have two separate communities 
>using the outbound draft:
>
>1) folks that want to get through NATs and Firewalls in the 
>public Internet at large - they want to use TCP and TLS with 
>double CRLF for keepalives. One "flow" is always one 
>connection.  The milestone for this would read "Make TCP and 
>TLS work in the Internet".
>
>2) folks that want UDP to work through specific NATs even if 
>the edge proxy, NAT, or interface hiccups - some of these 
>folks want to treat multiple IPsec SAs so the definition of 
>"flow" becomes terribly fuzzy to everyone else, and they need 
>to use STUN keepalives.
>
><soapbox>
>I would like to use this opportunity to point out that if we 
>said "out of scope for now" to outbound over UDP then we would 
>already be done now and there would already be multiple 
>implementations, including one that I started for the repro 
>open source proxy.  We would have sidestepped the fuzzy "flow" 
>terminology and all the endless debates about STUN keepalive 
>usage and discovery, since double CRLF is fully backwards 
>compatible with even RFC 2543 implementations.  I am bringing 
>this up on the list because I hope the WG can look back on 
>this and not make the mistake of snowballing complexity to 
>preserve UDP parity again in the future.
></soapbox>
>
>At this point, I believe that these decisions are water under 
>the bridge.  I would like to explore ways forward:
>
>Point out that if you only use UDP flows you can't switch over 
>to TCP, and that using a UDP flow when you have a perfectly 
>good TCP flow is complete silliness.  I'll point out that TCP 
>has been mandatory to implement in both UAs and proxies for 4 years.
>
>bindings/paths back to a UA regardless of transport.  this is 
>useful in the multiple radio interface use case for example 
>even if there are no NATs.
>b) a STUN keep-alive draft - with or without discovery.  I'm 
>not writing it--I think it is a terrible idea.
>c) outbound *connections* draft for TCP and TLS over TCP only. 
> (If you want outbound for SCTP you can write your own damn draft).
>d) possibly a SIP over UDP NAT traversal draft.  Again, I have 
>no interest in working on a draft with this kind of draft.
>
>If you think you have a clever/better proposal than one of 
>these, please send me private mail or phone me.
>
>Please send comments to the list or directly to me.  If you 
>support one of these two approaches, please put FASTEST or 
>CLEANEST in the first line of the message.
>
>thanks,
>-rohan
>
>
>>> I think it's enough to have a recommendation. In some cases it may 
>>> not be possible/feasible to establish a TCP connection - no 
>matter if 
>>> you use outbound or not.
>>
>> Unless there are concrete cases where TCP simply does not work, I 
>> would strongly recommend we drop UDP from outbound altogether. 
>> Remember, UDP already kind of works in presence of NAT; this 
>is why we 
>> have for instance rport.
>>
>> it out later on.

---

From: Fredrik Thulin <[email-masked]>
Date: Tue, 21 Nov 2006 09:50:08 +0100

FASTEST

I think it really WILL be two more years if we go for "cleanest", and I 
don't even see it as a loss to solve the problem for only those 
transports where it is solved easily.

What is the _real_ reason that user agents only implement UDP, anyway?

Most of them have TCP stacks already (for web browsing in mobile phones, 
and web interfaces in other), and even though it is harder to do 
message de-framing yourself, it isn't _that_ hard.
In my implementation I do TCP message de-framing in less than 130 lines 
of code.

/Fredrik

---

From: Dean Willis <[email-masked]>
Date: Tue, 21 Nov 2006 17:29:02 -0600

> bite the bullet and make sip-outbound TCP-only.

The arguments against TCP are, if I understand them correctly:

1) TCP may be harder to implement on high fan-out servers because  
naive systems using the socket library run out of sockets fairly  
quickly.

Response: So? Either learn to program using poll/select, or build  
smaller proxies.

2) TCP may cause the consumption of more resources in the mobile  
radio networks (specifically the battery) because of all those  
retransmissions and keepalives.

Response: Of course, outbound with UDP doesn't fare much better in  
this case, as we're still doing keepalives, and TCP's keepalives can  
be turned down or off anyhow.

3) TCP is less desirable for mobile use because each proxy attachment  
requires three more packets (the TCP handshake), and the extra two  
seconds this might require at startup on a slow GPRS link is a show  
stopper.

Response: Big fat hairy deal.

4) TCP's session binding makes it harder to do a distributed proxy  
cluster where SIP state is distributed across the cluster but TCP  
state isn't.

Response: Outbound of course helps with this by giving us the option  
to have multiple explicit entry points into the cluster.

--
Dean

---

From: <[email-masked]>
Date: Wed, 22 Nov 2006 14:57:40 +0200

Hi,

Dean Willis wrote:
>
>3) TCP is less desirable for mobile use because each proxy 
>attachment requires three more packets (the TCP handshake), 
>and the extra two seconds this might require at startup on a 
>slow GPRS link is a show stopper.
>

Clearly this does not apply to Outbound at all, since there the TCP
connection is anyway maintained persistently in order to be reachable
behind a NAT. So, at least from a mobile client point of view, this is
not an issue. 

Markus

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 22 Nov 2006 08:13:46 -0600

I happen to agree with Dean's suggested responses, I'm just offering more 
detail on this one.

> 2) TCP may cause the consumption of more resources in the mobile  radio 
> networks (specifically the battery) because of all those  retransmissions 
> and keepalives.
>
> Response: Of course, outbound with UDP doesn't fare much better in  this 
> case, as we're still doing keepalives, and TCP's keepalives can  be turned 
> down or off anyhow.

The default in the TCP specifications is a two-hour keepalive, turned off. 
If your TCP stack does something else, one might wonder "why?"

When we are not retransmitting UDP packets, concern about TCP 
retransmissions makes sense, but we are talking about SIP signaling, so 
needed retransmissions need to happen in either UDP or TCP.

Assuming that there's not a double-secret UDP retransmission mechanism that 
doesn't use battery power...

:-)

Thanks,

Spencer

---

From: <[email-masked]>
Date: Fri, 24 Nov 2006 14:54:57 +0200

CLEANEST

I have two major reasons for this opinion:

- After seeing the recent comments, the option to support
  UDP flows together with STUN keepalive really does not
  make sense. It is prone to fail with big enough messages,
  introduces a whole bunch of unnecessary complexity and
  further on is a burden for the battery consumption of
  mobile UAs (at least compared less frequent TCP keepalive).
  All practical examples of SIP use cases I have seen
  anyway generate messages exceeding 1300 bytes, for one
  purpose or another, sooner or later.

- After having a look into separate drafts written for
  mid-dialog failover, I believe it would be a wrong decision
  to approve Outbound as soon as possible and leave this
  rather important mid-dialog case to be solved separately.
  It does not make sense to split the high availability
  features to two drafts: multiple registration to Outbound 
  and mid-dialog failover to some bytes if I remember correctly.
>
> If you receive one byte that indicates this is STUN then you continue 
> reading from the socket until you have received (at least)
> 19 more bytes. From the first 20 bytes you can figure out the total 
> length of the STUN request.
>
> /Fredrik

---

From: <[email-masked]>
Date: Fri, 24 Nov 2006 14:54:57 +0200

CLEANEST

- After having a look into separate drafts written for
  mid-dialog failover, I believe it would be a wrong decision
  to approve Outbound as soon as possible and leave this
  rather important mid-dialog case to be solved separately.
  It does not make sense to split the high availability
  features to two drafts: multiple registration to Outbound 
  and mid-dialog failover to some other draft, especially
  when the failover draft is expected to have an impact to 
  Outbound. Instead the drafts should be combined the other
  way around. There should be one draft for outbound TCP
  connection maintenance and another for high availability
  by multiple registrations TOGETHER WITH mid-dialog failover.

If a version of Outbound will be frozen with UDP support
but without mid-dialog support, I believe there would either
be no deployment for the specified features (UDP) or that
the deployed implementations would lack those useful high
availability features.

For both cases: is there any point for speeding the process up 
(even if there REALLY is an urgent need for these solutions) 
if the result is that the agreed solution would not work well
enough ?

>Split outbound

>bindings/paths back to a UA regardless of transport.  This is 

More or less this would be the right direction. However
I still belive that the outbound connection draft could
be the one specifying the Path handling. My proposal would
be to move the reg-id and multiple registration part of
Outbound to the mid-dialog failover draft.

It has bothered me and my colleagues a long time that the
Outbound draft has bundled together two different things
that actually are orthogonal, both as problems and as
solutions too. The only reason to keep them together in
one single spec is that in some environments it makes
sense to use them together, but the problem is that in
some other environments separation would be desirable.

Those two items could be described like this:

- A mechanism with which an UA would be able to maintain a
  persistent flow through a NAT/firewall towards an outbound 
  proxy, keep the flow alive and monitor its state. The
  mechanism would also define how the authoritative and edge 
  proxies would use the persistent flow and Path header for 
  forwarding incoming requests to the UA.

- A mechanism with which an UA instance would be able to achieve
  high availability towards its home domain, by maintaining
  multiple simultaneous registrations without the need to
  receive multiple forked copies of a single incoming request.
  This resiliency would enable the UA to protect its connectivity
  against edge proxy failures or access network connectivity 
  failures. This mechanism would introduce the reg-id parameter
  to Contact and allow the authoritative proxy to forward
  requests to the UA using the set of registered Contacts
  and corresponding Paths.

The high availability draft should be able to refer to the
outbound connections draft, so that depending on the case
each of the multiple registrations might or might not set 
up a persistent flow towards the outbound proxy. The
high availability (including mid-dialog failover) mechanisms 
should be specified so that they would work regardless of 
whether the UA uses persistent connections towards edge 
proxies or not. Of course persistent connections would
be a must for NAT/firewall traversal, if that is the part
of problem space in the specific environment.

---
For those interested on the outbound TCP connections draft, 
I made a small excercise today. Taking the normative text from 
Outbound-06 as basis I put together normative sections for
such a draft with the following features:

1. Replaced the reg-id parameter of Contact header with 'ob' URI 
   parameter to indicate the outbound connection support
2. Explicit support for multiple registration out of scope, but 
   possible to be specified within a separate draft
3. No support for UDP or STUN keepalives
4. Connection kept alive with TCP keepalive or CLRF

I used this excercise as a proof-of-concept for myself that
the separation could be done in a way straightforward enough.

Please find the result below:

4.  User Agent Mechanisms

4.1  Instance ID Creation

   [[ other draft, especially
  when the failover draft is expected to have an impact to 
  Outbound. Instead the drafts should be combined the other
  way around. There should be one draft for outbound TCP
  connection maintenance and another for high availability
  by multiple registrations TOGETHER WITH mid-dialog failover.

If a version of Outbound will be frozen with UDP support
but without mid-dialog support, I believe there would either
be no deployment for the specified features (UDP) or that
the deployed implementations would lack those useful high
availability features.

For both cases: is there any point for speeding the process up 
(even if there REALLY is an urgent need for these solutions) 
if the result is that the agreed solution would not work well
enough ?

>Split outbound

>bindings/paths back to a UA regardless of transport.  This is 

More or less this would be the right direction. However
I still belive that the outbound connection draft could
be the one specifying the Path handling. My proposal would
be to move the reg-id and multiple registration part of
Outbound to the mid-dialog failover draft.

It has bothered me and my colleagues a long time that the
Outbound draft has bundled together two different things
that actually are orthogonal, both as problems and as
solutions too. The only reason to keep them together in
one single spec is that in some environments it makes
sense to use them together, but the problem is that in
some other environments separation would be desirable.

Those two items could be described like this:

- A mechanism with which an UA would be able to maintain a
  persistent flow through a NAT/firewall towards an outbound 
  proxy, keep the flow alive and monitor its state. The
  mechanism would also define how the authoritative and edge 
  proxies would use the persistent flow and Path header for 
  forwarding incoming requests to the UA.

- A mechanism with which an UA instance would be able to achieve
  high availability towards its home domain, by maintaining
  multiple simultaneous registrations without the need to
  receive multiple forked copies of a single incoming request.
  This resiliency would enable the UA to protect its connectivity
  against edge proxy failures or access network connectivity 
  failures. This mechanism would introduce the reg-id parameter
  to Contact and allow the authoritative proxy to forward
  requests to the UA using the set of registered Contacts
  and corresponding Paths.

The high availability draft should be able to refer to the
outbound connections draft, so that depending on the case
each of the multiple registrations might or might not set 
up a persistent flow towards the outbound proxy. The
high availability (including mid-dialog failover) mechanisms 
should be specified so that they would work regardless of 
whether the UA uses persistent connections towards edge 
proxies or not. Of course persistent connections would
be a must for NAT/firewall traversal, if that is the part
of problem space in the specific environment.

---
For those interested on the outbound TCP connections draft, 
I made a small excercise today. Taking the normative text from 
Outbound-06 as basis I put together normative sections for
such a draft with the following features:

1. Replaced the reg-id parameter of Contact header with 'ob' URI 
   parameter to indicate the outbound connection support
2. Explicit support for multiple registration out of scope, but 
   possible to be specified within a separate draft
3. No support for UDP or STUN keepalives
4. Connection kept alive with TCP keepalive or CLRF

I used this excercise as a proof-of-concept for myself that
the separation could be done in a way straightforward enough.

Please find the result below:

4.  User Agent Mechanisms

4.1  Instance ID Creation

   [[ As in Outbound-06, no changes needed ]]

4.2  Initial and Subsequent Registrations

   Registration requests, other than those described in Section 4.2.1,
   MUST include an instance-id media feature tag as specified in
   Section 4.1. Registration requests MUST also include the 'ob'
   URI parameter in the Contact URI. With 'ob' parameter the UA
   indicates that it wants to maintain a persistent flow towards
   the outbound proxy which receives the REGISTER request from the
   UA. The edge proxy is expected to use this flow when forwarding
   incoming requests towards the UA.

   UA MUST send the REGISTER request over a reliable transport
   protocol such as TCP. The connection over which the REGISTER
   was sent will be used as the persistent flow. The UA MUST
   not close the connection until it deregisters itself. Further
   on the UA must monitor the state of the flow and keep it alive
   as specified in section 4.4 of this specification.

   The UAC MUST indicate that it supports the Path header [RFC3327]
   mechanism, by including the 'path' option-tag in a Supported header
   field value in its REGISTER requests.  Other than optionally
   examining the Path vector in the response, this is all that is
   required of the UAC to support Path.

   The UAC MAY examine successful registrations for the presence of an
   'outbound' option-tag in a Supported header field value.  Presence of
   this option-tag indicates that the registrar is compliant with this
   specification, and that any edge proxies which need to partcipate are
   also compliant.

   Finally, re-registrations which merely refresh an existing valid
   registration MUST be sent over the same flow as the original
   registration.

4.3  Sending Requests

   When a UA is about to send a request, it first performs normal
   processing to select the next hop URI.  The UA can use a variety of
   techniques to compute the route set and accordingly the next hop URI.
   Discussion of these techniques is outside the scope of this document
   but could include mechanisms specified in RFC 3608 [RFC3608] (Service
   Route) and [I-D.rosenberg-sip-route-construct].

   The UA performs normal DNS resolution on the next hop URI (as
   described in RFC 3263 [RFC3263]) to find a protocol, IP address, and
   port.  For non-TLS protocols, if the UA has an existing flow to this
   IP address, and port with the correct protocol, then the UA MUST use
   the existing connection.  For TLS protocols, there MUST also be a
   match between the host production in the next hop and one of the URIs
   contained in the subjectAltName in the peer certificate.  If the UA
   cannot use one of the existing flows, then it SHOULD form a new flow
   by sending a datagram or opening a new connection to the next hop, as
   appropriate for the transport protocol. Note that flows not created
   by registration will be closed when the related dialog is closed.
   While such a flow is open the UA SHOULD monitor its state and keep
   it alive by sending the keepalive messages.

4.4  Detecting Flow Failure

   The UA needs to detect when a specific flow fails.  The UA actively
   tries to detect failure by periodically sending keepalive messages
   using one of the techniques described in Section 4.4.1. and  
   4.4.2. If a flow has failed, the UA follows the procedures
   in Section 4.2 to form a new flow to replace the failed one.
   The time between keepalive requests when using TCP-
   based transports SHOULD be a random number between 95 and 120
   seconds.  These times MAY be configurable.  Issues such as battery
   consumption might motivate longer keepalive intervals.

      Note on selection of time values: For TCP, the 120
      seconds upper bound was chosen based on the idea that for a good
      user experience, failures normally will be detected in this amount
      of time and a new connection set up.  Operators that wish to
      change the relationship between load on servers and the expected
      time that a user might not receive inbound communications will
      probably adjustAs in Outbound-06, no changes needed ]]

4.2  Initial and Subsequent Registrations

   Registration requests, other than those described in Section 4.2.1,
   MUST include an instance-id media feature tag as specified in
   Section 4.1. Registration requests MUST also include the 'ob'
   URI parameter in the Contact URI. With 'ob' parameter the UA
   indicates that it wants to maintain a persistent flow towards
   the outbound proxy which receives the REGISTER request from the
   UA. The edge proxy is expected to use this flow when forwarding
   incoming requests towards the UA.

   UA MUST send the REGISTER request over a reliable transport
   protocol such as TCP. The connection over which the REGISTER
   was sent will be used as the persistent flow. The UA MUST
   not close the connection until it deregisters itself. Further
   on the UA must monitor the state of the flow and keep it alive
   as specified in section 4.4 of this specification.

   The UAC MUST indicate that it supports the Path header [RFC3327]
   mechanism, by including the 'path' option-tag in a Supported header
   field value in its REGISTER requests.  Other than optionally
   examining the Path vector in the response, this is all that is
   required of the UAC to support Path.

   The UAC MAY examine successful registrations for the presence of an
   'outbound' option-tag in a Supported header field value.  Presence of
   this option-tag indicates that the registrar is compliant with this
   specification, and that any edge proxies which need to partcipate are
   also compliant.

   Finally, re-registrations which merely refresh an existing valid
   registration MUST be sent over the same flow as the original
   registration.

4.3  Sending Requests

   When a UA is about to send a request, it first performs normal
   processing to select the next hop URI.  The UA can use a variety of
   techniques to compute the route set and accordingly the next hop URI.
   Discussion of these techniques is outside the scope of this document
   but could include mechanisms specified in RFC 3608 [RFC3608] (Service
   Route) and [I-D.rosenberg-sip-route-construct].

   The UA performs normal DNS resolution on the next hop URI (as
   described in RFC 3263 [RFC3263]) to find a protocol, IP address, and
   port.  For non-TLS protocols, if the UA has an existing flow to this
   IP address, and port with the correct protocol, then the UA MUST use
   the existing connection.  For TLS protocols, there MUST also be a
   match between the host production in the next hop and one of the URIs
   contained in the subjectAltName in the peer certificate.  If the UA
   cannot use one of the existing flows, then it SHOULD form a new flow
   by sending a datagram or opening a new connection to the next hop, as
   appropriate for the transport protocol. Note that flows not created
   by registration will be closed when the related dialog is closed.
   While such a flow is open the UA SHOULD monitor its state and keep
   it alive by sending the keepalive messages.

4.4  Detecting Flow Failure

   The UA needs to detect when a specific flow fails.  The UA actively
   tries to detect failure by periodically sending keepalive messages
   using one of the techniques described in Section 4.4.1. and  
   4.4.2. If a flow has failed, the UA follows the procedures
   in Section 4.2 to form a new flow to replace the failed one.
   The time between keepalive requests when using TCP-
   based transports SHOULD be a random number between 95 and 120
   seconds.  These times MAY be configurable.  Issues such as battery
   consumption might motivate longer keepalive intervals.

      Note on selection of time values: For TCP, the 120
      seconds upper bound was chosen based on the idea that for a good
      user experience, failures normally will be detected in this amount
      of time and a new connection set up.  Operators that wish to
      change the relationship between load on servers and the expected
      time that a user might not receive inbound communications will
      probably adjust this time.  The 95 seconds lower bound was chosen
      so that the jitter introduced will result in a relatively even
      load on the servers after 30 minutes.

4.4.1  Keepalive with TCP KEEPALIVE

   User Agents that are capable of generating per-connection TCP
   keepalives with timer values consistent with those in this section
   SHOULD use TCP keepalives for TCP-based flows.

4.4.2  Keepalive with CRLF

   User Agents that are not capable of generating per-connection TCP
   keeplalives with timer values consistent with those in this section
   or are using some other transport protocol than TCP SHOULD send CRLF
   sequences as keepalive messages.

4.4.3  Flow Recovery

   When a flow created during registration fails, the
   UA needs to form a new flow to replace the old flow and replace any
   registrations that were previously sent over this flow. This is done 
   in much the same way as forming a brand new
   flow as described in Section 4.2; however, if there is a failure in
   forming this flow, the UA needs to wait a certain amount of time
   before retrying to form a flow to this particular next hop.

   The amount of time to wait depends if the previous attempt at
   establishing a flow was successful.  For the purposes of this
   section, a flow is considered successful if outbound registration
   succeeded and keepalives have not timed out for min-regtime seconds
   (default of 120 seconds) after a registration. If a flow is
established
   and is alive after this amount of time, the number of consecutive
   registration failures is set to zero.  Each time a flow fails before
   two minutes, the number of consecutive registration failures is
   incremented by one.  

   The number of seconds to wait is computed in the following way. This
   algorithm allows the UA to maintain multiple flows but it also
applies
   even if the UA maintains one single flow towards its home proxy. Note
   that the techniques needed to maintain multiple flows are not in
scope
   of this specification but may be defined within another document. If
   all of the flows to every URI in the outbound proxy set have failed,
   the base time is set to 30 seconds; otherwise, in the case where at
   least one of the flows has not failed, the base time is set to 90
   seconds.  The wait time is computed by taking two raised to the power
   of the number of consecutive registration failures for that URI, and
   multiplying this by the base time, up to a maximum of 1800 seconds.

   wait-time = min( max-time, (base-time * (2 ^ consecutive-failures)))

   These times MAY be configurable in the UA.  The four times are:
   o  max-time with a default of 1800 seconds
   o  base-time-all-fail with a default of 30 seconds
   o  base-time-not-failed with a default of 90 seconds
   o  min-regtime with a default of 120 seconds
   For example, if the base time is 30 seconds, and there were three
   failures, then the wait time is min(1800,30*(2^3)) or 240 seconds.
   The delay time is computed by selecting a uniform random time between
   50 and 100 percent of the wait time.  The UA MUST wait for the value
   of the delay time before trying another registration to form a new
   flow for that URI.

   To be explicitly clear on the boundary conditions:  when the UA boots
   it immediately tries to register.  If this fails and no registration
   on other flows succeed, the first retry happens somewhere between 30
   and 60 seconds after the failure of the first registration request.
   If the number of consecutive-failures is large enough that the
   maximum of 1800 seconds is reached, the UA will keep trying
   indefinitely with a random time of 15 to 30 minutes (900 to 1800
   seconds) between each attempt.

5.  Edge Proxy Mechanisms

5.1  Processing Register Requests

   When an Edge Proxy receives a registration request with a 'ob'
   URI parameter in the Contact URI, it needs to determine
   if it (the edge proxy) will have to be visited for any subsequent
   requests sent to the user agent identified in the Contact header
   field, or no this time.  The 95 seconds lower bound was chosen
      so that the jitter introduced will result in a relatively even
      load on the servers after 30 minutes.

4.4.1  Keepalive with TCP KEEPALIVE

   User Agents that are capable of generating per-connection TCP
   keepalives with timer values consistent with those in this section
   SHOULD use TCP keepalives for TCP-based flows.

4.4.2  Keepalive with CRLF

   User Agents that are not capable of generating per-connection TCP
   keeplalives with timer values consistent with those in this section
   or are using some other transport protocol than TCP SHOULD send CRLF
   sequences as keepalive messages.

4.4.3  Flow Recovery

   When a flow created during registration fails, the
   UA needs to form a new flow to replace the old flow and replace any
   registrations that were previously sent over this flow. This is done 
   in much the same way as forming a brand new
   flow as described in Section 4.2; however, if there is a failure in
   forming this flow, the UA needs to wait a certain amount of time
   before retrying to form a flow to this particular next hop.

   The amount of time to wait depends if the previous attempt at
   establishing a flow was successful.  For the purposes of this
   section, a flow is considered successful if outbound registration
   succeeded and keepalives have not timed out for min-regtime seconds
   (default of 120 seconds) after a registration. If a flow is
established
   and is alive after this amount of time, the number of consecutive
   registration failures is set to zero.  Each time a flow fails before
   two minutes, the number of consecutive registration failures is
   incremented by one.  

   The number of seconds to wait is computed in the following way. This
   algorithm allows the UA to maintain multiple flows but it also
applies
   even if the UA maintains one single flow towards its home proxy. Note
   that the techniques needed to maintain multiple flows are not in
scope
   of this specification but may be defined within another document. If
   all of the flows to every URI in the outbound proxy set have failed,
   the base time is set to 30 seconds; otherwise, in the case where at
   least one of the flows has not failed, the base time is set to 90
   seconds.  The wait time is computed by taking two raised to the power
   of the number of consecutive registration failures for that URI, and
   multiplying this by the base time, up to a maximum of 1800 seconds.

   wait-time = min( max-time, (base-time * (2 ^ consecutive-failures)))

   These times MAY be configurable in the UA.  The four times are:
   o  max-time with a default of 1800 seconds
   o  base-time-all-fail with a default of 30 seconds
   o  base-time-not-failed with a default of 90 seconds
   o  min-regtime with a default of 120 seconds
   For example, if the base time is 30 seconds, and there were three
   failures, then the wait time is min(1800,30*(2^3)) or 240 seconds.
   The delay time is computed by selecting a uniform random time between
   50 and 100 percent of the wait time.  The UA MUST wait for the value
   of the delay time before trying another registration to form a new
   flow for that URI.

   To be explicitly clear on the boundary conditions:  when the UA boots
   it immediately tries to register.  If this fails and no registration
   on other flows succeed, the first retry happens somewhere between 30
   and 60 seconds after the failure of the first registration request.
   If the number of consecutive-failures is large enough that the
   maximum of 1800 seconds is reached, the UA will keep trying
   indefinitely with a random time of 15 to 30 minutes (900 to 1800
   seconds) between each attempt.

5.  Edge Proxy Mechanisms

5.1  Processing Register Requests

   When an Edge Proxy receives a registration request with a 'ob'
   URI parameter in the Contact URI, it needs to determine
   if it (the edge proxy) will have to be visited for any subsequent
   requests sent to the user agent identified in the Contact header
   field, or not.  If the Edge Proxy determines that this is the case,
   it inserts its URI in a Path header field value as described in RFC
   3327 [RFC3327].  If the Edge Proxy is the first SIP node after the
   UAC, it either MUST store a "flow token"--containing information
   about the flow from the previous hop--in its Path URI, or reject the
   request.  The flow token MAY be placed in the userpart of the URI.
   In addition, the first node MUST include an 'ob' URI parameter in its
   Path header field value.  If the Edge Proxy is not the first SIP node
   after the UAC it MUST NOT place an 'ob' URI parameter in a Path
   header field value.  The Edge Proxy can determine if it is the first
   hop by examining the Via header field

5.2  Generating Flow Tokens

   [[ As in Outbound-06, no changes needed ]]

5.3  Forwarding Requests

   When an Edge Proxy receives a request, it applies normal routing
   procedures with the following addition.  If the Edge Proxy receives a
   request where the edge proxy is the host in the topmost Route header
   field value, and the Route header contains a flow token, the proxy
   compares the flow in the flow token with the source of the request.
   If these refer to the same flow, the Edge Proxy removes the Route
   header and continues processing the request.  Otherwise, if the top-
   most Route header refers to the Edge Proxy and contains a valid flow
   identifier token created by this proxy, the proxy MUST remove the
   Route header and forward the request over the 'logical flow'
   identified by the flow token, that is known to deliver data to the
   specific target UA instance.  For connection-oriented transports, if
   the flow no longer exists the proxy SHOULD send a 430 (Flow Failed)
   response to the request.

      The advantage to a stateless approach to managing the flow
      information is that there is no state on the Edge Proxy that
      requires clean up or that has to be synchronized with the
      registrar.

   Proxies which used one of the two algorithms described in this
   document to form a flow token follow the procedures below to
   determine the correct flow.

   Algorithm 1: The proxy base64 decodes the user part of the Route
      header.  For a TCP-based transport, if a connection specified by
      the file descriptor is present and the creation time of the file
      descriptor matches the creation time encoded in the Route header,
      the proxy forwards the request over that connection.  For a UDP-
      based transport, the proxy forwards the request from the encoded
      file descriptor to the source IP address and port.

   Algorithm 2: To decode the flow token, take the flow identifier in
      the user portion of the URI and base64 decode it, then verify the
      HMAC is correct by recomputing the HMAC and checking it matches.
      If the HMAC is not correct, the proxy SHOULD send a 403
      (Forbidden) response.  If the HMAC is correct then the proxy
      SHOULD forward the request on the flow that was specified by the
      information in the flow identifier.  If this flow no longer
      exists, the proxy SHOULD send a 430 (Flow Failed) response to the
      request.

6.  Registrar Mechanisms: Processing REGISTER Requests

   This specification updates the definition of a binding in RFC 3261
   [RFC3261] Section 10 and RFC 3327 [RFC3327] Section 5.3.

   When the Contact of REGISTER request contains an 'ob' URI parameter
   and +sip.instance media feature parameter, the corresponding
   binding is between an AOR and the the instance-id (from the 
   +sip.instance media feature parameter). For such a binding with 'ob'
   URI parameter, the registrar still stores the Contact header field
   value URI with the binding, but does not consider the Contact URI for
   comparison purposes. If the Contact of REGISTER request contains an
   'ob' URI parameter but not any +sip.instance media feature parameter,
   the registrar simply ignores the 'ob' parameter. The registrar MUST 
   be prepared to receive, simultaneously for the same AOR, some
   regit.  If the Edge Proxy determines that this is the case,
   it inserts its URI in a Path header field value as described in RFC
   3327 [RFC3327].  If the Edge Proxy is the first SIP node after the
   UAC, it either MUST store a "flow token"--containing information
   about the flow from the previous hop--in its Path URI, or reject the
   request.  The flow token MAY be placed in the userpart of the URI.
   In addition, the first node MUST include an 'ob' URI parameter in its
   Path header field value.  If the Edge Proxy is not the first SIP node
   after the UAC it MUST NOT place an 'ob' URI parameter in a Path
   header field value.  The Edge Proxy can determine if it is the first
   hop by examining the Via header field

5.2  Generating Flow Tokens

   [[ As in Outbound-06, no changes needed ]]

5.3  Forwarding Requests

   When an Edge Proxy receives a request, it applies normal routing
   procedures with the following addition.  If the Edge Proxy receives a
   request where the edge proxy is the host in the topmost Route header
   field value, and the Route header contains a flow token, the proxy
   compares the flow in the flow token with the source of the request.
   If these refer to the same flow, the Edge Proxy removes the Route
   header and continues processing the request.  Otherwise, if the top-
   most Route header refers to the Edge Proxy and contains a valid flow
   identifier token created by this proxy, the proxy MUST remove the
   Route header and forward the request over the 'logical flow'
   identified by the flow token, that is known to deliver data to the
   specific target UA instance.  For connection-oriented transports, if
   the flow no longer exists the proxy SHOULD send a 430 (Flow Failed)
   response to the request.

      The advantage to a stateless approach to managing the flow
      information is that there is no state on the Edge Proxy that
      requires clean up or that has to be synchronized with the
      registrar.

   Proxies which used one of the two algorithms described in this
   document to form a flow token follow the procedures below to
   determine the correct flow.

   Algorithm 1: The proxy base64 decodes the user part of the Route
      header.  For a TCP-based transport, if a connection specified by
      the file descriptor is present and the creation time of the file
      descriptor matches the creation time encoded in the Route header,
      the proxy forwards the request over that connection.  For a UDP-
      based transport, the proxy forwards the request from the encoded
      file descriptor to the source IP address and port.

   Algorithm 2: To decode the flow token, take the flow identifier in
      the user portion of the URI and base64 decode it, then verify the
      HMAC is correct by recomputing the HMAC and checking it matches.
      If the HMAC is not correct, the proxy SHOULD send a 403
      (Forbidden) response.  If the HMAC is correct then the proxy
      SHOULD forward the request on the flow that was specified by the
      information in the flow identifier.  If this flow no longer
      exists, the proxy SHOULD send a 430 (Flow Failed) response to the
      request.

6.  Registrar Mechanisms: Processing REGISTER Requests

   This specification updates the definition of a binding in RFC 3261
   [RFC3261] Section 10 and RFC 3327 [RFC3327] Section 5.3.

   When the Contact of REGISTER request contains an 'ob' URI parameter
   and +sip.instance media feature parameter, the corresponding
   binding is between an AOR and the the instance-id (from the 
   +sip.instance media feature parameter). For such a binding with 'ob'
   URI parameter, the registrar still stores the Contact header field
   value URI with the binding, but does not consider the Contact URI for
   comparison purposes. If the Contact of REGISTER request contains an
   'ob' URI parameter but not any +sip.instance media feature parameter,
   the registrar simply ignores the 'ob' parameter. The registrar MUST 
   be prepared to receive, simultaneously for the same AOR, some
   registrations that use instance-id and 'ob' and some registrations 
   that do not.

   Registrars which implement this specification MUST support the Path
   header mechanism [RFC3327].

   In addition to the normal information stored in the binding record,
   some additional information needs to be stored for any registration
   that contains an instance-id header parameter and a 'ob' URI
parameter in
   the Contact header field value.  First the registrar examines the
first
   Path header field value, if any. If the Path header field exists and
   the first URI does not have an 'ob' URI parameter, the registrar MUST
   ignore the 'ob' parameter in Contact and continue processing the
request
   as if it did not support this specification.  Likewise if the
REGISTER
   request visited an edge proxy, but no Path header field values are
   present, the registrar MUST ignore the 'ob' parameter in Contact URI.
   Specifically, the registrar MUST use RFC 3261 Contact binding rules,
   and MUST NOT include the 'outbound' option-tag in its Supported
   header field.  The registrar can determine if it is the first hop by
   examining the Via header field.

   If the UAC has a direct flow with the registrar, the registrar MUST
   store enough information to uniquely identify the network flow over
   which the request arrived.  For common operating systems with TCP,
   this would typically just be the file descriptor and the time the
   file descriptor was opened.  For common operating systems with UDP
   this would typically be the file descriptor for the local socket that
   received the request, the local interface, and the IP address and
   port number of the remote side that sent the request.  The registrar
   MAY store this information by adding itself to the Path header field
   with an appropriate flow token.

   The registrar MUST also store all the Contact header field
   information including the instance-id parameter and
   SHOULD also store the time at which the binding was last updated.  If
   a Path header field is present, RFC 3327 [RFC3327] requires the
   registrar to store this information as well.  If the registrar
   receives a re-registration, it MUST update any information that
   uniquely identifies the network flow over which the request arrived
   if that information has changed, and SHOULD update the time the
   binding was last updated.

   The Registrar MUST include the 'outbound' option-tag (defined in
   Section (Section 12.1)) in a Supported header field value in its
   responses to REGISTER requests for which it has performed outbound
   processing.  The Registrar MAY be configured with local policy to
   reject any registrations that do not include the instance-id and
   'ob'.  Note that the requirements in this section applies to both
   REGISTER requests received from an Edge Proxy as well as requests
   received directly from the UAC.

   To be compliant with this specification, registrars which can receive
   SIP requests directly from a UAC without intervening edge proxies
   MUST implement the STUN NAT Keepalive usage on its SIP ports as
   described in Section 8.

7.  Authoritative Proxy Mechansims: Forwarding Requests

   When a proxy uses the location service to look up a registration
   binding and then proxies a request to a particular contact, it
   selects a contact to use normally, with a few additional rules:

   o  The proxy MUST NOT populate the target set with more than one
      contact with the same AOR and instance-id at a time.  If a request
      for a particular AOR and instance-id fails with a 430 (Flow
      Failed) response, the proxy SHOULD replace the failed branch with
      another target (if one is available) with the same AOR and
      instance-id, but for different flow, if available.
   o  If the proxy receives a final response from a branch other than a
      408 (Request Timeout) or a 430 (Flow Failed) response, the proxy
      MUST NOT forward the same request to another target representing
      the same AOR and instance-id.  The targetted instance has already
strations that use instance-id and 'ob' and some registrations 
   that do not.

   Registrars which implement this specification MUST support the Path
   header mechanism [RFC3327].

   In addition to the normal information stored in the binding record,
   some additional information needs to be stored for any registration
   that contains an instance-id header parameter and a 'ob' URI
parameter in
   the Contact header field value.  First the registrar examines the
first
   Path header field value, if any. If the Path header field exists and
   the first URI does not have an 'ob' URI parameter, the registrar MUST
   ignore the 'ob' parameter in Contact and continue processing the
request
   as if it did not support this specification.  Likewise if the
REGISTER
   request visited an edge proxy, but no Path header field values are
   present, the registrar MUST ignore the 'ob' parameter in Contact URI.
   Specifically, the registrar MUST use RFC 3261 Contact binding rules,
   and MUST NOT include the 'outbound' option-tag in its Supported
   header field.  The registrar can determine if it is the first hop by
   examining the Via header field.

   If the UAC has a direct flow with the registrar, the registrar MUST
   store enough information to uniquely identify the network flow over
   which the request arrived.  For common operating systems with TCP,
   this would typically just be the file descriptor and the time the
   file descriptor was opened.  For common operating systems with UDP
   this would typically be the file descriptor for the local socket that
   received the request, the local interface, and the IP address and
   port number of the remote side that sent the request.  The registrar
   MAY store this information by adding itself to the Path header field
   with an appropriate flow token.

   The registrar MUST also store all the Contact header field
   information including the instance-id parameter and
   SHOULD also store the time at which the binding was last updated.  If
   a Path header field is present, RFC 3327 [RFC3327] requires the
   registrar to store this information as well.  If the registrar
   receives a re-registration, it MUST update any information that
   uniquely identifies the network flow over which the request arrived
   if that information has changed, and SHOULD update the time the
   binding was last updated.

   The Registrar MUST include the 'outbound' option-tag (defined in
   Section (Section 12.1)) in a Supported header field value in its
   responses to REGISTER requests for which it has performed outbound
   processing.  The Registrar MAY be configured with local policy to
   reject any registrations that do not include the instance-id and
   'ob'.  Note that the requirements in this section applies to both
   REGISTER requests received from an Edge Proxy as well as requests
   received directly from the UAC.

   To be compliant with this specification, registrars which can receive
   SIP requests directly from a UAC without intervening edge proxies
   MUST implement the STUN NAT Keepalive usage on its SIP ports as
   described in Section 8.

7.  Authoritative Proxy Mechansims: Forwarding Requests

   When a proxy uses the location service to look up a registration
   binding and then proxies a request to a particular contact, it
   selects a contact to use normally, with a few additional rules:

   o  The proxy MUST NOT populate the target set with more than one
      contact with the same AOR and instance-id at a time.  If a request
      for a particular AOR and instance-id fails with a 430 (Flow
      Failed) response, the proxy SHOULD replace the failed branch with
      another target (if one is available) with the same AOR and
      instance-id, but for different flow, if available.
   o  If the proxy receives a final response from a branch other than a
      408 (Request Timeout) or a 430 (Flow Failed) response, the proxy
      MUST NOT forward the same request to another target representing
      the same AOR and instance-id.  The targetted instance has already
      provided its response.

   The proxy uses normal forwarding rules looking at the next-hop target
   of the message and the value of any stored Path header field vector
   in the registration binding to decide how to forward the request and
   populate the Route header in the request.  If the proxy stored
   information about the flow over which it received the REGISTER for
   the binding, then the proxy MUST send the request over the same
   'logical flow' saved with the binding that is known to deliver data
   to the specific target UA instance.

      Typically this means that for TCP, the request is sent on the same
      TCP socket that received the REGISTER request.  

   If a proxy or registrar receives information from the network that
   indicates that no future messages will be delivered on a specific
   flow, then the proxy MUST invalidate all the bindings in the target
   set that use that flow (regardless of AOR).  Examples of this are a
   TCP socket closing. Similarly, if a proxy closes a file descriptor,
it
   MUST invalidate all the bindings in the target set with flows that
   use that file descriptor.

Combining the multiple registration part of Outbound-06 together
with one of the mid-dialog failover drafts would be a bigger
excercise, so I skipped that for now ;-)

Regards,
Erkki

      provided its response.

   The proxy uses normal forwarding rules looking at the next-hop target
   of the message and the value of any stored Path header field vector
   in the registration binding to decide how to forward the request and
   populate the Route header in the request.  If the proxy stored
   information about the flow over which it received the REGISTER for
   the binding, then the proxy MUST send the request over the same
   'logical flow' saved with the binding that is known to deliver data
   to the specific target UA instance.

      Typically this means that for TCP, the request is sent on the same
      TCP socket that received the REGISTER request.  

   If a proxy or registrar receives information from the network that
   indicates that no future messages will be delivered on a specific
   flow, then the proxy MUST invalidate all the bindings in the target
   set that use that flow (regardless of AOR).  Examples of this are a
   TCP socket closing. Similarly, if a proxy closes a file descriptor,
it
   MUST invalidate all the bindings in the target set with flows that
   use that file descriptor.

Combining the multiple registration part of Outbound-06 together
with one of the mid-dialog failover drafts would be a bigger
excercise, so I skipped that for now ;-)

Regards,
Erkki

---

From: <[email-masked]>
Date: Wed, 29 Nov 2006 10:59:48 +0200

Hi,

>backwards compatible with even RFC 2543 implementations.  I am 
>bringing this up on the list because I hope the WG can look back on 
>this and not make the mistake of snowballing complexity to preserve 
>UDP parity again in the future.

Rohan is making a valid point here and I believe in Outbound there
is still room for change to cater for CRLF keepalives as an option
to STUN keepalives over TCP.

I am calling the WG to look back on the keepalive decision made
earlier for TCP and proposing that Outbound should also cover 
CRLF keepalive option.

>this would read "Make TCP and TLS work in the Internet".

I agree with the intents of this community. However this is not what
the current Outbound provides. Outbound specifies two options for
keepalives for reliable connections: TCP keepalive and STUN.

These options were agreed in IETF 65, a cite from the minutes:
        
Proposal: 
   Do STUN for TCP and UDP 
   Do CRLF for TCP and STUN for UDP 
   TCP KeepAlive if supported, 1 or 2 otherwise 

Resolutions:  
   OS TCP KeepAlive should be used if the client supports it. 
   Need something more because OS TCP KeepAlive is not supported in
every
   client OS. 
   Consensus to use STUN for UDP 
   Consensus to use STUN for TCP, with use of OS TCP keep alive above.  

In that meeting the basic assumption was that every Outbound
compliant client should implement both UDP and TCP even if that
is not explicitely mentioned in the draft. However latest -06
version now makes that debatable by stating:

   Use of outbound with UDP flows typically prevents messages larger
   than 1300 bytes from being delivered using TCP as described in
   Section 18.1.1 RFC 3261.  Use of outbound in conjunction with UDP
   flows in environments where requests are expected to be larger than
   this size is therefore NOT RECOMMENDED.

In practice this seems to justify implementing "TCP only" UAs
what comes to the Outbound support. In that case the basic assumption
with STUN keepalive (implement it for TCP as it is anyway needed for
UDP as well) would become obsolete. For implementations which can
not use TCP keepalive, CRLF would obviously provide a great benefit
without significant increase of complexity to Outbound.

P.S. Last week I made a proposal for "stripped Outbound" without
UDP, STUN keepalives and multiple registrations. As that proposal
did not receive any comments, I decided to propose this minimal
addition to Outbound as an alternative that might be a bit easier
to accept but still achieve some of the benefits.

Regards,

Erkki

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 29 Nov 2006 10:30:24 -0800

Hi Erkki,

Clearly you are suggesting that we make CRLF mandatory to implement
for TCP.  There would be no longer any need to do STUN over TCP and
therefore no need implement code to deal with stream-based demuxing.
  The text about sigcomp over TCP and STUN over TLS over TCP could
also go away.

To clarify are you suggesting that an edge proxy can implement
outbound without support for UDP flow tokens, without support for STUN
keepalives over UDP, both, or neither?

thanks,
-rohan

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 30 Nov 2006 13:56:50 +0100

Hi,

Why don't we let the edge proxy choose which keep-alive mechanism to
use?

The outbound spec should now say (I haven't had time to check, but I
hope me and Rohan agreed to add it :) that the edge proxy can insert the
keepalive parameter in the Path header.

So, we define a "CRLF" value for the parameter, and the edge proxy can
then use that value for TCP flows.

Of course, if the UA is not mandated to implement all kind of
keep-alives, it will also have to be able to indicate to the edge proxy
which keep-alive mechanisms it support.

Regards,

Christer

> From: Rohan Mahy [mailto:[email-masked]] 
> Sent: 29. marraskuuta 2006 20:30
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Clearly you are suggesting that we make CRLF mandatory to 
> implement for TCP.  There would be no longer any need to do 
> STUN over TCP and therefore no need implement code to deal 
> with stream-based demuxing.
>   The text about sigcomp over TCP and STUN over TLS over TCP 
> could also go away.
> 
> To clarify are you suggesting that an edge proxy can 
> implement outbound without support for UDP flow tokens, 
> without support for STUN keepalives over UDP, both, or neither?
> 
> thanks,
> -rohan
> 
> > Rohan is making a valid point here and I believe in 
> Outbound there is 
> > still room for change to cater for CRLF keepalives as an option to 
> > STUN keepalives over TCP.
> >
> > earlier for TCP and proposing that Outbound should also cover CRLF 
> > keepalive option.
> >
> using the 
> > In that meeting the basic assumption was that every 
> Outbound compliant 
> > client should implement both UDP and TCP even if that is not 
> > explicitely mentioned in the draft. However latest -06 version now 
> > makes that debatable by stating:
> >
> > In practice this seems to justify implementing "TCP only" UAs what 
> > comes to the Outbound support. In that case the basic 
> assumption with 
> > STUN keepalive (implement it for TCP as it is anyway needed 
> for UDP as 
> > well) would become obsolete. For implementations which can 
> not use TCP 
> > keepalive, CRLF would obviously provide a great benefit without 
> > significant increase of complexity to Outbound.
> >
> >
> > P.S. Last week I made a proposal for "stripped Outbound" 
> without UDP, 
> > STUN keepalives and multiple registrations. As that 
> proposal did not 
> > receive any comments, I decided to propose this minimal addition to 
> > Outbound as an alternative that might be a bit easier to accept but 
> > still achieve some of the benefits.
> >
> > Regards,
> >
> > Erkki
> >

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 30 Nov 2006 09:37:15 -0800

Hi Christer,

If we are going to revisit the keepalive decision for TCP, there is no 
reason to do STUN over TCP if you have CRLF.  Likewise, CRLF does not 
work over UDP.  So, the sensible decision would be to do STUN over UDP 
and CRLF over TCP.  The alternative is to stick with STUN over TCP for 
"consistency" (a dubious attribute to trade off against implementation 
and specification complexity).

thanks,
-rohan

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 30 Nov 2006 22:18:04 +0100

Hi, 

>If we are going to revisit the keepalive decision for TCP, 
>there is no reason to do STUN over TCP if you have CRLF.  
>Likewise, CRLF does not work over UDP.  So, the sensible 
>decision would be to do STUN over UDP and CRLF over TCP.  The 
>alternative is to stick with STUN over TCP for "consistency" 
>(a dubious attribute to trade off against implementation and 
>specification complexity).

We may still need a new value for the keepalive parameter, eventhough
specific support is probably not required in order to receive CRLFs.

...OR, we simply use the parameter without a value, to indicate that
keep-alive is supported, but the actual mechanism is then based on the
transport protocol.

I don't think "keepalive=stun" would be very good in the outbound proxy
set either, in case the DNS lookup would result in using TCP.

Regards,

Christer

> > hope me and Rohan agreed to add it :) that the edge proxy 
> can insert 
> > the keepalive parameter in the Path header.
> >
> > keep-alives, it will also have to be able to indicate to the edge 
> > proxy which keep-alive mechanisms it support.
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> >
> >
> >> Subject: Re: [Sip] Re: issue with oubound and the used transport 
> >> protocol
> >>
> >> Hi Erkki,
> >>
> implement 
> >> outbound without support for UDP flow tokens, without support for 
> >> STUN keepalives over UDP, both, or neither?
> >>
> >> thanks,
> >> -rohan
> >>