[Home]

Summary:ASTERISK-13370: No Audio on Call Transfer (Invite not being forwarded to Provider via Asterisk)
Reporter:Mike Burlingame (mbnwa)Labels:
Date Opened:2009-01-14 18:13:15.000-0600Date Closed:2011-06-07 14:03:22
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) call_sample1_CALL1_SIP_trace.rtf
( 1) call_sample1_CALL2_SIP_trace.rtf
( 2) Call_Sample1_DEBUG.rtf
( 3) Call_Sample1_PCAP_FLOW.png
( 4) original-call-trace.txt
( 5) Picture_1.png
( 6) Server_A_->_Server_B_->_Provider.png
( 7) Server_A_->_Server_B_->_Provider_Call_1.png
( 8) Server_A_->_Server_B_->_Provider_Call_2.png
( 9) transfernortp.cap
(10) transfernortp.txt
Description:Notes:
Asterisk 1.4.18 & Asterisk 1.6.x effected
Running directrtpsetup=yes
OS Debian
Kernel Version 2.6.26-1-amd64
Called number 13605551212
Caller's number 13605551211
Extension to get transfer: 13605551210
Caller z.z.z.z
Asterisk Server x.x.x.x
Carrier y.y.y.y

Call Flow
13605551211 calls 13605551212 makes the transfer to 13605551210 at this point call is direct between 13605551212 and 13605551210 but no audio

Issue:
Phone 1 makes an outbound call then transfers to another extension invite is sent from phone 1 to asterisk, Asterisk ack's however it  never sends the invite to the carrier to update the audio path resulting in no audio

SIP Trace

(lmadsen: I have removed the inline call trace, and placed it in a text file as 'original-call-trace.txt' and attached it to this issue. Long inline traces make open issues difficult to work with.)
Comments:By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2009-01-19 14:46:57.000-0600

Please close this bug report - user was unaware that using the L() argument in app_dial will cause RTP to pass via Asterisk always.
By: Mike Burlingame (mbnwa) 2009-01-22 15:45:30.000-0600

This issue was not resolved with removing L from the dial string.
By: David Woolley (davidw) 2009-05-13 10:18:11

The call flow doesn't match the trace.  In particular, the first stage is ...11 calls ...10, whereas the call flow says ....11 calls ....12.

Would it be possible to summarise the SIP dialogue; it is difficult to see what is happening, but I can't see any replaces operation, so I can't see where the transfer is supposed to complete.  Is this a SIP transfer or a features one and is it blind or attended?

I got a hint that there was early media; I wonder if ASTERISK-1345545 might be relevant (long shot).
By: Digium Subversion (svnbot) 2009-05-19 09:41:47

Repository: asterisk
Revision: 195448

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r195448 | file | 2009-05-19 09:41:46 -0500 (Tue, 19 May 2009) | 7 lines

Fix a bug where direct RTP setup would partially occur even when disabled if the calling channel was answered.

(issue ASTERISK-12766)
Reported by: davidw
(issue ASTERISK-13370)
Reported by: mbnwa

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=195448
By: Digium Subversion (svnbot) 2009-05-19 09:43:55

Repository: asterisk
Revision: 195449

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r195449 | file | 2009-05-19 09:43:55 -0500 (Tue, 19 May 2009) | 14 lines

Merged revisions 195448 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r195448 | file | 2009-05-19 11:41:45 -0300 (Tue, 19 May 2009) | 7 lines
 
 Fix a bug where direct RTP setup would partially occur even when disabled if the calling channel was answered.
 
 (issue ASTERISK-12766)
 Reported by: davidw
 (issue ASTERISK-13370)
 Reported by: mbnwa
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=195449
By: Digium Subversion (svnbot) 2009-05-19 09:45:56

Repository: asterisk
Revision: 195450

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_sip.c

------------------------------------------------------------------------
r195450 | file | 2009-05-19 09:45:55 -0500 (Tue, 19 May 2009) | 21 lines

Merged revisions 195449 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r195449 | file | 2009-05-19 11:43:54 -0300 (Tue, 19 May 2009) | 14 lines
 
 Merged revisions 195448 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r195448 | file | 2009-05-19 11:41:45 -0300 (Tue, 19 May 2009) | 7 lines
   
   Fix a bug where direct RTP setup would partially occur even when disabled if the calling channel was answered.
   
   (issue ASTERISK-12766)
   Reported by: davidw
   (issue ASTERISK-13370)
   Reported by: mbnwa
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=195450
By: Digium Subversion (svnbot) 2009-05-19 09:47:47

Repository: asterisk
Revision: 195451

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_sip.c

------------------------------------------------------------------------
r195451 | file | 2009-05-19 09:47:47 -0500 (Tue, 19 May 2009) | 21 lines

Merged revisions 195449 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r195449 | file | 2009-05-19 11:43:54 -0300 (Tue, 19 May 2009) | 14 lines
 
 Merged revisions 195448 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r195448 | file | 2009-05-19 11:41:45 -0300 (Tue, 19 May 2009) | 7 lines
   
   Fix a bug where direct RTP setup would partially occur even when disabled if the calling channel was answered.
   
   (issue ASTERISK-12766)
   Reported by: davidw
   (issue ASTERISK-13370)
   Reported by: mbnwa
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=195451
By: Digium Subversion (svnbot) 2009-05-19 09:49:40

Repository: asterisk
Revision: 195452

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_sip.c

------------------------------------------------------------------------
r195452 | file | 2009-05-19 09:49:40 -0500 (Tue, 19 May 2009) | 21 lines

