[asterisk-bugs] [Asterisk 0014149]: Continuation - Handle BYE instead of CANCEL from callers (issue 0004994)
Asterisk Bug Tracker
noreply at bugs.digium.com
Thu Mar 12 13:32:39 CDT 2009
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=14149
======================================================================
Reported By: legranjl
Assigned To: mmichelson
======================================================================
Project: Asterisk
Issue ID: 14149
Category: Channels/chan_sip/General
Reproducibility: always
Severity: minor
Priority: normal
Status: closed
Asterisk Version: 1.4.21.2
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
Resolution: fixed
Fixed in Version:
======================================================================
Date Submitted: 2008-12-29 01:17 CST
Last Modified: 2009-03-12 13:32 CDT
======================================================================
Summary: Continuation - Handle BYE instead of CANCEL from
callers (issue 0004994)
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 at 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 at atlanta.example.com>;tag=9fxced76sl
>> To: Bob <sip:bob at biloxi.example.com>
>> Call-ID: 3848276298220188511 at atlanta.example.com
>> CSeq: 1 INVITE
>> Contact: <sip:alice at 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 at atlanta.example.com>;tag=9fxced76sl
>> To: Bob <sip:bob at biloxi.example.com>;tag=8321234356
>> Call-ID: 3848276298220188511 at atlanta.example.com
>> CSeq: 1 INVITE
>> Contact: <sip:bob at 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 at 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 at atlanta.example.com>;tag=9fxced76sl
>> To: Bob <sip:bob at biloxi.example.com>;tag=8321234356
>> Call-ID: 3848276298220188511 at 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 at atlanta.example.com>;tag=9fxced76sl
>> To: Bob <sip:bob at biloxi.example.com>;tag=8321234356
>> Call-ID: 3848276298220188511 at 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 at atlanta.example.com>;tag=9fxced76sl
>> To: Bob <sip:bob at biloxi.example.com>;tag=8321234356
>> Call-ID: 3848276298220188511 at atlanta.example.com
>> CSeq: 1 INVITE
>> Contact: <sip:bob at 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 at 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 at atlanta.example.com>;tag=9fxced76sl
>> To: Bob <sip:bob at biloxi.example.com>
>> Call-ID: 3848276298220188511 at atlanta.example.com
>> CSeq: 1 ACK
>> Contact: <sip:alice at 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?
======================================================================
----------------------------------------------------------------------
(0101676) svnbot (reporter) - 2009-03-12 13:32
http://bugs.digium.com/view.php?id=14149#c101676
----------------------------------------------------------------------
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 http://bugs.digium.com/view.php?id=14149)
Reported by: legranjl
Patches:
14149.patch uploaded by mmichelson (license 60)
Tested by: legranjl
........
................
------------------------------------------------------------------------
http://svn.digium.com/view/asterisk?view=rev&revision=181770
Issue History
Date Modified Username Field Change
======================================================================
2009-03-12 13:32 svnbot Checkin
2009-03-12 13:32 svnbot Note Added: 0101676
======================================================================
More information about the asterisk-bugs
mailing list