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

From: <[email-masked]>
Date: Wed, 1 Aug 2007 17:34:27 +0300

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

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.  

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

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.

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.

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.

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

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

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.

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. 

========

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