Some updates to my own previous comments. I have found answers to some of the questions, so I have removed them.
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. --------------------------- 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 _______________________________________________ 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
