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

From: Rohan Mahy <[email-masked]>
Date: Sat, 1 Dec 2007 09:53:23 -0800

Hi Erkki,

I largely used your text for a reworded section 6, except that the  
text deals with the binding rules for GRUU as well as outbound.

I believe all your points are addressed in outbound-11.

more inline.

On Aug 1, 2007, at 7:34 AM, <[email-masked]>  
<[email-masked]> wrote:
>
> Hi,
>
> Here are my comments regarding to the behaviour of the registrar
> as specified within SIP Outbound-10.
>
> As a summary, it seems to me that section 6 would need substantial
> changes to become clearer. I am sorry to not find and point all that
> out until WGLC. To compensate I tried to rework section 6 and you
> can find the result in the end of this email. Please use for version
> 11, if you find it useful.
>
>
> 3.1.  Summary of Mechanism
>
> Nit:
>
>    "The registrar can use the reg-id label to
>    recognize that a UA is registering after a reboot or a network
>    failure."
>
> In practice the registrar can not detect from the reg-id
> if the UA is just refreshing an existing registration or
> registering after a reboot or other failure. Thus my suggestion
> is to replace that sentence with this one: "The registrar can
> use the reg-id label to recognize whether an UA is creating a
> new flow or refreshing an existing flow, possibly after a reboot
> or a network failure."

incorporated

> 6.  Registrar Mechanisms
>
> Nit:
>
>    "When no +sip.instance media feature parameter is present in a
> Contact
>    header field value in a REGISTER request, the corresponding binding
>    is still between an AOR and the URI from that Contact header field
>    value."
>
> I believe this statement should be dropped from the spec as it does
> not tell anything new compared to RFC 3261. But if the idea is rather
> to tell what the registrar should do if the Contact contains reg-id
> but does not contain the +sip.instance, then the statement has to be
> clarified to point that out. In my opinion the statement is not needed
> even for this latter case as the section 6 covers that case later.

this was confusing to others, so I have left it in place.

> Nit:
>
>    "When a +sip.instance media feature parameter is present in a
>    Contact header field value in a REGISTER request, the corresponding
>    binding is between an AOR and the combination of the instance-id
>    (from the +sip.instance media feature parameter) and the value of
>    reg-id parameter if it is present."
>
> As GRUU specifies what the registrar should do when the Contact
> header contains +sip.instance without reg-id, this statement should
> more clearly focus to the case when Contact has both of them. I  
> suggest
> rewrite like this: "When both +sip.instance media feature parameter
> and reg-id parameter are present in a Contact header field of
> a REGISTER request, the corresponding binding is between an AOR and
> the combination of the instance-id (from the +sip.instance media
> feature parameter) and the value of reg-id parameter." With the
> current formulation the statement is a bit open-ended and leaves the
> reader to wonder what might happen if reg-id parameter is not present
> (which is the case in GRUU).

the outbound spec is supposed to define the new binding behavior for  
both GRUU and outbound-style registrations.

> Nit:
>
>    "A Contact header field value with an instance-id but no reg-id is
> valid"
>
> An informative reference to GRUU would be helpful here.

done.

> Minor technical:
>
>    "For a binding with an
>    instance-id, the registrar still stores the Contact header field
>    value URI with the binding, but does not consider the Contact  
> URI for
>    comparison purposes."
>
> Why does the registrar has to store the URI ? To which purpose it
> will be used ? If there is no explicit purpose for storing the URI
> I suggest dropping that statement and reformulating this one: "The
> registrar MUST also store all the Contact header field information"
> just to require storage all the Contact header parameters, not URI.

The registrar has to store the URI so the authoritative proxy can  
place the URI in the Request-URI (retarget) when it forwards the  
request. This URI is not used for next hop routing however.

> Major technical:
>
>    "Specifically, if it ignores the 'reg-id' parameter the registrar
> MUST
>    use RFC 3261 Contact binding rules"
>
> What happens if the UA is requesting both Outbound and GRUU behavior
> in its REGISTER request, but the edge proxy does not support  
> Outbound ?
> The statement above in the Outbound seems to suggest that the  
> registrar
> will not deliver even the GRUUs (and store the instance-Id with AOR as
> specified for GRUU), which however does not sound correct to me.  
> Instead
> the UA should get its GRUUs and the registrar should use binding rules
> specified in GRUU spec.

A registrar which supports GRUU MUST also support outbound.  If the  
UA requests outbound, it is highly likely that the GRUU will be  
unusable anyway.

> Nit:
>
>    "If a Path header field is present, RFC 3327 [5] requires the
> registrar
>    to store this information as well."
>
> Why to repeat this in Outbound ? I suggest dropping it and only  
> leaving
> the statement given earlier in the same section: "Registrars which
> implement this specification MUST support the Path header mechanism
> [5]."

I left this in place as a reminder to implementors. Several  
implementors contacted me privately asking what information the  
registrar needs to store.  With this text, that information is in one  
place.

