[Serusers] Max-Forwards missing in SER CANCEL during forking
jiri at iptel.org
Fri Jan 15 08:14:09 CET 2010
> Jiri Kuthan wrote:
>> Try to set parameter tm/reparse_invite to 1 -- I was not aware of the
>> 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
>> I could have imagined that the downstream hop absorbs the CANCEL at
>> 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
> 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.
>> Andres wrote:
>>> 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
>>> sip:3055551234 at 10.10.1.50:36679;rinstance=C926AD943D258534F5F62913216C50ADC9D895D2;
>>> transport=udp SIP/2.0..Via: SIP/2.0/UDP
>>> 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.
>>> Serusers mailing list
>>> Serusers at lists.iptel.org
> Serusers mailing list
> Serusers at lists.iptel.org
More information about the sr-users