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:
- 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@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@10.10.1.20:5066;tag=as7d1243c9.. Call-ID: 4385c66230a310e714f020926aa2028c@10.10.1.20.. To: sip:3055551234@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers