[reSIProcate] route set when establishing dialog
Robert Sparks
rjsparks at nostrum.com
Mon Oct 1 13:12:20 CDT 2007
On Oct 1, 2007, at 1:09 PM, Scott Godin wrote:
> 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?
My guess is to use the routeset from the first provisional and not
change it until the 200, but I don't feel strongly about it. Does
anyone else have a strong opinion?
>
> Scott
>
>> -----Original Message-----
>> From: Robert Sparks [mailto:rjsparks at nostrum.com]
>> Sent: Monday, October 01, 2007 1:55 PM
>> To: Scott Godin
>> Cc: Jesus Monzon Legido; resiprocate-devel at list.resiprocate.org
>> 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 at list.resiprocate.org
>>>> [mailto:resiprocate-devel-bounces at list.resiprocate.org] On
>>>> Behalf Of
>>>> Jesus Monzon Legido
>>>> Sent: Tuesday, September 11, 2007 5:55 AM
>>>> To: resiprocate-devel at list.resiprocate.org
>>>> 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 at list.resiprocate.org
>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>
>>> _______________________________________________
>>> resiprocate-devel mailing list
>>> resiprocate-devel at list.resiprocate.org
>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
>
More information about the resiprocate-devel
mailing list