[reSIProcate] route set when establishing dialog
Robert Sparks
rjsparks at nostrum.com
Mon Oct 1 12:55:22 CDT 2007
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