Re: [reSIProcate] route set when establishing dialog
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
> ********************************************************************cha
> 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