[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] gruu in outbound-15 9.1
Hi,
I have to admit that I have missed the addition of the possibiliy to
establish non-registration outbound flows using dialog-forming requests.
However, I unfortunately think that is going to require some more
editorial work to the spec, because parts of the documents talk about
the registation case, and some procedures seem to assume that
registrations are used, so maybe clarifications are needed that some
procedures only apply to the registration case.
---------------------------
Subclause 1 says:
"The key idea of this specification is that when a UA sends a REGISTER
request or a dialog-forming request, the proxy can later use this
same network "flow"--whether this is a bidirectional stream of UDP
datagrams, a TCP connection, or an analogous concept in another
transport protocol--to forward any incoming requests that need to go
to this UA in the context of the registration or dialog.
The text is a little confusing. It starts by talking about when a UA
sends a REGISTER, and at the end it talks about the context of a dialog.
You probably need to e.g. split the text into two parts - one talking
about the registration case, and one talking about the dialog case.
---------------------------
Subclauses 2.1 says:
"ob Parameter: The 'ob' parameter is a SIP URI parameter which has
different meaning depending on context. In a Path header field
value it is used by the first edge proxy to indicate that a flow
token was added to the URI. In a Contact or Route header field
value it indicates that the UA would like other requests in the
same dialog routed over the same flow."
First, I assume it refers to a Contact or Route header inserted by the
UAC in the dialog, so maybe that needs to be clarified.
Second, I assume the only time the UAC will insert the parameter in a
Route header is when it was sent beck in a Path header?
---------------------------
Subclause 3.1 says:
"When sending a dialog-forming request, a UA can also ask its first
edge proxy to route subsequent requests in that dialog over the same
flow. This is necessary whether the UA has registered or not."
Why is this necessary when the UA is registered? Won't requests then
automatically be delivered over the registered flow?
---------------------------
Also, are keep-alives sent on dialog-forming requests? The text in the
last paragraph of subclause 1 seems to indiate so.
But, the non-registration flow examples don't show any keep-alives.
Also, subclause 3.5 says:
"When the UA detects that a flow has failed or that the flow definition
has changed, the UA needs to re-register..."
Is that true if the flow was established using a dialog-forming request?
What if the UA isn't registerded in the first place...? I guess
subclause 4.5 clarifies that this only applies to registation flows, but
it would also need to be claified here.
Also, subclause 3.5.1 says:
"If the client does not receive a pong in response to its ping, it
declares the flow dead and opens a new flow in its place."
How will that be done if the flow was established using a dialog-forming
request? Will the new flow be esablished by transfering the existing
dialog?
---------------------------
Subclause 4.2.1 talks about the case when the UAC recieves a 439
resposne for the REGISTER request. But, can't it receive 439 also if it
tries to estblish the flow using a dialog-establisment request?
---------------------------
Regards,
Christer
-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
Francois Audet
Sent: Saturday, October 04, 2008 12:57 AM
To: Dean Willis
Cc: SIP IETF
Subject: Re: [Sip] gruu in outbound-15 9.1
Thanks Dean.
This text seems perfect to me. I'll deal with it in WGLC.
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis at softarmor.com]
> Sent: Thursday, October 02, 2008 16:59
> To: Audet, Francois (SC100:3055)
> Cc: Juha Heinanen; SIP IETF
> Subject: gruu in outbound-15 9.1
>
> >
>
> Original text:
>
>
> > If the UAC is sending a dialog-forming request, and wants all
> > subsequent requests in the dialog to arrive over the same
> flow, the
> > UAC adds an 'ob' parameter to its Contact header.
> Typically this is
> > desirable, but it is not necessary for example if the Contact is a
> > GRUU [I-D.ietf-sip-gruu]. The flow used for the request is
> typically
> > the same flow the UA registered over, but it could be a new
> flow, for
> > example the initial subcription dialog for the configuration
> > framework [I-D.ietf-sipping-config-framework] needs to
> exist before
> > registration.
>
>
> Proposed text:
>
> Typically, a UAC using the procedures of this document and sending a
> dialog-forming request will want all subsequent requests in the dialog
> to arrive over the same flow. If the UAC is using a GRUU
> [I-D.ietf-sip-gruu] that was instantiated using a Contact header field
> value that included an "ob"
> parameter, the UAC sends teh request over the flow used for
> registration and susequent requests will arrive over that same flow.
> If the UAC is not using such a GRUU, then the UAC adds an "ob"
> parameter to its Contact header field value.
> This will cause all subsequent requests in the dialog to arrive over
> the flow instantiated by the dialog-forming request. This case is
> typical when the request is sent prior to registration, such as in the
> the initial subcription dialog for the configuration framework
> [I-D.ietf-sipping-config-framework].
>
>
> --
> Dean
>
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
sip-implementors at cs.columbia.edu for questions on current sip Use
sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip