Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-10.txt

From: [email-masked]
Date: Thu, 12 Jul 2007 12:15:09 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Managing Client Initiated Connections in the Session Initiation Protocol (SIP)
	Author(s)	: C. Jennings, R. Mahy
	Filename	: draft-ietf-sip-outbound-10.txt
	Pages		: 42
	Date		: 2007-7-12
	
The Session Initiation Protocol (SIP) allows proxy servers to
   initiate TCP connections and send asynchronous UDP datagrams to User
   Agents in order to deliver requests.  However, many practical
   considerations, such as the existence of firewalls and Network
   Address Translators (NATs), prevent servers from connecting to User
   Agents in this way.  This specification defines behaviors for User
   Agents, registrars and proxy servers that allow requests to be
   delivered on existing connections established by the User Agent.  It
   also defines keep alive behaviors needed to keep NAT bindings open
   and specifies the usage of multiple connections.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-10.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-sip-outbound-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-outbound-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
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: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 19 Jul 2007 00:52:48 +0200

Minor comment on section 4.3 (sending requests): it talks about the UAC 
inserting an 'ob' parameter in its Contact URI, should it do the same for 
Contact URIs in responses over an outbound flow (for consistency reasons 
perhaps; allows the other end to detect outbound usage)?

Regards,
Jeroen

[email-masked] wrote:
>> Title : Managing Client Initiated Connections in the Session
>> Initiation Protocol (SIP) Author(s) : C. Jennings, R. Mahy
>>   initiate TCP connections and send asynchronous UDP datagrams to
>>   User Agents in order to deliver requests.  However, many practical
>>   delivered on existing connections established by the User Agent.
>>   It also defines keep alive behaviors needed to keep NAT bindings
>>   open and specifies the usage of multiple connections.
>>
>> You can also visit
>> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 19 Jul 2007 11:31:01 -0700

Hi Jeroen,

I don't see why 'ob' in the Contact is necessary in a response, but  
it doesn't hurt anything either.

thanks

On Jul 18, 2007, at 3:52 PM, Jeroen van Bemmel wrote:
> Minor comment on section 4.3 (sending requests): it talks about the  
> UAC inserting an 'ob' parameter in its Contact URI, should it do  
> the same for Contact URIs in responses over an outbound flow (for  
> consistency reasons perhaps; allows the other end to detect  
> outbound usage)?
>
> Regards,
> Jeroen
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 20 Jul 2007 02:04:53 +0200

Hi,

A comment / clarification on outbound-10 section 5.3 Forwarding requests, 
regarding flow token construction and incoming/outgoing logic:
The text says to send a 430 (Flow Failed) "For connection-oriented 
transports, if the flow no longer exists" (SHOULD)

This can be read as saying that if the original TCP connection no longer 
exists, a 430 should be sent. However, if the UAC somehow lost its 
connection and recovered, there would be a new TCP connection with (likely) 
a different ephemeral port at the UAC.

For the proposed flow token algorithm, this would cause the described 
incoming/outgoing logic to fail (since the token no longer matches an 
incoming flow from the UAC). Moreover, for requests in the other direction 
("incoming") the proxy would not be able to locate the new flow, and send a 
430 where it could have done better.

Two thoughts:
1. To determine if a (non-REGISTER) request is incoming/outgoing, it might 
be easier to simply say: 1 Via header --> outgoing, else incoming. There are 
other options, the Edge proxy could check the request URI for a Contact URI 
it has seen in REGISTER before. It could also be based on Service-Route 
and/or Path.

Perhaps this draft need not explain all details, but it currently only 
describes logic for mid-dialog requests, and appears to fail in the above 
described case of TCP connection loss.

2. An alternative implementation could be to maintain a mapping of Contact 
address ( IP/host+port ) to flow, which is updated each time a REGISTER 200 
OK comes by. If the UAC is using the same Contact URIs as in its REGISTER 
(or a GRUU rewritten by the home proxy), there is no need for a flow token 
at all: the Edge proxy can use (IP/host+port part of) the request URI as an 
(hash) index into the flow table (for incoming requests).