Merged revisions 195449 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r195449 | file | 2009-05-19 11:43:54 -0300 (Tue, 19 May 2009) | 14 lines
 
 Merged revisions 195448 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r195448 | file | 2009-05-19 11:41:45 -0300 (Tue, 19 May 2009) | 7 lines
   
   Fix a bug where direct RTP setup would partially occur even when disabled if the calling channel was answered.
   
   (issue ASTERISK-12766)
   Reported by: davidw
   (issue ASTERISK-13370)
   Reported by: mbnwa
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=195452
By: Joshua C. Colp (jcolp) 2009-05-19 12:09:18

Can you please *attach* a complete console log with debug set to go to console in logger.conf and "core set debug 4" executed in the CLI, plus SIP traces? I haven't been able to reproduce this but the details are rather confusing.
By: Joshua C. Colp (jcolp) 2009-06-01 14:15:12

Unfortunately there has been no reply on this and I have failed to reproduce any problems during a second attempt. I am suspending until more information can be attached as needed.
By: Mike Burlingame (mbnwa) 2009-06-05 16:52:10

sorry I was not aware there was interest in this issue -- never got an email update, I will get the data requested and post back here.

The call flow is Server A makes an outbound call to Server B (Asterisk) Server B forwards the call to Provider Call is connected with out issue, Server A then makes a 2nd call to Server B and Server B forwards 2nd call to provider call is answered with out issue. Now the person that made the two calls from Server A tries to bridge the two calls together by sending an invite to Server B changing the SDP connection information of calls 1 and 2 to the provider media port and address of the respected channel.. However the invite is taken by Server B and is never forwarded to provider however Asterisk sends Server A a 100 Trying and a 200 OK even though the invite was never ack'ed or let alone seen by the provider. Attached is two images from a SIP PCAP dump showing the flow time stamp of reinvite for call 1 is around 22.77sec mark

I will try to get the Debug info on this asap
By: Mike Burlingame (mbnwa) 2009-06-12 16:12:58

Call Sample 1 has been uploaded with DEBUG data -- if you would like to see the unedited versions of the PCAP and DEBUG please contact me directly as I have removed all IP's from the data and replaced with unique values.
By: Sergey Okhapkin (sokhapkin) 2009-06-21 09:35:41

I have similar problem and I'm very interesting in the issue resolution. My scenario is the following:

direcrtpsetup=yes, canreinvite=yes

Server A -> Server B(asterisk) -> termination provider.

Initial call setup is OK, audio runs directly between Server A and termination provider. Now Server A sends to Server B SIP reinvite to update media IP/port. Asterisk on server B replies with 200 OK, but doesn't send reinvite to termination provider, audio path is broken.
By: Mike Burlingame (mbnwa) 2009-07-02 15:47:54

I can also confirm this issue that sokhapkin stated
By: Mike Burlingame (mbnwa) 2009-07-30 18:46:15

Any suggestions or corrections for this issue?
By: Jehanzeb Mansoor (jehanzeb) 2009-09-25 07:08:01

HI,
I am having a similar issue with my asterisk setup
I am on asterisk version 1.4.21.2
My sinerio is almost exactly the same
Sip.cfg is configured for reinvites
i.e. canreinvite= yes
the server layout is as under
handsetA<--->ServerA<--->SeverB(Asterisk)<--->ServerC<--->handsetC,handsetD and  media server
when a call is made from handset A destined for handset C, asterisk initially keeps hold of the media while the call is being established and once this is done server B (asterisk) sends re-invites to both servers  A and C with the media ip addresses of hanset A and C respectively so that now the RTP is flowing directly between the handsets.
The problem starts when handset C puts the caller (handset A ) on hold to transfer call to handset D. this is a blind transfer at this point server C sends an invite to asterisk server to re-route the media from handset A to the media server and later it provides the ip adderss for handset D to route media to in a separate invite. On both occasion the asterisk server sends an OK back to server C but doesn’t send an invite back to server A to reroute the media to the new phone. The result is even though handset A can hear the RTP from Handset D , Handset D is not receiving any RTP from Handset A I am attaching a trace file by the mane of "transfernortp.cap" taken at the asterisk server to illustrate my point. Please can you advice if there is a fix out for this.
Thanks,
Jehanzeb
By: David Woolley (davidw) 2009-09-25 08:48:56

You need to provide sip set debug output, not, I guess, Wireshark.

It is somewhat of a hassle for me to view it, even if it turns out to be tcpdump compatible, but I wonder if you actually have a variation of ASTERISK-13496.

PS don't ask if something has been fixed.  You should be reasonably confident that it hasn't, or should use the forum, irc, or mailing list.
By: Jehanzeb Mansoor (jehanzeb) 2009-09-25 11:08:44

Sorry about that, I have just uploaded the trace file using the sip set debug command. file name is transfernortp.txt. Hope this is helpful. I will also read through the provided the provided report to see if there are similarities.
Thanks
By: Paul Belanger (pabelanger) 2010-06-02 13:50:11

Please upgrade to the 1.4 or 1.6.2 branch and retest your issue.  If the problem still exists attach a debug log (see below) and sample extensions.conf to reproduce the issue.

---
We require a complete debug log to help triage the issue.

This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue:

http://svn.digium.com/svn/asterisk/trunk/doc/HOWTO_collect_debug_information.txt

By: Paul Belanger (pabelanger) 2010-06-10 15:11:17

Suspending since no new debug information has been provided.
--
Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.

Further information can be found at http://www.asterisk.org/developers/bug-guidelines