thr3ads.net - asterisk users - [asterisk-users] Asterisk sends CANCEL to the wrong destination [Dec 2014]

If this information is useful, please help other people find it:
Share via:

Karsten Wemheuer

2014-Dec-16 15:32 UTC

[asterisk-users] Asterisk sends CANCEL to the wrong destination

Hi,

I got a weird behaviour in asterisk (original found in 1.8 but it is
still the same in 11.15.0). I have three phones communicating via
OpenSIPs with asterisk. Phone A dials 100 and asterisk calls
SIP/phone-b. Phone B accepts the call. The User on Phone B places the
call on hold, dials 200 and, while hearing the dial tone of ringing
Phone C, places the handset on hook. Phone B sends a REFER, so that
Phone A is connected with the ringing Phone C. Asterisk sends an UPDATE
to Phone-C to update the connected line information. Now the user on
Phone B realized that User B is not available. He presses the blinking
LED of BLF to get the Call back. A and B are now connected again. But
Phone C is still ringing. Asterisk sends the CANCEL to terminate the
call to phone C not to the proxy (where the INVITE comes from), but
directly to the phone. The phone ignores this CANCEL, as it does not
belong to a call and so the phone keeps on ringing.

If I modify the configuration, so that there is no UPDATE for the
connected line information, the CANCEL is send via proxy to the phone
and all is well.

In the following trace asterisk is at 192.168.10.70:25060, the proxy is
at 192.168.10.5060. The phones are at 192.168.10.201 (Phone-A),
192.168.10.124 (Phone-B) and 192.168.10.102 (Phone-C).

Shortened SIP-Trace is as follows (starting with the REFER):

Call between A and B is on hold, B has call to C in ringing state.
Transfer, so that A has the ringing call to C

REFER is send from Phone B to proxy:

U 192.168.10.124:5060 -> 192.168.10.75:5060
REFER sip:180 at 192.168.10.75:25060 SIP/2.0.
Via: SIP/2.0/UDP
192.168.10.124:5060;branch=z9hG4bK_7C2F8008F5C1_T5B47A547;rport.
From: <sip:phone-b at 192.168.10.75>;tag=7C2F8008F5C1_T1484940980.
To: "PhoneA" <sip:180 at 192.168.10.75:25060>;tag=as18f69e58.
Call-ID: 452af6610540b7cf0d4c49f372d46779 at 192.168.10.75.
CSeq: 2 REFER.
Refer-To:
<sip:200 at 192.168.10.75?Replaces=CALL_ID9_7C2F8008F5C1_T1871060912%
40192_168_10_124%3Bto-tag%3Das13cb6557%3Bfrom-tag%
3D7C2F8008F5C1_T570909484>.
Referred-by: <sip:phone-b at 192.168.10.75>.
Contact: <sip:phone-b at 192.168.10.124:5060>.
Max-Forwards: 70.
Content-Length: 0.

REFER is send from proxy to asterisk:

U 192.168.10.75:5060 -> 192.168.10.75:25060
REFER sip:180 at 192.168.10.75:25060 SIP/2.0.
Via: SIP/2.0/UDP
192.168.10.75:5060;branch=z9hG4bK_7C2F8008F5C1_T5B47A547.
Via: SIP/2.0/UDP
192.168.10.124:5060;received=192.168.10.124;branch=z9hG4bK_7C2F8008F5C1_T5B47A547;rport=5060.
From: <sip:phone-b at 192.168.10.75>;tag=7C2F8008F5C1_T1484940980.
To: "PhoneA" <sip:180 at 192.168.10.75:25060>;tag=as18f69e58.
Call-ID: 452af6610540b7cf0d4c49f372d46779 at 192.168.10.75.
CSeq: 2 REFER.
Refer-To:
<sip:200 at 192.168.10.75?Replaces=CALL_ID9_7C2F8008F5C1_T1871060912%
40192_168_10_124%3Bto-tag%3Das13cb6557%3Bfrom-tag%
3D7C2F8008F5C1_T570909484>.
Referred-by: <sip:phone-b at 192.168.10.75>.
Contact: <sip:phone-b at 192.168.10.124:5060>.
Max-Forwards: 69.
Content-Length: 0.

