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

From: <[email-masked]>
Date: Thu, 2 Aug 2007 14:03:05 +0300

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."

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."

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.

- 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.

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.

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.

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