Subject: Re: [Sip] WGLC comments on sip-outbound-10: behaviour of the UA

From: Rohan Mahy <[email-masked]>
Date: Sat, 1 Dec 2007 10:24:39 -0800

Hi Erkki,

I believe your comments have been addressed except for the question  
of which error response to send a registration Requires outbound, but  
the ob parameter is missing from the 1st Path header.  In addition,  
the invalidation of temporary GRUU I have raised as an open issue,  
although the text in -11 will behave nicely with the current GRUU spec.

See inline for more.

thanks,
-rohan

On Aug 2, 2007, at 4:03 AM, <[email-masked]>  
<[email-masked]> wrote:
>
> Hi,
>
> Here are my comments regarding to the behaviour of the UA
> as specified within SIP Outbound-10. I also hope that these
> would be my final comments for this WGLC.
>
> 4.1.  Instance ID Creation
>
> Nit:
>
> I suggest renaming section 4.1 as "Instance ID Creation and Usage"
> as the section also discusses how to convey the ID in requests and
> responses.
>
> Minor technical:
>
>    "To convey its instance-id in both requests and responses, the UA
>    includes a "sip.instance" media feature tag as a UA characteristic
>    [7] .  As described in [7], this media feature tag will be  
> encoded in
>    the Contact header field as the "+sip.instance" Contact header  
> field
>    parameter.  The value of this parameter MUST be a URN [8].  One  
> case
>    where a UA may not want to include the URN in the sip.instance  
> media
>    feature tag is when it is making an anonymous request or some other
>    privacy concern requires that the UA not reveal its identity."
>
> It sounds odd to state that the value of sip.instance parameter MUST
> be URN but tell that there is a case when a UA would not want to
> include URN into that parameter. The last statement should instead
> tell that the UA is free not to include sip.instance media tag (but
> if it includes it, the value must always be URN). I suggest rephrasing
> the  paragraph like this:
>
> "To convey its instance-id in both requests and responses, the UA
> MAY add a "sip.instance" media feature tag as a UA characteristic
> [7]. As described in [7], the media feature tag will be encoded in
> the Contact header field as the "+sip.instance" Contact header field
> parameter.  The value of this parameter MUST be a URN [8]. A UA MAY
> decide not to add the sip.instance media feature tag e.g. when it is
> making an anonymous request or some other privacy concern requires
> that the UA not reveal its identity."

This section was updated based on feedback from the apps area and the  
URI mailing list.  Now it MUST be a URN specifically described for  
use with outbound in an IETF-consensus RFC.  The UUID is the only one  
currently defined. if the IETF defined an IMEI URN for example, that  
spec could allow its use with outbound.

> 4.2.  Registrations
>
> Nit:
>
>    "These ordinary registration requests include a distinct reg-id
>    parameter in the Contact header field."
>
> Propose to rewrite the statement like this: "REGISTER requests sent
> towards different URIs within the outbound-proxy-set MUST include
> the reg-id parameter into the Contact header field, with a distinct
> reg-id value for each proxy."

I believe the text now in -11 (sect 4.2 para 4) is appropriate.

> Major technical:
>
>       "The UAC can situationally decide whether to request outbound
>       behavior by including or omitting the 'reg-id' parameter.  For
>       example, imagine the outbound-proxy-set contains two proxies in
>       different domains, EP1 and EP2.  If an outbound-style  
> registration
>       succeeded for a flow through EP1, the UA might decide to include
>       'outbound' in its Require header field when registering with  
> EP2,
>       in order to insure consistency.  Similarly, if the registration
>       through EP1 did not support outbound, the UA might decide to  
> omit
>       the 'reg-id' parameter when registering with EP2."
>
> To me this paragraph sounds dangerous and I suggest removing it
> for the following reasons:
>
> - It is not specified anywhere what the registrar should do if
>   it finds a REGISTER request to contain Require: outbound in a
>   case where the reg-id will be ignored due to the proxy not
>   supporting outbound. Intuitively the registrar should reject
>   the REGISTER with an error response, but which one ? Using
>   420 Bad Extension is not according to RFC 3261, since the
>   registrar supports Outbound but would just like to tell that
>   it can not apply it since the first hop proxy did not support
>   Outbound. More text is needed into the spec if a REGISTER
>   request is allowed to use Require: Outbound.

This is currently an open issue. One way to resolve this is to say  
that UAs must not include Require: outbound in a REGISTER request. A  
survey of error codes does not give an obvious answer. 420 is clearly  
wrong however. Precondition failed looked like a dubious possibility.

> - If a registration through EP1 did not support outbound, then
>   I would believe the UA should not try to register via EP2 at
>   all. Otherwise the authoritative proxy could fork an incoming
>   request to the a multihomed UA via both EP1 and EP2, which
>   is not desirable. And if the UA is not multihomed then this
>   kind of double registration without Outbound does not make sense.

This text was fixed so the UA does not register via EP2 at all.

> Major technical:
>
>    "The UAC MAY examine successful registrations for the presence  
> of an
>    'outbound' option-tag in a Supported header field value.   
> Presence of
>    this option-tag indicates that the registrar is compliant with this
>    specification, and that any edge proxies which need to participate
>    are also compliant."
>
> As stated earlier, registrar will use Require header for this purpose.

fixed

> 9.  Example Message Flow
>
> Minor technical:
>
>    "The second registration in message 3 and 4 are similar other than
> the
>    Call-ID has changed, the reg-id is 2, and the route is set to the
>    secondary instead of the primary."
>
>    "The registrations in message 13 and 14 are the same as message  
> 1 and
>    2 other than the Call-ID and tags have changed.  Because these
>    messages will contain the same instance-id and reg-id as those in 1
>    and 2, this flow will partially supersede that for messages 1 and 2
>    and will be tried first by Primary."
>
> In the examples the UA is changing the Call-ID for every successive
> REGISTER request. What is the reason for the UA to do that ?
> The normative text for neither the UA nor the registrar suggest
> any that kind of behaviour. If the UA and registrar use GRUU
> this would cause the temporary GRUUs to be invalidated and I
> do not think the purpose of this example would be to implicate
> any such behavior for case when UA is using Outbound.

I have changed the behavior so the Call-IDs do not change, however I  
think this is bad behavior and that the GRUU spec should be changed  
to keep temporary GRUUs as long as a new registration comes form any  
previously used Call-ID.

thanks,
-rohan

> Regards,
> Erkki

_______________________________________________
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