[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] NOTIFY establishes a dialog



Nice question.

>From a constructionist view, the PRACK is clearly associated with the
early dialog and should use the early dialog route set. From a practical
point of view, using either the early or confirmed route set gets the
PRACK to the place that needs it, so what does it matter? (Can you
construct a case where a proxy would care?)

I think, though, that the idea that the early and established route
sets can be different is just an artifact of the way we defined
record-route rewriting instead of a feature we really intended to
engineer. (If someone knows differently, please speak up). The
double-record-route solution for those cases where rewriting
is necessary would allow the RR field in a response to be signed.
That would _prevent_ the early and confirmed route sets from being
different. I suspect that's a more desired behavior.

So to answer your question more succinctly:
 - I don't think it matters which you use
 - The potential difference should go away anyhow

RjS

On Thu, 2003-03-20 at 21:49, Christer Holmberg wrote:
> Hi Robert,
> 
> > >From rfc3261 page 82:
> >
> >    If the dialog identifier in the 2xx response matches the dialog
> >    identifier of an existing dialog, the dialog MUST be transitioned to
> >    the "confirmed" state, and the route set for the dialog MUST be
> >    recomputed based on the 2xx response using the procedures of Section
> >    12.2.1.2.  Otherwise, a new dialog in the "confirmed" state MUST be
> >    constructed using the procedures of Section 12.1.2.
> >
> > In context, you'll see the "existing dialog" above is an "early dialog".
> 
> Chapter 4 in RFC3262 says:
> 
> "The UAC MAY acknowledge reliable provisional responses received after
> the final response or MAY discard them."
> 
> Now, IF the UAC chooses to acknowledge reliable provisional responses after the final response is received, which route set should it use for the PRACK? The route set it used for the other PRACKs in the "early state", or the possible new route set is has for the "confirmed state"?
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip