Hi Rohan,
Thanks for your answers. Please find my proposal for section
7 below:
>> 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.
So this case is when all the roles of registrar,
authoritative proxy
and edge proxy are colocated, right ?
If so, then I propose the text to be written like this:
If the proxy is colocated with the registrar which stored
in
the binding the information about its direct flow to the
UA,
then the proxy MUST send the request over the same
'logical
flow' saved with the binding ...
How would that sound ?
Regards,
Erkki
>-----Original Message-----
>From: ext Rohan Mahy [mailto:rohan ekabal.com]
>Sent: 21.November.2007 18:20
>To: Koivusalo Erkki (Nokia-BI/Espoo)
>Cc: Rohan Mahy; fluffycisco.com; sipietf.org
>Subject: Re: [Sip] Few comments to
draft-ietf-sip-outbound-11
>
>
>On Nov 21, 2007, at 12:25 AM, <Erkki.Koivusalonokia.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
|