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:[email protected]:25060 SIP/2.0. Via: SIP/2.0/UDP 192.168.10.124:5060;branch=z9hG4bK_7C2F8008F5C1_T5B47A547;rport. From: <sip:[email protected]>;tag=7C2F8008F5C1_T1484940980. To: "PhoneA" <sip:[email protected]:25060>;tag=as18f69e58. Call-ID: [email protected]. CSeq: 2 REFER. Refer-To: <sip:[email protected]?Replaces=CALL_ID9_7C2F8008F5C1_T1871060912% 40192_168_10_124%3Bto-tag%3Das13cb6557%3Bfrom-tag% 3D7C2F8008F5C1_T570909484>. Referred-by: <sip:[email protected]>. Contact: <sip:[email protected]: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:[email protected]: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:[email protected]>;tag=7C2F8008F5C1_T1484940980. To: "PhoneA" <sip:[email protected]:25060>;tag=as18f69e58. Call-ID: [email protected]. CSeq: 2 REFER. Refer-To: <sip:[email protected]?Replaces=CALL_ID9_7C2F8008F5C1_T1871060912% 40192_168_10_124%3Bto-tag%3Das13cb6557%3Bfrom-tag% 3D7C2F8008F5C1_T570909484>. Referred-by: <sip:[email protected]>. Contact: <sip:[email protected]: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:[email protected]>;tag=7C2F8008F5C1_T1484940980. To: "PhoneA" <sip:[email protected]:25060>;tag=as18f69e58. Call-ID: [email protected]. 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:[email protected]: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:[email protected]:2048;line=jrtagx14 SIP/2.0. Via: SIP/2.0/UDP 192.168.10.75:25060;branch=z9hG4bK7bc63ea0. Max-Forwards: 70. From: "PhoneB" <sip:[email protected]:25060>;tag=as2b910e05. To: <sip:[email protected]>;tag=dg06weh6iz. Contact: <sip:[email protected]:25060>. Call-ID: [email protected]. CSeq: 103 UPDATE. User-Agent: IPTAM PBX (Version 20141216/6814). P-Asserted-Identity: "PhoneA" <sip:[email protected]>. 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:[email protected]>;tag=7C2F8008F5C1_T1484940980. To: "PhoneA" <sip:[email protected]:25060>;tag=as18f69e58. Call-ID: [email protected]. 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:[email protected]: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:[email protected]:25060>;tag=as2b910e05. To: <sip:[email protected]>;tag=dg06weh6iz. Call-ID: [email protected]. CSeq: 103 UPDATE. Contact: <sip:[email protected]: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:*[email protected] SIP/2.0. Via: SIP/2.0/UDP 192.168.10.124:5060;branch=z9hG4bK_7C2F8008F5C1_T501426A2;rport. Session-Expires: 1800. From: "PhoneB" <sip:[email protected]>;tag=7C2F8008F5C1_T1016856740. To: <sip:*[email protected]>. Call-ID: CALL_ID10_7C2F8008F5C1_T35659420@192_168_10_124. CSeq: 2 INVITE. Contact: <sip:[email protected]: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:*[email protected]: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:[email protected]>;tag=7C2F8008F5C1_T1016856740. To: <sip:*[email protected]>. Call-ID: CALL_ID10_7C2F8008F5C1_T35659420@192_168_10_124. CSeq: 2 INVITE. Contact: <sip:[email protected]: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:[email protected] SIP/2.0. Via: SIP/2.0/UDP 192.168.10.75:25060;branch=z9hG4bK362342ee. Max-Forwards: 70. From: "PhoneB" <sip:[email protected]:25060>;tag=as2b910e05. To: <sip:[email protected]>. Call-ID: [email protected]. 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:[email protected]:25060>;tag=as2b910e05. To: <sip:[email protected]>. Call-ID: [email protected]. 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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
