Re: [asterisk-users] Failed to CANCEL a call in ringing state (SIP) in 1.8.9.2
Hi, Am Dienstag, den 14.02.2012, 11:32 -0600 schrieb Kevin P. Fleming: > This does appear to be a bug in Asterisk; please open an issue in JIRA, > and post the issue number here, so we can get someone looking at this > ASAP. Thanks! > Done, issue ASTERISK-19358. If I can do anything to test something, let me know. 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
Re: [asterisk-users] Failed to CANCEL a call in ringing state (SIP) in 1.8.9.2
On 02/14/2012 11:19 AM, Karsten Wemheuer wrote: Hi Kevin, Am Dienstag, den 14.02.2012, 09:46 -0600 schrieb Kevin P. Fleming: On 02/14/2012 09:30 AM, Karsten Wemheuer wrote: Hi, I got a problem with asterisk 1.8.9.2. The same scenario is working fine in 1.8.8.2. Asterisk calls a SIP phone via a proxy, proxy phone and asterisk are on the same LAN, no NAT. Asterisk sends the INVITE to the proxy, the proxy sends INVITE to the phone. The phone sends 180 RINGING back to the proxy. The proxy sends 180 RINGING to asterisk. So far so good. If the calling side decides to cancel the call, asterisk sends the CANCEL directly to the phone. The phone doesn't find the call and answers 404. In asterisk 1.8.8.2 asterisk sends the CANCEL to the proxy, which sends the CANCEL to the phone and all ist fine. I think, the new behavior comes from the lines parse_ok_contact(p, req); if (!reinvite) { build_route(p, req, 1); } which are inserted in the handling of provisional SIP response. Am I doing something wrong or is this a bug? It's impossible to answer that question without seeing the SIP signaling. The answer will depend on what the proxy did to insert itself in the path (or not) when it forwarded the 180 RINGING response to Asterisk. I shorten the trace to (hopefully) the relevant things. Asterisk is on 192.168.10.72, port 25060, proxy is opnesips on the same machine with port 5060, the phone which is ringing is on 192.168.10.221. Asterisk => Proxy: U 192.168.10.72:25060 -> 192.168.10.72:5060 INVITE sip:arthur@192.168.10.72 SIP/2.0. Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860. Max-Forwards: 70. From: "Max M..ller";tag=as3cafd135. To:. Contact:. Call-ID: 4c640ebd11d192e15bfc6d3a667684ce@192.168.10.72. CSeq: 102 INVITE. ... sdp cut of ... Proxy => Asterisk U 192.168.10.72:5060 -> 192.168.10.72:25060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860. From: "Max M..ller";tag=as3cafd135. To:. Call-ID: 4c640ebd11d192e15bfc6d3a667684ce@192.168.10.72. CSeq: 102 INVITE. Proxy => phone U 192.168.10.72:5060 -> 192.168.10.221:34381 INVITE sip:arthur@192.168.10.221:34381;line=478vzxb3 SIP/2.0. Via: SIP/2.0/UDP 192.168.10.72;branch=z9hG4bK24be.5163d992.0. Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860. Max-Forwards: 69. From: "Max M..ller";tag=as3cafd135. To:. Contact:. Call-ID: 4c640ebd11d192e15bfc6d3a667684ce@192.168.10.72. CSeq: 102 INVITE. ... sdp cut of ... Phone => Proxy U 192.168.10.221:34381 -> 192.168.10.72:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 192.168.10.72;branch=z9hG4bK24be.5163d992.0. Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860. From: "Max M..ller";tag=as3cafd135. To:;tag=cvovqkf6i5. Call-ID: 4c640ebd11d192e15bfc6d3a667684ce@192.168.10.72. CSeq: 102 INVITE. Contact:;reg-id=1. Proxy => Asterisk U 192.168.10.72:5060 -> 192.168.10.72:25060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860. From: "Max M..ller";tag=as3cafd135. To:;tag=cvovqkf6i5. Call-ID: 4c640ebd11d192e15bfc6d3a667684ce@192.168.10.72. CSeq: 102 INVITE. Contact:;reg-id=1. When canceling the call, asterisk sends Asterisk => Phone U 192.168.10.72:25060 -> 192.168.10.221:34381 CANCEL sip:arthur@192.168.10.72 SIP/2.0. Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860. Max-Forwards: 70. From: "Max M..ller";tag=as3cafd135. To:. Call-ID: 4c640ebd11d192e15bfc6d3a667684ce@192.168.10.72. CSeq: 102 CANCEL. The Phone responds: U 192.168.10.221:34381 -> 192.168.10.72:25060 SIP/2.0 404 Not found. Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860. From: "Max M..ller";tag=as3cafd135. To:. Call-ID: 4c640ebd11d192e15bfc6d3a667684ce@192.168.10.72. CSeq: 102 CANCEL. As noted in the earlier mail, this scenario is working in previous versions (1,4.x up to asterisk 1.8.8.2). Do You have any idea where the failure happens? Is it the proxy configuration or is it at the asterisk side (maybe config or bug)? This does appear to be a bug in Asterisk; please open an issue in JIRA, and post the issue number here, so we can get someone looking at this ASAP. Thanks! -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org -- _ -- 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
Re: [asterisk-users] Failed to CANCEL a call in ringing state (SIP) in 1.8.9.2
Hi Kevin, Am Dienstag, den 14.02.2012, 09:46 -0600 schrieb Kevin P. Fleming: > On 02/14/2012 09:30 AM, Karsten Wemheuer wrote: > > Hi, > > > > I got a problem with asterisk 1.8.9.2. The same scenario is working fine > > in 1.8.8.2. > > > > Asterisk calls a SIP phone via a proxy, proxy phone and asterisk are on > > the same LAN, no NAT. > > > > Asterisk sends the INVITE to the proxy, the proxy sends INVITE to the > > phone. The phone sends 180 RINGING back to the proxy. The proxy sends > > 180 RINGING to asterisk. So far so good. If the calling side decides to > > cancel the call, asterisk sends the CANCEL directly to the phone. The > > phone doesn't find the call and answers 404. In asterisk 1.8.8.2 > > asterisk sends the CANCEL to the proxy, which sends the CANCEL to the > > phone and all ist fine. > > > > I think, the new behavior comes from the lines > > parse_ok_contact(p, req); > > if (!reinvite) { > > build_route(p, req, 1); > > } > > which are inserted in the handling of provisional SIP response. > > > > Am I doing something wrong or is this a bug? > > It's impossible to answer that question without seeing the SIP > signaling. The answer will depend on what the proxy did to insert itself > in the path (or not) when it forwarded the 180 RINGING response to Asterisk. > I shorten the trace to (hopefully) the relevant things. Asterisk is on 192.168.10.72, port 25060, proxy is opnesips on the same machine with port 5060, the phone which is ringing is on 192.168.10.221. Asterisk => Proxy: U 192.168.10.72:25060 -> 192.168.10.72:5060 INVITE sip:arthur@192.168.10.72 SIP/2.0. Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860. Max-Forwards: 70. From: "Max M..ller" ;tag=as3cafd135. To: . Contact: . Call-ID: 4c640ebd11d192e15bfc6d3a667684ce@192.168.10.72. CSeq: 102 INVITE. ... sdp cut of ... Proxy => Asterisk U 192.168.10.72:5060 -> 192.168.10.72:25060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860. From: "Max M..ller" ;tag=as3cafd135. To: . Call-ID: 4c640ebd11d192e15bfc6d3a667684ce@192.168.10.72. CSeq: 102 INVITE. Proxy => phone U 192.168.10.72:5060 -> 192.168.10.221:34381 INVITE sip:arthur@192.168.10.221:34381;line=478vzxb3 SIP/2.0. Via: SIP/2.0/UDP 192.168.10.72;branch=z9hG4bK24be.5163d992.0. Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860. Max-Forwards: 69. From: "Max M..ller" ;tag=as3cafd135. To: . Contact: . Call-ID: 4c640ebd11d192e15bfc6d3a667684ce@192.168.10.72. CSeq: 102 INVITE. ... sdp cut of ... Phone => Proxy U 192.168.10.221:34381 -> 192.168.10.72:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 192.168.10.72;branch=z9hG4bK24be.5163d992.0. Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860. From: "Max M..ller" ;tag=as3cafd135. To: ;tag=cvovqkf6i5. Call-ID: 4c640ebd11d192e15bfc6d3a667684ce@192.168.10.72. CSeq: 102 INVITE. Contact: ;reg-id=1. Proxy => Asterisk U 192.168.10.72:5060 -> 192.168.10.72:25060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860. From: "Max M..ller" ;tag=as3cafd135. To: ;tag=cvovqkf6i5. Call-ID: 4c640ebd11d192e15bfc6d3a667684ce@192.168.10.72. CSeq: 102 INVITE. Contact: ;reg-id=1. When canceling the call, asterisk sends Asterisk => Phone U 192.168.10.72:25060 -> 192.168.10.221:34381 CANCEL sip:arthur@192.168.10.72 SIP/2.0. Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860. Max-Forwards: 70. From: "Max M..ller" ;tag=as3cafd135. To: . Call-ID: 4c640ebd11d192e15bfc6d3a667684ce@192.168.10.72. CSeq: 102 CANCEL. The Phone responds: U 192.168.10.221:34381 -> 192.168.10.72:25060 SIP/2.0 404 Not found. Via: SIP/2.0/UDP 192.168.10.72:25060;branch=z9hG4bK6c6f4860. From: "Max M..ller" ;tag=as3cafd135. To: . Call-ID: 4c640ebd11d192e15bfc6d3a667684ce@192.168.10.72. CSeq: 102 CANCEL. As noted in the earlier mail, this scenario is working in previous versions (1,4.x up to asterisk 1.8.8.2). Do You have any idea where the failure happens? Is it the proxy configuration or is it at the asterisk side (maybe config or bug)? Thanks, 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
Re: [asterisk-users] Failed to CANCEL a call in ringing state (SIP) in 1.8.9.2
On 02/14/2012 09:30 AM, Karsten Wemheuer wrote: Hi, I got a problem with asterisk 1.8.9.2. The same scenario is working fine in 1.8.8.2. Asterisk calls a SIP phone via a proxy, proxy phone and asterisk are on the same LAN, no NAT. Asterisk sends the INVITE to the proxy, the proxy sends INVITE to the phone. The phone sends 180 RINGING back to the proxy. The proxy sends 180 RINGING to asterisk. So far so good. If the calling side decides to cancel the call, asterisk sends the CANCEL directly to the phone. The phone doesn't find the call and answers 404. In asterisk 1.8.8.2 asterisk sends the CANCEL to the proxy, which sends the CANCEL to the phone and all ist fine. I think, the new behavior comes from the lines parse_ok_contact(p, req); if (!reinvite) { build_route(p, req, 1); } which are inserted in the handling of provisional SIP response. Am I doing something wrong or is this a bug? It's impossible to answer that question without seeing the SIP signaling. The answer will depend on what the proxy did to insert itself in the path (or not) when it forwarded the 180 RINGING response to Asterisk. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org -- _ -- 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