[asterisk-bugs] [Asterisk 0014149]: Continuation - Handle BYE instead of CANCEL from callers (issue 0004994)
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Dec 29 01:17:45 CST 2008
The following issue has been SUBMITTED.
======================================================================
http://bugs.digium.com/view.php?id=14149
======================================================================
Reported By: legranjl
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 14149
Category: Channels/chan_sip/General
Reproducibility: always
Severity: minor
Priority: normal
Status: new
Asterisk Version: 1.4.21.2
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 2008-12-29 01:17 CST
Last Modified: 2008-12-29 01:17 CST
======================================================================
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?
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2008-12-29 01:17 legranjl New Issue
2008-12-29 01:17 legranjl Asterisk Version => 1.4.21.2
2008-12-29 01:17 legranjl SVN Branch (only for SVN checkouts, not tarball
releases) => N/A
======================================================================
More information about the asterisk-bugs
mailing list