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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
