[Serusers] Max-Forwards missing in SER CANCEL during forking

[Jiri Kuthan]

Andres wrote:
> Jiri Kuthan wrote:
> 
>>
>> Try to set parameter tm/reparse_invite to 1 -- I was not aware of the 
>> option
>> but the code seems to adopt more message pieces including MF than if 
>> the parameter
>> is set to 0.
> 
> I could not find that parameter in the code for 0.9.6 or 0.9.7.  Where 
> did you see it?


My bad, I forgot the version number. Unfortunately 0.9.6 doesn't have it.
It would be probably helpful anyhow to use some release that's not as
old as four years; otherwise you are left with backporting or otherwise
fixing. I'm not aware of an easier fix (like by the way of scripting).

> 
>>
>> BTW was this an esthetic thing or did actually the CANCEL result in a 
>> loop?
>> I could have imagined that the downstream hop absorbs the CANCEL at 
>> transaction
>> level and the CANCEL follows the INVITE path, therefore not looping 
>> unless INVITE
>> did too.
> 
> It resulted in established calls being dropped.  Here is why:
> 1)  In a parallel fork scenario one endpoint answered the call and the 
> others receive the SER CANCEL
> 2)  One of the endpoints rejects the SER CANCEL with a "SIP/2.0 400 Bad 
> Request" (because of the missing mandatory Max-Forwards header)
> 3)  40 seconds later that endpoint sends a "SIP/2.0 480 Temporarily 
> Unavailable" to SER
> 4)  SER Forwards that message to our gateway which cuts off the already 
> established call.


OK interesting :-) The UAS apparently should not send two different
negative answer (not speaking of the very basic commandment to be liberal
receiver) , and UAC should not respond to UAS's negative answer
by terminating an established dialog with another UAS with a different
to-tag.

> 
> Any other suggestions?  We have been running the 0.9.6 version for many 
> years and its solid as a rock.  We do not want to explore the possibilty 
> of upgrading at this point.

Glad 0.9.6 is working for you so well.
Unfortunately I have no better idea than backporting the code in question.
Not sure if you are in position to change the UAC and UAS, apparently there
is a great improvement in their space as well.

-jiri

> 
> Thanks,
> Andres
> http://www.telesip.net
> 
>>
>> -jiri
>>
>> Andres wrote:
>>
>>> Hi,
>>>
>>> We encountered an issue in 0.9.6 when SER forks requests because 
>>> there are several endpoints registered with the same account (ie 
>>> office and home phones).  When one of the endpoints answers the call, 
>>> SER sends a CANCEL to the other endpoints so they can stop further 
>>> call processing.  It turns our that this SER generated CANCEL does 
>>> not contain the "Max-Forwards" header which apparently violates RFC3261.
>>>
>>> Here is an example:
>>> U SER IP:5060 -> 10.10.1.50:36679
>>>  CANCEL 
>>> sip:3055551234 at 10.10.1.50:36679;rinstance=C926AD943D258534F5F62913216C50ADC9D895D2; 
>>>
>>>  transport=udp SIP/2.0..Via: SIP/2.0/UDP 
>>> 10.10.1.21:5065;branch=z9hG4bK1c1e.32eeb702.1..
>>>  From: "9545551234" <sip:9545551234 at 10.10.1.20:5066>;tag=as7d1243c9..
>>>  Call-ID: 4385c66230a310e714f020926aa2028c at 10.10.1.20..
>>>  To: <sip:3055551234 at X.X.X.X:5065>..CSeq: 102 CANCEL..
>>>  User-Agent: Sip EXpress router(0.9.6 (i386/linux))..
>>>  Content-Length: 0....    Is there any fix or workaround for this?  
>>> How can we get that "Max-Forwards" header in the Message if it is 
>>> internally generated by SER and no something that flows through the 
>>> config script.
>>>
>>> Thanks,
>>> Andres
>>> http://www.telesip.net
>>> _______________________________________________
>>> Serusers mailing list
>>> Serusers at lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>
> 
> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>