U 192.168.10.75:25060 -> 192.168.10.75:5060
SIP/2.0 202 Accepted.
Via: SIP/2.0/UDP
192.168.10.75:5060;branch=z9hG4bK_7C2F8008F5C1_T5B47A547;received=192.168.10.75.
Via: SIP/2.0/UDP
192.168.10.124:5060;received=192.168.10.124;branch=z9hG4bK_7C2F8008F5C1_T5B47A547;rport=5060.
From: <sip:phone-b at 192.168.10.75>;tag=7C2F8008F5C1_T1484940980.
To: "PhoneA" <sip:180 at 192.168.10.75:25060>;tag=as18f69e58.
Call-ID: 452af6610540b7cf0d4c49f372d46779 at 192.168.10.75.
CSeq: 2 REFER.
Server: IPTAM PBX (Version 20141216/6814).
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Contact: <sip:180 at 192.168.10.75:25060>.
Content-Length: 0.

Update connected line info on ringing phone C. Request is sent directly
from asterisk to phone:

U 192.168.10.75:25060 -> 192.168.10.102:2048
UPDATE sip:phone-c at 192.168.10.102:2048;line=jrtagx14 SIP/2.0.
Via: SIP/2.0/UDP 192.168.10.75:25060;branch=z9hG4bK7bc63ea0.
Max-Forwards: 70.
From: "PhoneB" <sip:100 at 192.168.10.75:25060>;tag=as2b910e05.
To: <sip:phone-c at 192.168.10.75>;tag=dg06weh6iz.
Contact: <sip:100 at 192.168.10.75:25060>.
Call-ID: 2dadc6b61efcb4dc726be746564897bf at 192.168.10.75.
CSeq: 103 UPDATE.
User-Agent: IPTAM PBX (Version 20141216/6814).
P-Asserted-Identity: "PhoneA" <sip:180 at 192.168.10.75>.
X-Asterisk-rpid-update: Yes.
Content-Length: 0.

U 192.168.10.75:5060 -> 192.168.10.124:5060
SIP/2.0 202 Accepted.
Via: SIP/2.0/UDP
192.168.10.124:5060;received=192.168.10.124;branch=z9hG4bK_7C2F8008F5C1_T5B47A547;rport=5060.
From: <sip:phone-b at 192.168.10.75>;tag=7C2F8008F5C1_T1484940980.
To: "PhoneA" <sip:180 at 192.168.10.75:25060>;tag=as18f69e58.
Call-ID: 452af6610540b7cf0d4c49f372d46779 at 192.168.10.75.
CSeq: 2 REFER.
Server: IPTAM PBX (Version 20141216/6814).
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Contact: <sip:180 at 192.168.10.75:25060>.
Content-Length: 0.

U 192.168.10.102:2048 -> 192.168.10.75:25060
SIP/2.0 200 Ok.
Via: SIP/2.0/UDP 192.168.10.75:25060;branch=z9hG4bK7bc63ea0.
From: "PhoneB" <sip:100 at 192.168.10.75:25060>;tag=as2b910e05.
To: <sip:phone-c at 192.168.10.75>;tag=dg06weh6iz.
Call-ID: 2dadc6b61efcb4dc726be746564897bf at 192.168.10.75.
CSeq: 103 UPDATE.
Contact: <sip:phone-c at 192.168.10.102:2048;line=jrtagx14>;reg-id=1.
User-Agent: snom360/8.7.3.25.
Supported: timer, 100rel, replaces, from-change.
Content-Length: 0.

Start directed pickup from phone B:

U 192.168.10.124:5060 -> 192.168.10.75:5060
INVITE sip:*8200 at 192.168.10.75 SIP/2.0.
Via: SIP/2.0/UDP
192.168.10.124:5060;branch=z9hG4bK_7C2F8008F5C1_T501426A2;rport.
Session-Expires: 1800.
From: "PhoneB" <sip:phone-b at
192.168.10.75>;tag=7C2F8008F5C1_T1016856740.
To: <sip:*8200 at 192.168.10.75>.
Call-ID: CALL_ID10_7C2F8008F5C1_T35659420 at 192_168_10_124.
CSeq: 2 INVITE.
Contact: <sip:phone-b at 192.168.10.124:5060>.
Max-Forwards: 70.
Content-Type: application/sdp.
Content-Length: 241.

Send INVITE from proxy to asterisk:

