[Home]

Summary:ASTERISK-11954: Loss of audio after 2 seconds of P2P RTP bridging
Reporter:Private Name (falves11)Labels:
Date Opened:2008-05-01 13:23:14Date Closed:2008-05-16 08:38:34
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-1.4-call-setup.txt
( 1) asterisk-trunk-sip-test.txt
( 2) core_show_locks_trunk_r115537
( 3) rtp_debug_trunk_r115537
Description:I have a peer like this

[federico]
type=peer
host=72.187.243.97
context=default
dtmfmode=rfc2833
canreinvite=no
disallow=all
allow=g729
allow=ulaw
nat=yes
insecure=port,invite

but when I type "sip show peers"
ame/username              Host            Dyn Nat ACL Port     Status
federico                   72.187.243.97        N      5060     Unmonitored

and in fact the calls connect and there is second of audio and then the audio stops. I am behind a nat.

****** ADDITIONAL INFORMATION ******

[general]
dtmfmode=rfc2833
bindport = 5060
bindaddr = 0.0.0.0
context=default
tos=184
maxexpirey=3600
defaultexpirey=3600
notifymimetype=text/plain
disallow=all
t38pt_udptl = yes
t38udptlsupport=yes
t38tcpsupport=yes
t38rtpsupport=yes
allow=g729
allow=ulaw
rfc2833compensate =yes
trustrpid = yes                 ; If Remote-Party-ID should be trusted
sendrpid = no
passcodecs=yes
autocreatepeer=yes
qualify=no
language=en
relaxdtmf=no
nat=yes
fromdomain=minixel
promiscredir=no
bridge=yes
transfer=no
cancallforward=no
callreturn=yes
rtpholdtimeout=60
rtptimeout=60
directrtpsetup=yes              
canreinvite=nonat,
rtpkeepalive=60
Comments:By: Olle Johansson (oej) 2008-05-01 13:26:26

If you had read the bug guidelines you would see that this is an incomplete bug report. You also have several settings that is not valid. Please start by contacting someone on IRC to help you or use the asterisk-users mailing list to get help. If you still think we have a bug, please follow the instructions and file a new bug report or re-open this one.

Thank you.
By: Leif Madsen (lmadsen) 2008-05-01 17:27:00

Reopening as I was able to see this reproduced on his system.
By: Leif Madsen (lmadsen) 2008-05-01 17:35:04

On this system with no changes to the configuration, I was able to see this issue reproduced.

What happens on 1.4 is that the call is setup to my IVR, and audio is passed in both directions (confirmed with 'rtp set debug on' and that fact we could hear each other).

When running trunk, the system seems to pass RTP for a few seconds, but then stops. No audio is heard.

I have provided the console output. My apologies for the useless information at the top of the file -- I'm running a bit late and didn't have time to format it nicely for you.

Please let me know if you need any additional information to move this forward.

Thanks!
L.
By: Private Name (falves11) 2008-05-04 22:56:42

After the call connects to the destination, and I hangup in the destination, I see these errors on the screen. All this happens if the originating SIP endpoint is behind a NAT and there is no DMZ active. Somehow the way we handle NAT got lost from 1.4 to Trunk. I got this error with version SVN-trunk-r115283. My machine is open if somebody wants to do further captures. I have no idea how to capture the trace the way Leif Madsen from Digium did it. Maybe somebody could explain??.

-- Packet2Packet bridging SIP/45990-b805d4f8 and SIP/4.71.122.130-b80b7568
Sipserver208*CLI> [May  4 23:57:54] ERROR[3500]: chan_sip.c:19213 handle_request_do: We could NOT get the channel lock for SIP/45990-b805d4f8!
[May  4 23:57:54] ERROR[3500]: chan_sip.c:19214 handle_request_do: SIP transaction failed: 0B87AA19-3AF6-4238-A858-70A8F5204419@192.168.1.111
[May  4 23:57:54] ERROR[3500]: chan_sip.c:19213 handle_request_do: We could NOT get the channel lock for SIP/45990-b805d4f8!
[May  4 23:57:54] ERROR[3500]: chan_sip.c:19214 handle_request_do: SIP transaction failed: 0B87AA19-3AF6-4238-A858-70A8F5204419@192.168.1.111


By: Leif Madsen (lmadsen) 2008-05-05 08:50:43

FYI: We tried this both with and without directrtpsetup on. The same thing occurred with it off.
By: Joshua C. Colp (jcolp) 2008-05-07 09:15:13

1. Has a separate SIP destination been tested to ensure that it is happening on all SIP dialogs, and not just ones to this Cisco?

2. Are the filenames correct? The one from trunk does show RTP packets being forwarded in the P2P layer while the 1.4 one does not.

