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