Hi All,
Has anyone come up against an issue on 0.9.6 / 0.9.7 whereby a SIP App Server, delivers a CANCEL to the SER. The SER proxies the CANCELs to all the forked endpoints. At the same time it sends "200 Cancelling" back to the SIP App server...(this suppresses CANCEL retransmission from the SIP App server). If one of the CANCELs from the SER to the SIP UA gets lost....the phone keeps ringing. There is no CANCEL retransmission on the SER !!! There is CANCEL retransmission on the SIP App, but when it sends SER replies "no pending branches"
Ideally want the SER do CANCEL retransmissions. I understand the timers were rewritten in 0.10.x but this is not hardened version like 0.9.6....any suggestions?
Thanks in advance
Rupert
rupert.organ@bt.com wrote:
Hi All,
Has anyone come up against an issue on 0.9.6 / 0.9.7 whereby a SIP App Server, delivers a CANCEL to the SER. The SER proxies the CANCELs to all the forked endpoints. At the same time it sends "200 Cancelling" back to the SIP App server...(this suppresses CANCEL retransmission from the SIP App server). If one of the CANCELs from the SER to the SIP UA gets lost....the phone keeps ringing. There is no CANCEL retransmission on the SER !!! There is CANCEL retransmission on the SIP App, but when it sends SER replies "no pending branches"
Ideally want the SER do CANCEL retransmissions. I understand the timers were rewritten in 0.10.x but this is not hardened version like 0.9.6....any suggestions?
Thanks in advance
Rupert
Yes, SER behavior is obnoxious or even wrong for CANCEL, even for simple cases, such as the switch that SER forwards the CANCEL to rejects it. In that situation, SER has already sent a "200 cancelling", and can now only discard the rejection message. So the call continues on downstream of SER but upstream thinks the handshake is complete. Does this generate billing disputes? You bet it does, such as when the called party is a IVR and never hangs up or hangs up only after a day or more.
Due to a bug in the branch computation (chosing header elements that can change for re-computing the branch tag for subsequent messages of the same command sequence), we used to see this problem all the time.
Regardless of what the RFC may say on the subject, really SER should wait and return the the response to the CANCEL rather than assuming it is going to work and faking its own reply. I really don't see another rational way to handle it.
On Nov 19, 2009 at 17:00, rupert.organ@bt.com rupert.organ@bt.com wrote:
Hi All,
Has anyone come up against an issue on 0.9.6 / 0.9.7 whereby a SIP App Server, delivers a CANCEL to the SER. The SER proxies the CANCELs to all the forked endpoints. At the same time it sends "200 Cancelling" back to the SIP App server...(this suppresses CANCEL retransmission from the SIP App server). If one of the CANCELs from the SER to the SIP UA gets lost....the phone keeps ringing. There is no CANCEL retransmission on the SER !!!
There is, but only for the branches on which a provisional reply was received. There are 3 cases: 1. no reply received => ser 0.9.x will not send _any_ CANCEL on this branch, it will just close it. 2. provisional reply received (>=100 && < 200) => CANCEL will be sent and retransmitted 3. final reply (>= 200) => nothing will be done (it's too late for CANCEL)
(1) can introduce "ringing" problems: the reply from UA is lost, ser thinks it has received no reply and when CANCEL comes it just closes the branch. This behaviour can be changed in ser 2.1 or sip-router 3.0 (see http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#ca...). In fact on both of them the default behaviour is to keep retransmitting the original INVITE if there is no response received on the branch.
There's no easy way to backport it to 0.9.x. OTOH one could try modifying the code to retransmit CANCELs even on branches where no response was received (similar to cancel_b_method set to 2 in ser 2.1/sr 3.0). I could tell you what to change (2 or 3 lines), but I can't guarantee that it won't introduce some nasty side effect.
There is CANCEL retransmission on the SIP App, but when it sends SER replies "no pending branches"
No, that behaviour is correct: "If a matching response context is found, the element MUST immediately return a 200 (OK) response to the CANCEL request." (rfc3261 16.10 CANCEL Processing)
Ideally want the SER do CANCEL retransmissions. I understand the timers were rewritten in 0.10.x but this is not hardened version like 0.9.6....any suggestions?
sip-router 3.0 :-) However it would require config and db scheme changes.
If you want to keep using 0.9.x then at least upgrade to 0.9.9-rc1 (the 0.9.x are bugfix only releases, so no config or db changes are needed).
Andrei
Hi All,
I have a similar issue to the following post http://lists.iptel.org/pipermail/serusers/2009-December/035826.html
I am running against 0.9.6 but I have upgraded to 0.9.9 and I see the same issue.
I have the SER setup as a stateful proxy, occasionally the SBC due to load drops CANCEL's. (please find attached a .txt file for call flow out of wireshark) The SER doesn't retransmit the CANCEL, but this call has received a provisional reply (>=100 && < 200). The expectation from the post above is that this should result in a retransmit of CANCEL.
To remove as much as possible from the test case I have run with, out the box ser.cfg and sipp scripts I can reproduce this issue on 0.9.6 and 0.9.9, running the same sipp scripts against 3.0.1 kamailio results in CANCELs being retransmitted.
While the long term goal is to move to a later version of SER I would prefer not to do this now, can you think of anything that could cause this unexpected behavior?
Regards
James
192.168.35.225 - Call Agent 192.168.35.216 - SER 192.168.35.25 - Green side SBC 10.5.0.106 - Red side SBC 10.5.0.58 - Red side UA
Conv.| Time | 192.168.35.225 | 192.168.35.216 | 192.168.35.251 | 10.5.0.106 | 10.5.0.58 | 3 |3.726 | INVITE ( g711U...) | | | |SIP From: sip:anonymous@ftelser07.ftel.co.uk To:sip:05604000024@ftelser07.ftel.co.uk | |(5060) ------------------> (5060) | | | | 3 |3.729 | 100 trying -- your call is ...| | | |SIP Status | |(5060) <------------------ (5060) | | | | 3 |3.730 | | INVITE SDP ( g711U...) | | |SIP Request | | |(5060) ------------------> (5060) | | | 3 |3.732 | | 100 Trying | | |SIP Status | | |(5060) <------------------ (5060) | | | --------------------------------------------------------------------------------------------------------------------- 8 |3.735 | | | | INVITE SDP ( g711U...) |SIP From: sip:anonymous@ftelser07.ftel.co.uk To:sip:05604000024@ftelser07.ftel.co.uk | | | | |(5060) ------------------> (53252) | 8 |3.803 | | | | 100 Trying| |SIP Status | | | | |(5060) <------------------ (53252) | 8 |3.844 | | | | 180 Ringing |SIP Status | | | | |(5060) <------------------ (53252) | --------------------------------------------------------------------------------------------------------------------- 3 |3.846 | | 180 Ringing | | |SIP Status | | |(5060) <------------------ (5060) | | | 3 |3.846 | 180 Ringing | | | |SIP Status | |(5060) <------------------ (5060) | | | | 3 |6.071 | CANCEL | | | | |SIP Request | |(5060) ------------------> (5060) | | | | 3 |6.079 | | CANCEL | | | |SIP Request | | |(5060) ------------------> (5060) | | | 3 |6.080 | 200 canceling | | | |SIP Status | |(5060) <------------------ (5060) | | | |
-
Andrei Pelinescu-Onciul -
Frank Durda IV -
James Chattaway -
rupert.organ＠bt.com