19 Nov
2009
19 Nov
'09
10 p.m.
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
19 Nov
19 Nov
10:08 p.m.
rupert.organ(a)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.
4 Dec
4 Dec
5:16 p.m.
On Nov 19, 2009 at 17:00, rupert.organ(a)bt.com <rupert.organ(a)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#c…).
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
8 Apr
8 Apr
3:16 p.m.
New subject: [Serusers] ser 0.9.x CANCEL retransmission problem
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) | |
| |
5135
days inactive
5275
days old
3 comments
4 participants
participants (4)
-
Andrei Pelinescu-Onciul -
Frank Durda IV -
James Chattaway -
rupert.organ＠bt.com