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