There are many other designs possible. Main point is that the stateless flow 
token approach described seems suboptimal in case of TCP connection loss 
(home proxy may be able to recover if the UAC used 2 or more flows, but if 
all were lost and the backup edge proxy also implemented this algorithm, 
ongoing dialogs would be lost)

Regards,
Jeroen

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 20 Jul 2007 08:40:58 -0700

On Jul 19, 2007, at 5:04 PM, Jeroen van Bemmel wrote:

> Hi,
>
> A comment / clarification on outbound-10 section 5.3 Forwarding  
> requests, regarding flow token construction and incoming/outgoing  
> logic:
> This can be read as saying that if the original TCP connection no  
> longer exists, a 430 should be sent. However, if the UAC somehow  
> lost its connection and recovered, there would be a new TCP  
> connection with (likely) a different ephemeral port at the UAC.

There is a timing issue here.  Two things could happen based on timing.

1) If the UA hasn't noticed that its original TCP connection failed,  
or it noticed but the REGISTER for its new flow has not been received  
or processed yet, then edge proxy (if any) should send a 430.  If  
there is another active flow, the authoritative proxy can try that  
flow. The failed flow does not

2) The UA sent a new REGISTER to replace its original (failed) flow  
and that request has been processed.  The original flow would never  
be attempted.

In both cases, the best possible thing that could happen will happen.

> For the proposed flow token algorithm, this would cause the  
> described incoming/outgoing logic to fail (since the token no  
> longer matches an incoming flow from the UAC). Moreover, for  
> requests in the other direction ("incoming") the proxy would not be  
> able to locate the new flow, and send a 430 where it could have  
> done better.
>
> Two thoughts:
> 1. To determine if a (non-REGISTER) request is incoming/outgoing,  
> it might be easier to simply say: 1 Via header --> outgoing, else  
> incoming.

In a proxy with a colocated UA (ex: the registration package or a  
presence server), the proxy can emit "incoming" requests with 1 Via  
header.

> There are other options, the Edge proxy could check the request URI  
> for a Contact URI it has seen in REGISTER before. It could also be  
> based on Service-Route and/or Path.

This would require the Edge proxy to mirror registration state. We  
had a requirement that outbound should work without requiring this  
state mirroring.

> Perhaps this draft need not explain all details, but it currently  
> only describes logic for mid-dialog requests, and appears to fail  
> in the above described case of TCP connection loss.

What you are describing is a mid-dialog flow switchover.  This was so  
controversial that we made this explicitly out of the scope of this  
document.  The document does not prevent an edge proxy from doing  
this, but it doesn't describe how to do it either.

> 2. An alternative implementation could be to maintain a mapping of  
> Contact address ( IP/host+port ) to flow, which is updated each  
> time a REGISTER 200 OK comes by. If the UAC is using the same  
> Contact URIs as in its REGISTER (or a GRUU rewritten by the home  
> proxy), there is no need for a flow token at all: the Edge proxy  
> can use (IP/host+port part of) the request URI as an (hash) index  
> into the flow table (for incoming requests).

I'm not understanding where you propose to maintain this mapping.  If  
you want the edge proxy to keep per-flow state, I'm afraid we had a  
strong consensus not to add mechanism that requires that approach.    
If the UAC uses a GRUU in the Contact header, the edge proxy may not  
need to Record-Route.  However, that is a topic for either the GRUU  
spec or another spec on mid-dialog Record-Routing to cover.

> There are many other designs possible. Main point is that the  
> stateless flow token approach described seems suboptimal in case of  
> TCP connection loss (home proxy may be able to recover if the UAC  
> used 2 or more flows, but if all were lost and the backup edge  
> proxy also implemented this algorithm, ongoing dialogs would be lost)

Yes.  And we decided for this document that losing those calls was  
acceptable for this document.  Other specification work can take up  
that challenge, otherwise we will never make forward progress.

thanks,
-rohan