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

From: [email-masked]
Date: Tue, 27 Jun 2006 18:50:01 -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-04.txt
	Pages		: 34
	Date		: 2006-6-27
	
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-04.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-04.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-04.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: Fri, 30 Jun 2006 00:28:23 +0200

We've had some VERY long and extensive discussions on this (starting with 
http://www1.ietf.org/mail-archive/web/sip/current/msg13677.html) but the 
draft is still not addressing some of the issues that were raised

1) The UAC needs a positive indication that the selected proxy can indeed 
handle STUN packets without choking on them. It is not sufficient if the URI 
it is configured with says 'keepalive=stun', that's a wish but no guarantee.

A simple way to do this is to have the edge proxy that receives a REGISTER 
with its own address and 'keepalive=stun' in the topmost Route header mirror 
that parameter in the Path header it MUST insert (according to 5.1).

There could be an issue in case systems exist that simply copy verbatim what 
is in the Route header URI into their Path header URI. To avoid this 
scenario, perhaps a header parameter (instead of an URI parameter) would be 
an idea.

The text should then say "the UAC MUST wait for a 200 OK to REGISTER before 
it starts sending STUN packets. If the last Path header of the 200 OK does 
not contain keepalive=stun, the UAC MUST NOT use STUN towards this URI. If 
there are no Path headers and no "Supported: outbound", the UAC also MUST 
NOT use STUN towards the registrar.". It could still use TCP keepalive if it 
supports that

2) Section 5.3: the Edge Proxy MUST Record-Route dialog forming INVITE 
requests that it forwards over the flow towards the UA (reverse direction is 
not strictly necessary, but probably common too). If it does not do this, an 
ACK for 2xx cannot arrive. For incoming SUBSCRIBE it might work without (the 
NOTIFY could create a direct flow towards the target or some other proxy, 
using the local socket as a Contact), but then there would be an issue with 
keeping that flow alive (the STUN question). Probably safer to say that (in 
addition to MUST for INVITE) "the Edge Proxy SHOULD Record-Route all 
dialog-forming requests it forwards to the UA"

3) The Proxy-Require mechanism we have discussed could be useful to UACs 
that want to ensure that a selected edge proxy supports outbound, aborting 
if not.

4) (minor remark) Perhaps some words could be added that the UAC SHOULD 
perform keepalives when configured to do so, even if it detects that there 
is no NAT. There could be a transparent firewall device that needs to be 
kept open.

Regards,

Jeroen

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 28, 2006 12:50 AM
Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt

> implementation to automatically retrieve the ASCII version of the

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

---

From: <[email-masked]>
Date: Fri, 30 Jun 2006 14:27:03 +0300

Hi Rohan,

Even if this issue was discussed earlier between me and Cullen:
http://www1.ietf.org/mail-archive/web/sip/current/msg14560.html 

... I still feel uncomfortable with how chapter 4.3. Sending
Requests is formulated in latest outbound-04:

   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.

The draft is still very explicit that "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."

Like I mentioned earlier those RFC 3263 procedures might cause the UA 
to select a proxy towards which it does not have a flow open. However
what should happen in the following use cases is not very clear from
the current text and is left as "a trivial excercise for the reader":

1. UA sends an INVITE 

My earlier question was: Is the UA expected to keep this new flow alive
? 

Cullen answered: "No - if it is important for this flow to stay alive, 
it will use a GRUU in the contact which will end up with routing over 
one of the flows that is alive. This is out of the scope of outbound."

If that is the case the current text is a bit ambiguous in the sense 
that it requests the UA to "form a new flow towards the next hop".
When the I-D uses the word "flow" it nearly always refers to a flow
that the UA is required to keep alive - except this specific case.
So if the meaning is that the UA should not keep this new connection
persistently alive I could suggest rewording the text like this:

   If the UA cannot use one of the existing flows, then it SHOULD 
   send a  datagram or open a new connection to the next hop, as
   appropriate for the transport protocol.

	Note: By using GRUU in Contact header the UA can ensure
	that the possibly resulting dialog will be routed over
	an existing flow towards the UA.

2. UA sends a REGISTER refresh

My earlier question was: I believe that draft-ietf-sip-outbound 
is written with the assumption that when the UA refreshes a 
registration binding the REGISTER message would be sent over 
the same flow over which the binding was created, right ?

Cullen answered: "I think Robert has or working on a draft with 
fixes this. It's not clear this is what 3263 says should happen.
Clearly we want to send things in the same dialog on an existing 
connection if we have one. One of the things we got wrong in much 
earlier version of outbound was trying to fix every routing problem 
in sip in one document including high availability and stateless 
server design. We are definitely trying to push things that are 
orthogonal to be solved separately."

However outbound-04 still explicitely tells the UA to use RFC3263
processing, so I do not find how the UA is allowed to use the
existing flow (or use any mechanism defined in a draft by Robert).
I hope you could explicitely specify in outbound-05 one of the
following procedures:

1. UA to send registration refreshes over the same flow which
   was set up when sending the corresponding initial registration
   (instead of resolving the URI with RFC 3263 procedures).

OR

2. Mention that the UA is allowed to swap a persisten flow from
   one proxy to another when performing a registration refresh.

I would prefer the first one since the second alternative is
expected to cause some nasty race conditions when performing 
the switch.

Regards,

Erkki