3. We will need a core show locks to examine the SIP channel locking issue, it may be the cause of the loss of audio.

4. Core debug would also be useful. debug to console in logger.conf and core set debug 10
By: Private Name (falves11) 2008-05-07 10:44:55

Is there a volunteer that wishes to help capture the debugging information, since Digium's Leif has no time and I don't feel like paying support for bugs? I can dedicate a machine only for analizing this bug.
By: Private Name (falves11) 2008-05-08 12:17:25

The ssh connection freezes and also the CDR does not get written to the database (cdr_odbc). It only happens when I call from behind NAT, otherwise works fine. Also, if I hangup in the origin, the destination leg remains connected. But I get a reply to my "BYE" message. I might be getting it because I set the DMZ to my computer, otherwise I would not. It is like it does not understand how to handle NAT anymore.
What kind of debugging ca we do if it freezes? However, I disconnect and reconnect again and Asteriksk works,

-- Called 19544447408@4.71.122.130
   -- SIP/4.71.122.130-b4054d48 is making progress passing it to SIP/45990-0366b878
   -- SIP/4.71.122.130-b4054d48 answered SIP/45990-0366b878
   -- Packet2Packet bridging SIP/45990-0366b878 and SIP/4.71.122.130-b4054d48
We could NOT get the channel lock for SIP/207.155.147.30-03677968!
SIP transaction failed: 682c66d823d8ecfe1f03aa4378768a0e@minixel.com
We could NOT get the channel lock for SIP/207.155.147.30-03677968!
SIP transaction failed: 682c66d823d8ecfe1f03aa4378768a0e@minixel.com
We could NOT get the channel lock for SIP/207.155.147.30-03677968!
SIP transaction failed: 682c66d823d8ecfe1f03aa4378768a0e@minixel.com
We could NOT get the channel lock for SIP/207.155.147.30-03677968!
SIP transaction failed: 682c66d823d8ecfe1f03aa4378768a0e@minixel.com
We could NOT get the channel lock for SIP/207.155.147.30-03677968!
SIP transaction failed: 682c66d823d8ecfe1f03aa4378768a0e@minixel.com
We could NOT get the channel lock for SIP/207.155.147.30-03677968!
SIP transaction failed: 682c66d823d8ecfe1f03aa4378768a0e@minixel.com
We could NOT get the channel lock for SIP/207.155.147.30-03677968!
SIP transaction failed: 682c66d823d8ecfe1f03aa4378768a0e@minixel.com
Maximum retries exceeded on transmission 682c66d823d8ecfe1f03aa4378768a0e@minixel.com for seqno 103 (Critical Request)
By: Michael L. Young (elguero) 2008-05-08 14:46:47

I think I am seeing the same issue and maybe I can shed some more light on this with what I am experiencing.  I am using trunk, r115537

My setup: Asterisk is on my router.  Therefore it has a public IP.  On asterisk I have a SIP registration to a SIP provider.  I then have on the LAN side a Polycom 430.  Phone calls from SIP provider dial the Polycom.  (I do have realtime setup so the Polycom is registered to Asterisk using realtime, not sure if that matters).

file:

1.  Destination in my case is a Polycom

2.  I am using trunk r115537

3.  Core show locks attached

4.  Core debug too big for mantis; find it at http://www.nashuacs.com/asterisk-debug/core_debug_10_trunk_r115537

Just in case, RTP debug attached.

Now, outbound calling seems to be working fine.  This only affects incoming calls.  I have tried to stop P2P bridging (directrtp off) but that doesn't seem to work and asterisk is still trying to switch to P2P.

Let me know if I can provide any further information to help track this down.


By: Digium Subversion (svnbot) 2008-05-15 16:48:26

Repository: asterisk
Revision: 116663

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r116663 | jpeeler | 2008-05-15 16:48:24 -0500 (Thu, 15 May 2008) | 2 lines

Fixes a problem I was having with two SIP phones using Packet2Packet bridging dropping audio nearly immediately. The problem was that the lock on the SIP dialog was not being unlocked while the bridge was still active. (Related to issue ASTERISK-11954)

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

http://svn.digium.com/view/asterisk?view=rev&revision=116663
By: Jeff Peeler (jpeeler) 2008-05-15 16:52:17

Try with the latest update from trunk and see if the problem is still present.
By: Private Name (falves11) 2008-05-16 03:32:59

In my case it works fine. let's see what other affected user thinks when he tests. But thanks a lot. I am back to normal.
By: Michael L. Young (elguero) 2008-05-16 08:35:07

This update appears to have fixed the issue as well.

Thanks
By: Leif Madsen (lmadsen) 2008-05-16 08:38:19

jpeeler found a locking issue in chan_sip, which appears to have resolved the issue for at least 2 people.

Thanks to everyone who helped to resolve this issue!