Subject: [Sip] I-D Action:draft-ietf-sip-outbound-11.txt

From: [email-masked]
Date: Mon, 19 Nov 2007 08:50:01 -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-11.txt
	Pages           : 43
	Date            : 2007-11-19

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 from the User Agent
to its Registrar.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-11.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-11.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-11.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: Wed, 21 Nov 2007 10:25:10 +0200

Hi,

First of all, in my opinion outbound-11 looks good.
It has improved a lot from the previous version and
properly addressed many comments given in August during
WGLC.

After reading the draft I found a few things for which
I would seek further clarification. Some of those were
already initially raised in WGLC and the other minor
issues are due to the new text appeared in version 11.

1. Why should the registrar store the time of updating
   the binding ?

Section 6. Registrar mechanisms tells the following:

   The registrar MUST store in the binding the Contact URI,
   all the Contact head field parameters, and any Path header field
   values and SHOULD also store the time at which the binding was last
   updated. 

   If the registrar receives a re-registration for a specific
   combination of AOR, instance-id and reg-id values, the registrar 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.

To which purpose is this stored time used ? In my understanding
such a stored time is not needed for replacing older bindings and
I could not come up with any other reason either to store the time.

As the draft tells elsewhere "[when the] reg-id values [coming from
the UA within REGISTER request] will collide with the previously 
used reg-id values [stored earlier along the binding] the registrar 
can replace the older registrations". The time of any previous update
should not matter.

2. How to respond if UA requires Outbound but the proxy does 
   not support it even if the registrar does ?

How should the registrar respond to a REGISTER request when:

- REGISTER contains Require: Outbound and reg-id in Contact

- Registrar itself supports Outbound

- Via header of REGISTER indicates that there is a proxy between
  the UA and registrar, but the proxy has not included either the
  Path header or 'ob' parameter to its URI within the Path ?

3. Completing the removal of TCP keepalive from the draft

As all the other references to TCP keepalive have now been removed 
from the draft, then please remove also this one from section 
Section 3.5. Keepalive Technique:

   transports such as TCP and SCTP, this specification describes a
   keepalive approach based on sending CRLFs, *and for TCP, a usage of
   TCP transport-layer keepalives*. 

4. Ambiguous text in section 7

Section 7. Authoritative Proxy Mechanisms: Forwarding Requests tells:

   If the proxy doubles as a registrar and stored information about the
   flow that created the binding, then the proxy MUST send the request
   over the same 'logical flow' saved with the binding,

Sorry but I do not understand what is meant by: "If the proxy doubles 
as a registrar and stored information about the flow that created the 
binding"  Proxy 'doubling as a registrar' sounds odd (which might be due
to my poor skills of English ...) Could you please clarify this ?

Thanks,

Erkki Koivusalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 21 Nov 2007 15:02:31 +0100

Hi,

One comment on the draft.

I think we should describe the usage of "ob" a little better. The usage
is a little unclear, I think.

Regards,

Christer

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 21 Nov 2007 08:19:37 -0800

> can replace the older registrations". The time of any previous update

There are three reasons, but all of them are a bit dubious.
a) RFC 3261 recommends keeping this information, but does not say why
b) This was needed in a previous version of outbound
c) GRUU uses this in the temporary GRUU invalidation procedure.   
However, this is an open issue for GRUU and outbound.  I will send  
mail about this soon.

The short answer is that it can probably be removed.

>   Path header or 'ob' parameter to its URI within the Path ?

I looked for an appropriate error message for this and it was quite a  
puzzler.  420 is clearly not appropriate. I was planning to  
investigate if 488 Not Acceptable Here or 580 Precondition Failed  
could be reused for this purpose.  I am not really keen on adding a  
new response code though. A 400 Bad Request would be appropriate but  
not especially helpful.

>    TCP transport-layer keepalives*.

Thanks

> to my poor skills of English ...) Could you please clarify this ?

Sure.  This is the case where the authoritative proxy and registrar  
roles are implemented in the same SIP implementation.  The flow was  
stored by the "registrar" but the "authoritative proxy" performs the  
lookup function and routes to the registered UA over the saved flow.

This was actually a suggestion from Byron Cambell which seemed much  
less cumbersome from the previous text, but clearly it could use some  
additional rewording.  Feel free to propose something.

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 21 Nov 2007 08:25:09 -0800

Christer,

I could add to the Overview something like this:

"The 'ob' parameter has two uses.  In a REGISTER request it is placed  
in the Path header by the first edge proxy to indicate that the edge  
proxy understood outbound and added a flow token there.  Secondly, it  
is placed by a User Agent in its dialog-forming requests, when the UA  
wants the first hop proxy to Record-Route subsequent requests in this  
dialog over the same flow."

Would that help?

thanks,
-rohan

---

From: <[email-masked]>
Date: Thu, 22 Nov 2007 09:15:41 +0200

Hi Rohan,

>additional rewording.  Feel free to propose something.

So this case is when all the roles of registrar, authoritative proxy
and edge proxy are colocated, right ?

If so, then I propose the text to be written like this:

   If the proxy is colocated with the registrar which stored in 
   the binding the information about its direct flow to the UA,
   then the proxy MUST send the request over the same 'logical 
   flow' saved with the binding ...

How would that sound ?

Regards,

Erkki

>-----Original Message-----
>From: ext Rohan Mahy [mailto:[email-masked]] 
>Sent: 21.November.2007 18:20
>To: Koivusalo Erkki (Nokia-BI/Espoo)
>Cc: Rohan Mahy; [email-masked]; [email-masked]
>Subject: Re: [Sip] Few comments to draft-ietf-sip-outbound-11
>
>