U 192.168.10.75:5060 -> 192.168.10.75:25060
INVITE sip:*8200 at 192.168.10.75:25060 SIP/2.0.
Via: SIP/2.0/UDP
192.168.10.75:5060;branch=z9hG4bK_7C2F8008F5C1_T501426A2.
Via: SIP/2.0/UDP
192.168.10.124:5060;received=192.168.10.124;branch=z9hG4bK_7C2F8008F5C1_T501426A2;rport=5060.
Session-Expires: 1800.
From: "PhoneB" <sip:phone-b at
192.168.10.75>;tag=7C2F8008F5C1_T1016856740.
To: <sip:*8200 at 192.168.10.75>.
Call-ID: CALL_ID10_7C2F8008F5C1_T35659420 at 192_168_10_124.
CSeq: 2 INVITE.
Contact: <sip:phone-b at 192.168.10.124:5060>.
Max-Forwards: 69.
Content-Type: application/sdp.
Content-Length: 241.

(Skipping Trying and OK)

Asterisk send CANCEL directly to the phone-C:

U 192.168.10.75:25060 -> 192.168.10.102:2048
CANCEL sip:phone-c at 192.168.10.75 SIP/2.0.
Via: SIP/2.0/UDP 192.168.10.75:25060;branch=z9hG4bK362342ee.
Max-Forwards: 70.
From: "PhoneB" <sip:100 at 192.168.10.75:25060>;tag=as2b910e05.
To: <sip:phone-c at 192.168.10.75>.
Call-ID: 2dadc6b61efcb4dc726be746564897bf at 192.168.10.75.
CSeq: 102 CANCEL.
User-Agent: IPTAM PBX (Version 20141216/6814).
Reason: SIP;cause=200;text="Call completed elsewhere".
Content-Length: 0.

Phone does not accept the CANCEL and keeps on ringing!
U 192.168.10.102:2048 -> 192.168.10.75:25060
SIP/2.0 404 Not found.
Via: SIP/2.0/UDP 192.168.10.75:25060;branch=z9hG4bK362342ee.
From: "PhoneB" <sip:100 at 192.168.10.75:25060>;tag=as2b910e05.
To: <sip:phone-c at 192.168.10.75>.
Call-ID: 2dadc6b61efcb4dc726be746564897bf at 192.168.10.75.
CSeq: 102 CANCEL.
User-Agent: snom360/8.7.3.25.
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE,
PRACK, MESSAGE, INFO, UPDATE.
Allow-Events: talk, hold, refer, call-info.
Supported: timer, 100rel, replaces, from-change.
Content-Length: 0.

As far as I understand the RFC, the CANCEL has to be sent via the proxy
to the phone. If I set sendrpid to "no" to disable the connected line
update, the CANCEL will be sent correctly via proxy to the phone.

Is this a bug? Or am I wrong? Should I file a bug at jira?

Thanks for any hints,

Karsten

Karsten Wemheuer

2014-Dec-17 11:50 UTC

head link

[asterisk-users] Asterisk sends CANCEL to the wrong destination

Hi,

Am Dienstag, den 16.12.2014, 16:32 +0100 schrieb Karsten Wemheuer:
> Hi,
> 
> I got a weird behaviour in asterisk (original found in 1.8 but it is
> still the same in 11.15.0). I have three phones communicating via
> OpenSIPs with asterisk. Phone A dials 100 and asterisk calls
> SIP/phone-b. Phone B accepts the call. The User on Phone B places the
> call on hold, dials 200 and, while hearing the dial tone of ringing
> Phone C, places the handset on hook. Phone B sends a REFER, so that
> Phone A is connected with the ringing Phone C. Asterisk sends an UPDATE
> to Phone-C to update the connected line information. Now the user on
> Phone B realized that User B is not available. He presses the blinking
> LED of BLF to get the Call back. A and B are now connected again. But
> Phone C is still ringing. Asterisk sends the CANCEL to terminate the
> call to phone C not to the proxy (where the INVITE comes from), but
> directly to the phone. The phone ignores this CANCEL, as it does not
> belong to a call and so the phone keeps on ringing.
> 
> If I modify the configuration, so that there is no UPDATE for the
> connected line information, the CANCEL is send via proxy to the phone
> and all is well.
I possibly find the source of the failure and a patch, working without
failure in my test scenario. I filed a bug with patch attached, see
https://issues.asterisk.org/jira/browse/ASTERISK-24628

Have a nice day,

Karsten

Possibly Parallel Threads

Search for more reasonably related threads

asterisk users - Dec 2014 - Asterisk sends CANCEL to the wrong destination

[asterisk-users] Asterisk sends CANCEL to the wrong destination

[asterisk-users] Asterisk sends CANCEL to the wrong destination

Possibly Parallel Threads