On Nov 21, 2007, at 12:25 AM, <Erkki.Koivusalo nokia.com> wrote:
>
> Hi,
>
> First of all, in my opinion outbound-11 looks good.
> It has improved a lot from the previous version and
> properly addressed many comments given in August
during
> WGLC.
>
> After reading the draft I found a few things for which
> I would seek further clarification. Some of those were
> already initially raised in WGLC and the other minor
> issues are due to the new text appeared in version 11.
>
> 1. Why should the registrar store the time of updating
> the binding ?
>
> Section 6. Registrar mechanisms tells the following:
>
> The registrar MUST store in the binding the Contact
URI,
> all the Contact head field parameters, and any Path
header field
> values and SHOULD also store the time at which the
binding was last
> updated.
>
> 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 which purpose is this stored time used ? In my
understanding
> such a stored time is not needed for replacing older
bindings and
> I could not come up with any other reason either to
store the time.
>
> As the draft tells elsewhere "[when the] reg-id
values [coming from
> the UA within REGISTER request] will collide with the
previously
> used reg-id values [stored earlier along the binding]
the registrar
> can replace the older registrations". The time of
any previous update
> should not matter.
There are three reasons, but all of them are a bit dubious.
a) RFC 3261 recommends keeping this information, but does
not say why
b) This was needed in a previous version of outbound
c) GRUU uses this in the temporary GRUU invalidation
procedure.
However, this is an open issue for GRUU and outbound. I
will send
mail about this soon.
The short answer is that it can probably be removed.
> 2. How to respond if UA requires Outbound but the proxy
does
> not support it even if the registrar does ?
>
> How should the registrar respond to a REGISTER request
when:
>
> - REGISTER contains Require: Outbound and reg-id in
Contact
>
> - Registrar itself supports Outbound
>
> - Via header of REGISTER indicates that there is a
proxy between
> the UA and registrar, but the proxy has not included
either the
> Path header or 'ob' parameter to its URI within the
Path ?
I looked for an appropriate error message for this and it
was quite a
puzzler. 420 is clearly not appropriate. I was planning to
investigate if 488 Not Acceptable Here or 580 Precondition
Failed
could be reused for this purpose. I am not really keen on
adding a
new response code though. A 400 Bad Request would be
appropriate but
not especially helpful.
> 3. Completing the removal of TCP keepalive from the
draft
>
> As all the other references to TCP keepalive have now
been removed
> from the draft, then please remove also this one from
section
> Section 3.5. Keepalive Technique:
>
> transports such as TCP and SCTP, this specification
describes a
> keepalive approach based on sending CRLFs, *and for
TCP, a usage of
> TCP transport-layer keepalives*.
Thanks
> 4. Ambiguous text in section 7
>
> Section 7. Authoritative Proxy Mechanisms: Forwarding
Requests tells:
>
> If the proxy doubles as a registrar and stored
information about
> the
> flow that created the binding, then the proxy MUST
send the request
> over the same 'logical flow' saved with the
binding,
>
> Sorry but I do not understand what is meant by:
"If the proxy doubles
> as a registrar and stored information about the flow
that created the
> binding" Proxy 'doubling as a registrar' sounds
odd (which might
> be due
> to my poor skills of English ...) Could you please
clarify this ?
Sure. This is the case where the authoritative proxy and
registrar
roles are implemented in the same SIP implementation. The
flow was
stored by the "registrar" but the
"authoritative proxy" performs the
lookup function and routes to the registered UA over the
saved flow.
This was actually a suggestion from Byron Cambell which
seemed much
less cumbersome from the previous text, but clearly it could
use some
additional rewording. Feel free to propose something.
thanks,
-rohan
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
