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

From: [email-masked]
Date: Tue, 06 Mar 2007 15:50:02 -0500

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-08.txt
	Pages		: 43
	Date		: 2007-3-6
	
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-08.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-08.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-08.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: <[email-masked]>
Date: Thu, 8 Mar 2007 09:58:50 +0200

Hi,

Outbound-08 specifies the CRLF keepalive technique like this:

3.5.1.  CRLF Keepalive Technique

   This approach can only be used with connection-oriented transports
   such as TCP or SCTP.  The client periodically sends a double-CRLF
   (the "ping") then waits to receive a single CRLF (the "pong").  If
   the server does not receive a "pong" within an appropriate amount of
   time, it considers the flow failed.

Question 1:

Is the single CRLF "pong" necessary or could the UA detect the
flow failure just by receiving a socket or ICMP error when the 
connection is broken and not able to pass the double-CRLF "ping" 
to the proxy ?

Question 2:

If the CRLF "pong" is not necessary then will it be necessary to
introduce 'keep-tcp' and 'keep-crlf' tags for the proxy URI ?
As Rohan earlier pointed out both the TCP keepalive and double 
CRLF keepalive techniques are totally backwards compliant towards 
the existing SIP proxies, assuming that the UA is able to detect
the failure of the connection oriented flow via an error returned
by the transport layer. 

Introducing the 'keep-tcp' tag appears superfluous to me as
a number of earlier versions of the draft supported the TCP
keepalive without any specific URI tag.

If both CRLF "pong" and the URI tags related to keepalive
methods for connection-oriented transports would be removed
from the spec, then the following open question would consequently
become irrelevant:

   Having multiple keep alive options that are only valid with some
   transports, combined with SRV providing multiple transport options,
   opens the possibility for configurations that make no sense and cause
   the system to fail.  For example, if the outbound proxy set is sip:
   example.com;keep-tcp and the SRV only resolves to a UDP transports,
   the system will not work.

Comments ?

Regards,

Erkki

---

From: Dean Willis <[email-masked]>
Date: Thu, 8 Mar 2007 14:46:32 -0600

> connection is broken and not able to pass the double-CRLF "ping"

Sure, if you don't mind not getting calls for 10 minutes. And if some  
moron hasn't blocked ICMP on your network (which unfortunately  
corpsec guidelines frequently recommend).

It can take TCP a LONG time to know a flow has failed. This is a  
large part of why I liked the STUN model.

--
Dean

---

From: <[email-masked]>
Date: Fri, 9 Mar 2007 08:30:04 +0200

Hi, 

>corpsec guidelines frequently recommend).

To overcome this problem, doesn't Outbound strongly promote the
UA registering over multiple flows ? 

   This requires the UA to detect when a flow fails.  Since
   such detection takes time and leaves a window of opportunity for
   missed incoming requests, this mechanism allows the UA to use
   multiple flows to the proxy or registrar.

Are you suggesting that this mechanism in the Outbound only
has limited or even no value ?

>large part of why I liked the STUN model.

How does the addition of CRLF keepalive without CRLF "pong"
make the situation worse compared using TCP keepalive, which
has been considered acceptable for Outbound over several 
successive  draft revisions and is still there without any 
"pong" other than TCP ACK ?

And as you say, it can take TCP a LONG time to know a flow has failed,
but not necessarily. The device which rebooted might indicate the
broken connection by sending TCP RST, which immediately tells the
sender about the flow failure.

Even the STUN over TCP model will not guarantee an immediate
detection of a failed flow as Outbound suggests that the time 
between successive keepalives over TCP should be between 95 and 
120 seconds on top of which the STUN transaction adds 8 seconds 
to wait for the response. So even with STUN or CRLF "ping-pong"
you could not getting calls for two minutes if the UA is relying
on one single flow only or using two flows towards two different
proxies over a single NAT which reboots.

I am still questioning whether the requirement to add CRLF "pong"
and 'keep-crlf' URI tags are really worth the extra complexity.
Personally I am not at all convinced about it.

Regards,

Erkki