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