|Summary:||ASTERISK-08085: SIP sends no hangup|
|Date Opened:||2006-11-08 07:37:32.000-0600||Date Closed:||2006-12-05 12:56:17.000-0600|
|Environment:||Attachments:||( 0) trace1.txt|
( 1) trace2.txt
( 2) trace3.txt
|Description:||In Asterisk 1.4 rev 47275 I see the following behaviour.|
A Call comes in via SIP or IAX2 (I tested both scenarios), the call triggers the DIAL application which forwards the call to a SIP carrier. When the calling party hangs-up the ringing call, Asterisk does not send a BYE/CANCEL packet to the carrier. Hence the call continues to ring on the PSTN/MOBILE side.
I added below a combined view of Asterisk CLI and SIP DEBUG.
****** ADDITIONAL INFORMATION ******
-- Accepting AUTHENTICATED call from 80.92.X.Y:
> requested format = alaw,
> requested prefs = (),
> actual format = alaw,
> host prefs = (g726|ilbc|alaw|ulaw|g729),
> priority = mine
-- Executing [352691600abc@CUSTOMERMAIN:1] Macro("IAX2/username-7", "C1") in new stack
-- Executing [s@macro-C1:1] Set("IAX2/username-7", "CALLERID(number)=35220304xyz") in new stack
-- Executing [s@macro-C1:2] GotoIf("IAX2/username-7", "0?3:4") in new stack
-- Goto (macro-C1,s,5)
-- Executing [s@macro-C1:5] Dial("IAX2/storckmarc2-7", "SIP/00352691600abc@C1out2|60|") in new stack
Audio is at 80.92.x.a port 17634
Adding codec 0x8 (alaw) to SDP
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 62.41.f.g:5060:
INVITE sip:firstname.lastname@example.org SIP/2.0
Via: SIP/2.0/UDP 80.92.x.a:5060;branch=z9hG4bK4751131e;rport
From: "Marc" <sip:email@example.com>;tag=as2a270a4f
CSeq: 102 INVITE
Date: Wed, 08 Nov 2006 13:17:00 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
o=root 30698 30698 IN IP4 80.92.x.a
c=IN IP4 80.92.x.a
m=audio 17634 RTP/AVP 8 0 101
a=silenceSupp:off - - - -
-- Called 00352691600abc@C1out2
Found RTP audio format 8
Peer audio RTP is at port 62.41.f.h:17118
Found description format PCMA for ID 8
Capabilities: us - 0xc (ulaw|alaw), peer - audio=0x8 (alaw)/video=0x0 (nothing), combined - 0x8 (alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing)
Peer audio RTP is at port 62.41.f.h:17118
-- SIP/C1out2-007fd640 is making progress passing it to IAX2/username-7
Scheduling destruction of SIP dialog 'firstname.lastname@example.org' in 6400 ms (Method: INVITE)
== Spawn extension (macro-C1, s, 5) exited non-zero on 'IAX2/username-7' in macro 'C1'
== Spawn extension (macro-C1, s, 5) exited non-zero on 'IAX2/username-7'
-- Executing [h@macro-C1:1] Hangup("IAX2/username-7", "") in new stack
== Spawn extension (macro-C1, h, 1) exited non-zero on 'IAX2/username-7'
-- Hungup 'IAX2/username-7'
|Comments:||By: Joshua C. Colp (jcolp) 2006-11-08 10:47:38.000-0600|
A full sip debug as an attachment would be really helpful. Thanks.
By: the_duke (the_duke) 2006-11-08 12:17:08.000-0600
The packet TRYING (after the 1rst one) and 200 OK are related to the OPTIONS packet, check the Call-IDs if you want confirmation.
I cancelled the call on my side after the phone on the PSTN side began to ring. However no signalling (CANCEL packet) from Asterisk was sent. The Carrier finally report 480 Temporary Unavailable.
By: Joshua C. Colp (jcolp) 2006-11-08 12:28:04.000-0600
I need a sip debug on Asterisk, it shows Asterisk specific information.
By: the_duke (the_duke) 2006-11-08 12:55:07.000-0600
the sip debug (file trace2.txt) is somewhat small, smaller/shorter than on 1.2 rev 46964 at least
By: Joshua C. Colp (jcolp) 2006-11-08 13:12:52.000-0600
It's because you are limiting it to the IP address. Just doing sip debug without limiting it will be of more help too.
By: the_duke (the_duke) 2006-11-09 03:02:09.000-0600
trace3 contains a "sip debug"
By: the_duke (the_duke) 2006-11-13 05:08:13.000-0600
In rev 47527 the behaviour is better.
The only scenario which does still show this behaviour is the one shown in the traces. If the scenario differs e.g. the carrier return 180 RINGING (instead of 183 SESSION PROGRESS) a CANCEL is send. Also when I hangup before the 183 SESSION PROGRESS is received, asterisk also sends a BYE.
So, the problem only appears in the following scenario
C: SESSION PROGRESS
(*: Asterisk, C: Carrier, U: user)
By: Anthony LaMantia (alamantia) 2006-11-13 16:46:41.000-0600
can you update a full debug running on the asterisk server that is called and places the call via the carrier. showing the entire log of the first invite to the last bye/cancel sent from the oringal caller .. for the last situation you described looking the logs you put in i can't seem to see a lot of the information that should be there
By: Olle Johansson (oej) 2006-11-14 05:34:28.000-0600
This is related to ASTERISK-7293, where I have a 1.2 branch to fix this. please test.
By: the_duke (the_duke) 2006-11-17 03:46:09.000-0600
In latest SVN (rev 47784) this behaviour only shows for peers, the signalling is correct for friends.
By: Olle Johansson (oej) 2006-11-17 07:31:16.000-0600
Did you test the invitestate branch that I referred to?
By: Loic Didelot (voipgate) 2006-11-22 02:22:45.000-0600
In revision 47912 (latest SVN 1.4) the BYE or CANCEL is never sent. Doesnt matter if I call a friend, user or peer whereas in revision 47784 (1.4) the CANCEL or BYE was sent correctly for friends. So something has changed, but not improved :)
I will give the "invitestate" now a try and let you know.
By: Loic Didelot (voipgate) 2006-11-22 05:03:13.000-0600
I tested the patch from ASTERISK-7293 against the lastest asterisk 1.4 (47912). Well it is worse than asterisk 1.4 (47784).
Let's make it easy. Contact me on email@example.com and I will give you direct access to my box. You can compile on it and do the tests. NDA has been signed with Digium long time ago, so I can give you access without any problem.
By: Alex lake (alexlake) 2006-11-23 05:36:45.000-0600
I also have this problem and consider it major!
By: Loic Didelot (voipgate) 2006-11-27 09:12:31.000-0600
Any news on this issue? I see no SVN commits related to this problem.
By: rayjay (rayjay) 2006-11-28 04:31:44.000-0600
We are also having this exact same problem with our upstream provider. Calls that use '180 Ringing' are all fine, but when we call a Mobile via our SIP trunk we get a '183 Session Progress' instead and hangups are ignored.
I am surprised this is only seen as a minor bug since it is a fundamentally broken part of SIP session handling? There are a number of key features that we cannot switch on because of this bug, most notably 'Simultaneous Ring' type features - since the calls out to our Mobile phones keep ringing after another phone picks up...
I see there are some related patches, but I cannot get these to work against 1.4-beta3 - is there a patch or branch I should use to fix these issues?
By: Olle Johansson (oej) 2006-11-29 01:19:51.000-0600
voipgate: I am not Digium...
By: Alex lake (alexlake) 2006-11-29 04:04:59.000-0600
Some people have too much karma ;-)
So how about this chap called "file" is he/she associated with Digium and is he/she interested?
By: Olle Johansson (oej) 2006-11-30 00:35:57.000-0600
alexlake: What do you mean here?
By: Alex lake (alexlake) 2006-11-30 03:24:08.000-0600
I meant that you put so much work in on a voluntary basis (hence the high karma score) that it's hard to distinguish you from a Digium employee!
It was meant as a compliment!
By: Olle Johansson (oej) 2006-11-30 03:37:44.000-0600
in that case: Thank you :-)
By: Loic Didelot (voipgate) 2006-12-04 02:24:43.000-0600
The latest invitestate1 (1.4) branch works fine. Godd job
By: Alex lake (alexlake) 2006-12-04 03:49:37.000-0600
SOrry to ask a basic question, but when would one expect this branch to be incorporated into the HEAD?
By: Olle Johansson (oej) 2006-12-05 12:56:00.000-0600
Invitestate-1.4 was recently merged into 1.4 svn.
Thanks for testing!