Re: [reSIProcate] route set when establishing dialog
Thanks Robert.
All of this code is in the Dialog class - so we are definitely working in the
same dialog. : )
I can fix resip so that the if the route-set in the 200 (to the initial invite)
is empty then it will overwrite any existing routeset.
Should I also modify it to update the routeset on all provisional responses
received? Or just leave it to use the routeset from the first provisional
until the 200 arrives? Which do you think is more interoperable?
Scott
> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@xxxxxxxxxxx]
> Sent: Monday, October 01, 2007 1:55 PM
> To: Scott Godin
> Cc: Jesus Monzon Legido; resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] route set when establishing dialog
>
> Sorry for being so slow to respond to this.
>
> 3261 is pretty clear about not changing the routeset once it's
> confirmed by a response to an initial invite.
> Its not as clear about what happens with provisional responses to
> that invite though - the intent at the time
> (though it was probably not thought about much) was that the first
> message that established the route set
> put it in stone. I suspect that you could find a group (likely
> motivated by IMS) that would argue for different
> behavior now, but the short answer is that it's not well specified.
>
> That said, I think the current code's motivation is to be as
> interoperable as possible, taking into account
> both elements that have interpreted the spec badly and those that are
> flat broken (in particular, those
> that don't return record-route in provisional responses even if they
> were there in the INVITE). Given that
> particular use case, I think we should continue to overwrite whatever
> we saw in a 1xx with what's in the 2xx
> (even if that's empty). And it would be good to inspect the code
> again and make triple-sure that we're talking
> about the 2xx that's on the same dialog (same remote-tag) as the 1xx.
>
> BTW - the text Scott quotes below about "pre-existing rout set"
> replacement is talking about route sets that
> came from configuration or from Path or Service-Route - not route
> sets that happened because of earlier
> responses to an initial INVITE.
>
> Now - It would be a mistake to take a different record route out of a
> retransmission of a 200 ok. That opens a big big big
> security hole that we can't close with the tools that exist today.
> (Again, be sure its a retransmission and not a 200 ok from
> another leg).
>
>
> In the long run, I believe 3261s RR fixing behavior is broken and
> hope to convince a critical mass of IETFers
> to change it so that you update on mid-dialog transactions too, but
> that's not going to happen in any near-term timeframe.
>
> RjS
>
> On Sep 14, 2007, at 8:43 AM, Scott Godin wrote:
>
> > Thanks for pointing this out.
> >
> > OK - so from what I can see from the code, DUM currently sets the
> > route set on the first dialog creating provisional response, and
> > updates it on any 200 response received to the initial invite (but
> > only if non-empty in the 200). I think we definitely have some
> > issues here.
> >
> > A careful read through RFC3261 seems to indicate that we should be
> > updating the routeset on every in-dialog response to the initial
> > invite (even if it is empty). With the final update being on the
> > 200 response to initial invite (even if empty). What is unclear is
> > what we should do if we receive a re-transmission of that 200
> > response. Technically it should contain the exact same routeset,
> > so we shouldn't need to worry - but I guess we have at least one
> > case where this is not true.
> >
> > Any opinions? I can commit a fix if we all agree on this. : )
> >
> > Scott
> >
> > FYI - Text in 12.1.2 - UAC Behavior is:
> > The route set MUST be set to the list of URIs in the Record-Route
> > header field from the response, taken in
> > reverse order and preserving all URI parameters. If no Record-Route
> > header field is present in the response,
> > the route set MUST be set to the empty set. This route set, even if
> > empty, overrides any pre-existing route set
> > for future requests in this dialog. The remote target MUST be set
> > to the URI from the Contact header field
> > of the response.
> >
> >
> >> -----Original Message-----
> >> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx
> >> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of
> >> Jesus Monzon Legido
> >> Sent: Tuesday, September 11, 2007 5:55 AM
> >> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> >> Subject: [reSIProcate] route set when establishing dialog
> >>
> >> Hi,
> >>
> >> I faced an strange behaviour when trying to establish an INVITE
> >> dialog
> >> using resiprocate (DUM) as a client:
> >> - Being my client the sender of the initial invite, it sent
> >> several
> >> restransmissions of the initial invite
> >> - It was answered with several 200OK, all of them with Record-
> >> Route
> >> headers, that should be used to learn the Route Set for the
> >> dialog (as
> >> rfc 3261, 13.2.2.4 says). Some of these 200Ok have different Recor-
> >> Route values (even the other parts of the msg are exactly the same).
> >> - Even it is somehow a fault on the other side (they should be a
> >> all a retransmission of the same 200OK) it led DUM to recompute and
> >> learn a different Route Set for each RESPONSE received.
> >> - The later can be true while the dialog has not yet received a
> >> final response (the route set in a final response, even empty,
> >> prevails
> >> over the provisional ones)
> >> - As far as I know, the route set (once it has been set) cannot
> >> change during the lifetime of a dialog (rfc 3261, 13.2.2.4).
> >>
> >> - If I am right, Dialog class should be modified in order to
> cope
> >> with this condition. My solution is something like the following
> >>
> >> void
> >> Dialog::dispatch(const SipMessage& msg)
> >> {
> >> (...)
> >> const SipMessage& response = msg;
> >> int code = response.header(h_StatusLine).statusCode();
> >> // If this is a 200 response to the initial request, then
> store
> >> the routeset (if present)
> >> BaseCreator* creator = mDialogSet.getCreator();
> >> if (creator && (creator->getLastRequest()->header(h_CSeq) ==
> >> response.header(h_CSeq)) && code >=200 && code < 300)
> >> {
> >> {
> >> //
> >>
> [********************************************************************
> >>
> changed**************************************************************
> >> **
> >> ****]
> >> if (mType == Invitation)
> >> {
> >> if ( (mInviteSession == NULL) || mInviteSession-
> >> >isEarly())
> >> {
> >> mRouteSet =
> >> response.header(h_RecordRoutes).reverse();
> >> }
> >> else
> >> {
> >> DebugLog ( << "Dialog::dispatch -- Route set
> >> is not
> >> taken" );
> >> }
> >> }
> >> else
> >> { //provisional responses are only meaningful on INVITE
> >> if ((code / 100 == 2) && mRouteSet.empty() &&
> >> response.exists(h_RecordRoutes))
> >> {
> >> mRouteSet = response.header
> >> (h_RecordRoutes).reverse();
> >> }
> >> }
> >> } //[end
> >>
> ********************************************************************c
> >> ha
> >>
> nged*****************************************************************
> >> **
> >> *]
> >> }
> >>
> >> - Does anybody faced before this strange scenario? How do you
> >> solve
> >> it?
> >>
> >> - Could my changes be right
> >>
> >> Thank you,
> >> /Jesus
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> _____________________________________________________________________
> >> __
> >> _____________
> >> Sé un Mejor Amante del Cine
> >> ¿Quieres saber cómo? ¡Deja que otras personas te ayuden!
> >> http://advision.webevents.yahoo.com/reto/entretenimiento.html
> >> _______________________________________________
> >> resiprocate-devel mailing list
> >> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> >> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>