| Summary: | ASTERISK-13283: Continuation - Handle BYE instead of CANCEL from callers (issue 0004994) | ||
| Reporter: | Jimmy le Grange (legranjl) | Labels: | |
| Date Opened: | 2008-12-29 01:17:45.000-0600 | Date Closed: | 2009-03-12 13:36:36 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) 14149.patch | |
| Description: | >> I have been testing 1.4.21.2 but still have problems with the BYE >> interpretation for unanswered calls. Asterisk is changing the >> incoming BYE from the SIP trunk to the SIP client to a CANCEL. This is >> fine but the termination request should also be passed on. Let me >> explain. >> >> In the early dialog establishment, it is better to send a Cancel to >> terminate early dialog but if a BYE is sent instead of Cancel, then >> UAS should send 4XX Response (It should be 481 responses but it can >> be 487 also). >> >> Alice (SIP Trunk) Bob (Asterisk) >> | | >> >> | INVITE F1 | >> >> |----------------------->| >> >> | 180 Ringing F2 | >> >> |<-----------------------| >> >> | | >> >> | BYE F3 | >> >> |----------------------->| >> >> | 200 OK(BYE) F4 | Currently Asterisk stops here >> >> |<-----------------------| >> >> | 481/7 F5 | >> >> |<-----------------------| >> >> | ACK F6 | >> |----------------------->| >> >> In this scenario, Alice establishes an early dialog with the >> receiving of 180 response. Alice sends a BYE on the early dialog. >> According to Section 15 of RFC3261, callee's UA MUST NOT send a BYE >> on early dialogs, but the caller's UA MAY send a BYE on early dialogs. >> >> >> >> >> >> F1 INVITE Alice -> Bob >> >> >> >> INVITE sip:bob@biloxi.example.com SIP/2.0 >> Via: SIP/2.0/UDP client.atlanta.example.com: >> 5060;branch=z9hG4bK74bf9 >> Max-Forwards: 70 >> From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl >> To: Bob <sip:bob@biloxi.example.com> >> Call-ID: 3848276298220188511@atlanta.example.com >> CSeq: 1 INVITE >> Contact: <sip:alice@client.atlanta.example.com;transport=udp> >> Content-Type: application/sdp >> Content-Length: 151 >> v=0 >> o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com >> s=- >> c=IN IP4 192.0.2.101 >> t=0 0 >> m=audio 49172 RTP/AVP 0 >> a=rtpmap:0 PCMU/8000 >> >> >> >> >> F2 180 Ringing Bob -> Alice >> >> >> >> SIP/2.0 180 Ringing >> Via: SIP/2.0/UDP >> client.atlanta.example.com: >> 5060;branch=z9hG4bK74bf9;received=192.0.2.101 >> From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl >> To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 >> Call-ID: 3848276298220188511@atlanta.example.com >> CSeq: 1 INVITE >> Contact: <sip:bob@client.biloxi.example.com;transport=udp> >> Content-Length: 0 >> >> >> >> >> >> Alice forms an early dialog by receiving a 180 response to the initial >> INVITE. However Bob is not sure that Alice received the 180 response. >> >> >> >> >> >> F3 BYE Alice -> Bob >> >> >> >> BYE sip:bob@client.biloxi.example.com SIP/2.0 >> Via: SIP/2.0/UDP client.atlanta.example.com: >> 5060;branch=z9hG4bKnashds9 >> Max-Forwards: 70 >> From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl >> To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 >> Call-ID: 3848276298220188511@atlanta.example.com >> CSeq: 2 BYE >> Content-Length: 0 >> >> >> >> >> >> Alice sends a BYE on the early dialog and Alice terminates a session >> (if any). >> >> >> >> F4 200 OK(BYE) Bob -> Alice >> >> >> >> SIP/2.0 200 OK >> Via: SIP/2.0/UDP client.atlanta.example.com: >> 5060;branch=z9hG4bKnashds9;received=192.0.2.101 >> From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl >> To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 >> Call-ID: 3848276298220188511@atlanta.example.com >> CSeq: 2 BYE >> Content-Length: 0 >> >> >> >> Bob sends a 200 OK to a BYE of Alice, and Bob terminates a session >> (if any). >> >> >> >> >> >> F5 487 Request Terminated(INVITE) Bob -> Alice >> >> >> >> SIP/2.0 487 Request Terminated >> Via: SIP/2.0/UDP client.atlanta.example.com: >> 5060;branch=z9hG4bK74bd5;received=192.0.2.101 >> From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl >> To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 >> Call-ID: 3848276298220188511@atlanta.example.com >> CSeq: 1 INVITE >> Contact: <sip:bob@client.biloxi.example.com;transport=udp> >> Content-Length: 0 >> >> >> >> >> >> Bob should terminate the early dialog when he receives a BYE. Bob >> sends a 487 response to terminate an INVITE transaction in the >> similar way to handle a CANCEL from Alice, because the INVITE >> transaction remains after terminating the early dialog. >> >> >> >> F6 ACK Alice -> Bob >> >> >> >> ACK sip:bob@biloxi.example.com SIP/2.0 >> Via: SIP/2.0/UDP client.atlanta.example.com: >> 5060;branch=z9hG4bK74bf9 >> Max-Forwards: 70 >> From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl >> To: Bob <sip:bob@biloxi.example.com> >> Call-ID: 3848276298220188511@atlanta.example.com >> CSeq: 1 ACK >> Contact: <sip:alice@client.atlanta.example.com;transport=udp> >> Content-Length: 0 >> >> >> >> Alice sends an ACK to a 487 response as processing of the initial >> INVITE transaction. (The dialog has been already terminated, but the >> initial INVITE transaction remains) >> So having this in mind the Asterisk PBX should actually send >> additionally a 4xx response here, in order to terminate the initial >> INVITE transaction. The Asterisk PBX stops with a 200 ok for the BYE >> received. >> Is it possible to change Asterisk PBX to behave this way? ****** ADDITIONAL INFORMATION ****** The current behaviour of Asterisk results in unreleased sessions on the ACME Net-Net-SD. The sessions only release after 3 minutes as specified in RFC3261 for timer C. Let me know what additional debug and traces are required. | ||
| Comments: | By: Mark Michelson (mmichelson) 2009-01-06 13:36:48.000-0600 The 1.4 branch of Asterisk appears to have code which is supposed to handle this scenario, but I suppose that it is not actually being run for whatever reason. If you look at the first if statement of handle_request_bye() in chan_sip.c, you'll see that we try to send a 487 if we receive a BYE for from a caller for whom we have not responded to their INVITE. I need to check into the individual components of this condition a bit more closely to determine why the 487 is not being transmitted. I should be able to reproduce this scenario pretty easily here, so I'll see what I can do. By: Mark Michelson (mmichelson) 2009-01-06 13:55:05.000-0600 A brief look at the code seems to indicate that the !p->owner condition being checked inside of handle_request_bye() is bogus. The p->owner pointer is set when we receive an incoming INVITE. I think checking the value of this is incorrect in this situation and should be removed. I'll do some quick looking through svn logs to see if I can find why that condition is there and if it needs to be worked around differently. I'll also upload my first attempt at a patch based on my code-reading thus far. By: Mark Michelson (mmichelson) 2009-01-06 13:56:40.000-0600 I've uploaded 14149.patch as a quick attempt to fix the problem. Test it out and see if that causes a 487 to be sent to the caller. By: Jimmy le Grange (legranjl) 2009-01-07 23:43:56.000-0600 Thanks, Will test the patch. By: Jimmy le Grange (legranjl) 2009-01-08 09:41:17.000-0600 Thanks this did it. Its wotking fine now By: Digium Subversion (svnbot) 2009-03-12 13:29:49 Repository: asterisk Revision: 181768 U branches/1.4/channels/chan_sip.c ------------------------------------------------------------------------ r181768 | mmichelson | 2009-03-12 13:29:48 -0500 (Thu, 12 Mar 2009) | 22 lines Properly send a 487 on an INVITE we have not responded to if we receive a BYE. If we receive an INVITE from an endpoint and then later receive a BYE from that same endpoint before we have sent a final response for the INVITE, then we need to respond to the INVITE with a 487. There was logic in the code prior to this commit which seemed to exist solely to handle this situation, but there was one condition in an if statement which was incorrect. The only way we would send a 487 was if the sip_pvt had no owner channel. This made no sense since we created the owner channel when we received the INVITE, meaning that the majority of the time we would never send the 487. The 487 being sent should not rely on whether we have created a channel. Its delivery should be dependent on the current state of the initial INVITE transaction. With this commit, that logic is now correctly in place. (closes issue ASTERISK-13283) Reported by: legranjl Patches: 14149.patch uploaded by mmichelson (license 60) Tested by: legranjl ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=181768 By: Digium Subversion (svnbot) 2009-03-12 13:30:59 Repository: asterisk Revision: 181769 _U trunk/ U trunk/channels/chan_sip.c ------------------------------------------------------------------------ r181769 | mmichelson | 2009-03-12 13:30:58 -0500 (Thu, 12 Mar 2009) | 28 lines Merged revisions 181768 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r181768 | mmichelson | 2009-03-12 13:29:48 -0500 (Thu, 12 Mar 2009) | 22 lines Properly send a 487 on an INVITE we have not responded to if we receive a BYE. If we receive an INVITE from an endpoint and then later receive a BYE from that same endpoint before we have sent a final response for the INVITE, then we need to respond to the INVITE with a 487. There was logic in the code prior to this commit which seemed to exist solely to handle this situation, but there was one condition in an if statement which was incorrect. The only way we would send a 487 was if the sip_pvt had no owner channel. This made no sense since we created the owner channel when we received the INVITE, meaning that the majority of the time we would never send the 487. The 487 being sent should not rely on whether we have created a channel. Its delivery should be dependent on the current state of the initial INVITE transaction. With this commit, that logic is now correctly in place. (closes issue ASTERISK-13283) Reported by: legranjl Patches: 14149.patch uploaded by mmichelson (license 60) Tested by: legranjl ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=181769 By: Digium Subversion (svnbot) 2009-03-12 13:32:39 Repository: asterisk Revision: 181770 _U branches/1.6.0/ U branches/1.6.0/channels/chan_sip.c ------------------------------------------------------------------------ r181770 | mmichelson | 2009-03-12 13:32:39 -0500 (Thu, 12 Mar 2009) | 35 lines Merged revisions 181769 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r181769 | mmichelson | 2009-03-12 13:30:58 -0500 (Thu, 12 Mar 2009) | 28 lines Merged revisions 181768 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r181768 | mmichelson | 2009-03-12 13:29:48 -0500 (Thu, 12 Mar 2009) | 22 lines Properly send a 487 on an INVITE we have not responded to if we receive a BYE. If we receive an INVITE from an endpoint and then later receive a BYE from that same endpoint before we have sent a final response for the INVITE, then we need to respond to the INVITE with a 487. There was logic in the code prior to this commit which seemed to exist solely to handle this situation, but there was one condition in an if statement which was incorrect. The only way we would send a 487 was if the sip_pvt had no owner channel. This made no sense since we created the owner channel when we received the INVITE, meaning that the majority of the time we would never send the 487. The 487 being sent should not rely on whether we have created a channel. Its delivery should be dependent on the current state of the initial INVITE transaction. With this commit, that logic is now correctly in place. (closes issue ASTERISK-13283) Reported by: legranjl Patches: 14149.patch uploaded by mmichelson (license 60) Tested by: legranjl ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=181770 By: Digium Subversion (svnbot) 2009-03-12 13:36:35 Repository: asterisk Revision: 181771 _U branches/1.6.1/ U branches/1.6.1/channels/chan_sip.c ------------------------------------------------------------------------ r181771 | mmichelson | 2009-03-12 13:36:35 -0500 (Thu, 12 Mar 2009) | 35 lines Merged revisions 181769 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r181769 | mmichelson | 2009-03-12 13:30:58 -0500 (Thu, 12 Mar 2009) | 28 lines Merged revisions 181768 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r181768 | mmichelson | 2009-03-12 13:29:48 -0500 (Thu, 12 Mar 2009) | 22 lines Properly send a 487 on an INVITE we have not responded to if we receive a BYE. If we receive an INVITE from an endpoint and then later receive a BYE from that same endpoint before we have sent a final response for the INVITE, then we need to respond to the INVITE with a 487. There was logic in the code prior to this commit which seemed to exist solely to handle this situation, but there was one condition in an if statement which was incorrect. The only way we would send a 487 was if the sip_pvt had no owner channel. This made no sense since we created the owner channel when we received the INVITE, meaning that the majority of the time we would never send the 487. The 487 being sent should not rely on whether we have created a channel. Its delivery should be dependent on the current state of the initial INVITE transaction. With this commit, that logic is now correctly in place. (closes issue ASTERISK-13283) Reported by: legranjl Patches: 14149.patch uploaded by mmichelson (license 60) Tested by: legranjl ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=181771 | ||