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

From: [email-masked]
Date: Tue, 07 Mar 2006 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-02.txt
	Pages		: 31
	Date		: 2006-3-7
	
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.
Even when a proxy server can open a TCP connection to a User Agent,
most User Agents lack a certificate suitable to act as a TLS
(Transport Layer Security) server.  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-02.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-02.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-02.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: Sat, 11 Mar 2006 19:51:10 +0100

Some comments on this draft:

Section 3.2 (and elsewhere): in addition to stating that a proxy/registrar 
should prefer the most recently registered flow, I would suggest that the 
registrar explicitly invalidates an existing registration when it receives a 
new registration with the same instance-id / reg-id. This situation would 
most likely be due to a reboot of the client. For TCP and other 
connection-oriented transports it would be detected, but a registration over 
UDP could survive a client crash

Section 3.3: the example route set should include the 'lr' parameter in each 
URI, as is done in section 8

Section 3.5: the statement "[...] most operating systems do not allow the 
time to be set on a per connection basis." is not true. Although I must 
admist I have no personal programming experience on this, Linux seems to 
offer "3 non-standard TCP socket options for tweaking the keepalive behavior 
of individual sockets: TCP_KEEPIDLE, TCP_KEEPCNT, and TCP_KEEPINTVL. The 
values set on a socket with these options should override the system-wide 
default.[http://www.ussg.iu.edu/hypermail/linux/kernel/0508.2/0745.html]. 
Windows offers WSAIoctl with SIO_KEEPALIVE_VALS, which also provides 
per-connection setting of keep-alive (enable, time and interval)

Section 4.1: When firmware is updated, should the instance-id be updated 
too? I've mentioned before that Jonathan made a remark on caching of UA 
capabilities some time ago, would there be other reasons to do this?

Section 8: The second REGISTER request should have a different Via branch 
and From-tag (in addition to the Call-ID which is already different)

Section 9: Perhaps the ABNF could be made more in line with the text, which 
states that "the instance-id MUST be an URN [RFC2141]". Suggestion to change 
it into
instance-val   = <URN>    ; <URN> defined in RFC2141Regards,Jeroen

> implementation to automatically retrieve the ASCII version of the

--------------------------------------------------------------------------------

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 12 Mar 2006 12:39:54 -0800

Many thanks for great comments. More inline...

> UDP could survive a client crash

This has been a topic of large debate and we (with many but not most people
saying exactly what you are saying). We asked about it in WG meeting and on
list and came to agreement that the text that does not allow "explicit
invalidation" was better. I'm scared to reopen this.

> URI, as is done in section 8

thanks

> per-connection setting of keep-alive (enable, time and interval)

Wow - interesting. Long, Long ago when I wrote this, I went and looked in
Windows 2k, Linux, and Solaris. I must has missed this. Thanks for finding
this - I must have done a lousy job of looking. Have you done any testing to
see if we can use this and avoid the whole STUN argument we have been
having. 

> capabilities some time ago, would there be other reasons to do this?

Good Questions - I would probably vote no but seems like a good discussion
point. Things like B2BUA may have changing capabilities based on what is on
the other side of them. Caching capabilities seems very risky.

> and From-tag (in addition to the Call-ID which is already different)

Yes

> instance-val   = <URN>    ; <URN> defined in RFC2141Regards,Jeroen

Need to think about this but you are probably right.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 14 Mar 2006 20:55:33 +0100

> see if we can use this and avoid the whole STUN argument we have been

I have just done some basic testing on the Windows (XP) implementation of 
TCP keep-alive.

I used the following code (s = a tcp socket):

#include <mstcpip.h>    // for tcp_keepalive

 int val = TRUE;
 ::setsockopt( s, SOL_SOCKET, SO_DONTLINGER, (const char*) &val, 
sizeof(val) );
 ::setsockopt( s, SOL_SOCKET, SO_KEEPALIVE,  (const char*) &val, 
sizeof(val) );
 ::setsockopt( s, IPPROTO_TCP, TCP_NODELAY,  (const char*) &val, 
sizeof(val) );

tcp_keepalive settings;
settings.onoff = 1;
settings.keepaliveinterval = 1000; // interval of a probe when failed, in ms
settings.keepalivetime = 60000;   // every X ms, default is 2 hours
DWORD nBytes=0;
int r = ::WSAIoctl( s, SIO_KEEPALIVE_VALS, &settings, sizeof(settings), 
NULL, 0, &nBytes, NULL, NULL );    // succeeds, r==0

This causes the client to send a TCP keep-alive segment with SEG.SEQ = 
SND.NXT-1 as per RFC1122, containing 1 byte of garbage data (byte 00) and DF 
flag set. It sends the first probe 60 seconds after the connection has been 
idle (I only performed a TCP REGISTER over it), and repeats this every 
interval as specified. Different values give different intervals, and other 
connections are not affected. The server (a win2k machine I think) responds 
with a TCP ACK segment

My conclusion: This seems usable...

Regards,

Jeroen

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 16 Mar 2006 11:14:07 -0800

> My conclusion: This seems usable...
agree

Thank you. Any chance someone could try the equivalent things on some other
OS? particularly Linux and Solaris? OSX? Other versions of windows?

---

From: Aki Niemi <[email-masked]>
Date: Fri, 17 Mar 2006 10:10:53 +0200

Hi,

> OS? particularly Linux and Solaris? OSX? Other versions of windows?

Is this strictly an OS issue? Can you set these options via the socket
APIs of, say, Java or C#?

I quickly tried on Linux, using perl's Socket module (wrapper for
sys/socket.h and with PHP's socket functions. Both let you enable
keepalives (SO_KEEPALIVE set to true), but both failed when I tried to
set TCP-level options, namely TCP_KEEPIDLE and TCP_KEEPINTVL. It could
be me, or then for those languages, only socket level options are
supported. If this is so, and I didn't goof on some silly thing, with
PHP or perl, you'd be left with the default idle time of 2 hours, before
keepalives start (in 75 second intervals).

Hope this helps.

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Fri, 17 Mar 2006 14:36:12 +0200

One more thing, Symbian only seems to support TCP keepalives with global
idle and probe intervals, and not per-connection basis. Meaning,
something else is still needed there.

Cheers,
Aki

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 18 Mar 2006 11:50:26 +0100

Aki,

I agree with you that TCP per-connection keep-alive alone is not sufficient 
to cover all deployments. Also languages built on top of the OS (like Java, 
C# I don't know) don't currently offer it, presumably since it's not 
commonly available on all platforms.

In my test I did not make any changes to the server side, so in my case it 
only depends on client side support. However, in real life there may be 
other prohibiting factors. Perhaps some NAT devices would block the 
keep-alive segments, I'm not sure

I would propose that the outbound draft recommends "TCP per-connection 
keep-alive when available, else XXX", where XXX is still subject to vehement 
discussions. Condition is that the keep-alive interval can be set on 
individual connections to a random value between 95-120 seconds

My point is that if TCP per-connection keep-alive is available, it should be 
the preferred choice as it is more scalable and efficient than the other 
alternatives being discussed (and more easy to implement / get right)

Regards,

Jeroen

---

From: Aki Niemi <[email-masked]>
Date: Sun, 19 Mar 2006 17:50:47 +0200

ext Jeroen van Bemmel wrote:
> keep-alive when available, else XXX", where XXX is still subject to
> vehement discussions. Condition is that the keep-alive interval can be
> set on individual connections to a random value between 95-120 seconds

I agree.

> My point is that if TCP per-connection keep-alive is available, it
> should be the preferred choice as it is more scalable and efficient than
> the other alternatives being discussed (and more easy to implement / get
> right)

Yes, plus there is one interesting security property as well, since
keepalives over an encrypted channel are potentially an easier target
for someone sniffing the traffic in order to brake the session key.

Cheers,
Aki