[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] NOTIFY establishes a dialog
Hi Robert,
> 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?)
First, if we use connection protocols, with or without security (TCP, TLS etc), nodes may have to establish two connections (if the next hop is different in the early- and confirmed route sets). This affects, of course, both UAs and proxies.
Second, since we are not allowed to change the route once the dialog has been "confirmed", there may be proxies which checks the route for incoming request. And, those proxies may not know the semantics of PRACK, so they may think the request is for the confirmed dialog, and reject it
because it tries to use another route.
Third, this MAY also affect other early dialog requests (UPDATE, INFO), which due to race conditions are sent after the dialog has been confirmed. >From a proxy point of view, however, I guess this is not different from the PRACK case.
Fourth, but this I haven't thought so much about yet, could this somehow affect the work on connection reuse?
> 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.
Personally I don't see any reason why it should be allowed in the first place. Because, we are NOT allowed to change the Contact header in 18x and 200 responses, are we? So, why should we be allowed to change Record-Route?
Of course, IF someone has reasons why proxies should be involved only in the early state, or in the confirmed state, that is another issue, but in the case the question is if we should have a generic way of changing the route set - also after the dialog has been confirmed (Juha
mentioned cases where such functionality could be useful).
Regards,
Christer Holmberg
Ericsson Finland
> (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