> Major technical:
>
>    "and MUST NOT include the 'outbound' option-tag in its Supported
> header
>     field."
>
>    "The Registrar MUST include the 'outbound' option-tag (defined in
>    Section (Section 12.1)) in a Supported header field value in its
>    responses to REGISTER requests for which it has performed outbound
>    processing"
>
> It was stated already earlier the registrar must add the tag into
> the Require header (and may also add it into Supported header).

fixed

> Nit:
>
>    "and MUST NOT include this option-tag if it did not
>    perform outbound processing.  Furthermore, the Registrar MUST NOR
>    include this option-tag in its response if the Registrar skipped
>    outbound processing by ignoring the reg-id parameter as  
> described in
>    this specification."
>
> The text above unnecessarily says the same thing twice.
> Statement starting with word "Furthermore" is redundant and
> should be deleted.

fixed.

> Nit:
>
>    "The registrar MUST also store all the Contact header field
>    information including the reg-id and instance-id parameters and
>    SHOULD also store the time at which the binding was last updated."
>
> It is not logical to have this statement in the middle of the text
> which discusses what the registrar should do if it has a direct flow
> with the UA.

moved.

thanks,
-rohan

> ========
>
> Here is the reworked text for section 6. It is at least shorter
> than the original version without any loss of functionality. I also
> believe that the structure has become much clearer during the rewrite
> and consists now of the following steps:
> 	
> 	a) Validation of Contact header (with help of Via and Path)
> 	   and decision whether to use Outbound or not
>
> 	b) Creating bindings for Contacts with reg-id and instance-id
> 	   and responding to the UA
>
> 	c) Maintenance of flows and registration refreshes
>
> 	d) Support for keepalives
>
>
> 6.  Registrar Mechanisms: Processing REGISTER Requests
>
>    This specification updates the definition of a binding in RFC 3261
>    [1] Section 10 and RFC 3327 [5] Section 5.3.
>
>    Registrars which implement this specification MUST support the Path
>    header mechanism [5].
>
>    When receiving a REGISTER request, the registrar first checks from
>    its Via header field if the registrar is the first hop or not. If
>    the registrar is not the first hop, it examines Path header of the
>    request. If the Path header field is missing or it exists but the
>    first URI does not have an 'ob' URI parameter, the registrar MUST
>    ignore the reg-id parameter of the Contact header.
>
>    A Contact header field value with an instance-id but no reg-id is
>    valid (as specified in GRUU [25]), but one with a reg-id but no
>    instance-id is not.  If the registrar processes a Contact header
>    field value with a reg-id but no instance-id, it simply ignores
>    the reg-id parameter.
>
>    If the Contact header did not contain 'reg-id' parameter or if that
>    parameter became ignored (as described above) the registrar MUST  
> NOT
>    apply any outbound processing for the request. Specifically,
> registrar
>    MUST NOT include the 'outbound' option-tag in the Require header
> field
>    of its response and it MUST use Contact binding rules of GRUU  
> [25] or
>
>    RFC 3261 [1], depending whether or not the Contact header contains
>    +sip.instance media feature parameter.
>
>    The registrar MUST be prepared to receive, simultaneously for the
>    same AOR, some registrations that use instance-id and reg-id and
>    some registrations that do not. The Registrar MAY be configured
>    with local policy to reject any registrations that do not include
>    the instance-id and reg-id, or with Path header field values that
>    do not contain the 'ob' parameter.
>
>    When both +sip.instance media feature parameter and reg-id  
> parameter
>    are present in a Contact header field of a REGISTER request (after
>    the Contact header validation as described above), the  
> corresponding
>    binding is between an AOR and the combination of the instance-id
>    (from the +sip.instance media feature parameter) and the value of
>    reg-id parameter. The registrar MUST store all the Contact  
> parameters
>
>    in the binding and SHOULD also store the time at which the binding
>    was last updated. Further on the Registrar MUST include the
> 'outbound'
>    option-tag (defined in Section (Section 12.1)) into a Require  
> header
>    field value in its response to the REGISTER request.
>
>    If the UAC has a direct flow with the registrar, the registrar MUST
>    store enough information to uniquely identify the network flow over
>    which the request arrived.  For common operating systems with TCP,
>    this would typically just be the handle to the file descriptor  
> where
>    the handle would become invalid if the TCP session was closed.  For
>    common operating systems with UDP this would typically be the file
>    descriptor for the local socket that received the request, the  
> local
>    interface, and the IP address and port number of the remote side  
> that
>    sent the request.  The registrar MAY store this information by  
> adding
>    itself to the Path header field with an appropriate flow token.
>
>    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 be compliant with this specification, registrars which can  
> receive
>    SIP requests directly from a UAC without intervening edge proxies
>    MUST implement STUN NAT Keepalives on its SIP UDP ports as  
> described
>    in Section 8 and when it receives a double-CRLF sequence on a
>    connection oriented transport such as TCP or SCTP, it MUST
>    immediately respond with a single CRLF over the same connection.
>
>
> 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