Summary:ASTERISK-15658: [regression] No Ringing / No Playback when call is getting forwared by a phone
Reporter:Bastian Marmetschke (basty)Labels:
Date Opened:2010-02-18 13:12:03.000-0600Date Closed:2010-07-29 13:56:25
Versions:Frequency of
Environment:Attachments:( 0) debug.txt
( 1) debug02062010.rtf
Description:If an extension tries to setup a static call forwarding (on the phone) to another internal extension. The call is getting redirected - but the caller does not hear a ringing or can not hear a playback.

Example 1:
Ext "100" has setup a 302 redirect to extension "5". Somebody is calling SIP/100 - the call is getting forwared to extension "5" to play the Playback. The caller does not hear anything.

Example 2:
Ext "100" has setup a 302 redirect to extension "101". Somebody is calling SIP/100 - the call is getting forwarded to extension "101". The phone on extension 101 is ringing but the caller of 100 does not hear a ringing tone.
There is no problem with answering the call - both can talk without Problems.


Debug for Example 1 (100 called 20 - 20 had a forward to 5 - 100 could not hear the playback)
   -- Executing [20@intern:1] Set("SIP/100-00004a2f", "__TRANSFER_CONTEXT=transfercontext") in new stack
   -- Executing [20@intern:2] Dial("SIP/100-00004a2f", "SIP/20") in new stack
Audio is at port 19366
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x8 (alaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to
INVITE sip:20@;line=5ot20rul SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK14984305;rport
From: "TEST" <sip:100@>;tag=as66284718
To: <sip:20@;line=5ot20rul>
Contact: <sip:100@>
Call-ID: 1582e2d96a5f148e21a1f3f5078e9108@
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Thu, 18 Feb 2010 18:03:49 GMT
Supported: replaces
Content-Type: application/sdp
Content-Length: 254

o=root 3526 3526 IN IP4
c=IN IP4
t=0 0
m=audio 19366 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

   -- Called 20
<--- SIP read from --->
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP;branch=z9hG4bK14984305;rport=5060
From: "TEST" <sip:100@>;tag=as66284718
To: <sip:20@;line=5ot20rul>;tag=5o0taiaeir
Call-ID: 1582e2d96a5f148e21a1f3f5078e9108@
CSeq: 102 INVITE
Contact: <sip:5@;user=phone>
Diversion: <sip:20@;line=5ot20rul>;reason="unconditional"
Content-Length: 0

--- (9 headers 0 lines) ---
   -- Got SIP response 302 "Moved Temporarily" back from
Transmitting (no NAT) to
ACK sip:20@;line=5ot20rul SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK14984305;rport
From: "TEST" <sip:100@>;tag=as66284718
To: <sip:20@;line=5ot20rul>;tag=5o0taiaeir
Contact: <sip:100@>
Call-ID: 1582e2d96a5f148e21a1f3f5078e9108@
CSeq: 102 ACK
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0

   -- Now forwarding SIP/100-00004a2f to 'Local/5@intern' (thanks to SIP/20-00004a30)
   -- Executing [5@intern:1] Answer("Local/5@intern-387c,2", "") in new stack
   -- Executing [5@intern:2] Playback("Local/5@intern-387c,2", "ivrnbst-speech") in new stack
   -- <Local/5@intern-387c,2> Playing 'ivrnbst-speech' (language 'en')
Really destroying SIP dialog '1582e2d96a5f148e21a1f3f5078e9108@' Method: INVITE
 == Spawn extension (intern, 20, 2) exited non-zero on 'SIP/100-00004a2f'
 == Spawn extension (intern, 5, 2) exited non-zero on 'Local/5@intern-387c,2'
Really destroying SIP dialog '3c466de5dd58-cx0dnlnpait0' Method: ACK
Comments:By: Dave Poirier (dpoirier) 2010-02-19 12:51:11.000-0600

Found the same behavior in and as well.

By: Patrick Plattes (mrparity) 2010-02-24 10:20:14.000-0600

same in works fine

By: subeclipse (subeclipse) 2010-02-27 21:25:57.000-0600

I have the same problem on 1.4.29
[edit]Downgraded to and the problem is gone[/edit]

By: Bastian Marmetschke (basty) 2010-03-02 08:15:48.000-0600

Hi Sube,

i just opened another issue with a little moh problem (https://issues.asterisk.org/view.php?id=16901). Could you try that one on your also - if this one works - I will just go and downgrade. Thanks much!

By: subeclipse (subeclipse) 2010-03-02 09:24:40.000-0600

Hey basty,

I just tested this and it works properly on  
I'll post my test results in 16901 as not to confuse people following this bug.

By: Bastian Marmetschke (basty) 2010-06-02 11:00:35

Hi guys,

is there any news about that Problem ? I still do have that Problem - should I try an update to the latest 1.4 ?


EDIT: I just uploaded a sip debug. I was trying to call from my mobile the extension 961722. That phone was call forwarding to the internal "70". While I was calling - i didnt not hear anything..not even a "busy" tone.

By: David Woolley (davidw) 2010-06-03 06:11:21

That trace shows the call being rejected immediately with:

SIP/2.0 480 Do Not Disturb

There was no 180 Ringing from the phone, so it is correct that the caller does not hear ringback.

Also, I suspect you will find a lot more people look at your traces if you attach them as plain text, rather than as Microsoft RTF.

By: Bastian Marmetschke (basty) 2010-06-04 02:15:52

Hi David,

sorry - my mac editor just saved it to "rtf". Just updated a *.txt now.

In my Debug it goes to DND - but I couldnt even hear a busy, when I call the extension from external.

By: Bastian Marmetschke (basty) 2010-07-20 16:05:35

Hi again,

i just tested it on a other installation. Running asterisk 1.4.30 with an external PRI Interface. The ringing is working well. So it seems to be a problem with 1.4.29 or with the dahdi...

By: Kevin McAllister (mcallist) 2010-07-29 13:50:07

I've confirmed the problem on a 1.4.29 build and also confirmed that it is working in 1.4.30.

I went ahead and reviewed some differences between the releases and found that the cumulative fixes on channels/chan_local.c also fixed this problem.


I think the key really was in r 244785 the code to set the state for ringing was incorporated but it also regressed, the regression was cleaned up in r249536

I've applied this change in my lab and confirmed that it restores ringback to the case where a phone forwards a call.

By: Leif Madsen (lmadsen) 2010-07-29 13:56:24

Fixed in 1.4.30. Thanks!