[Home]

Summary:ASTERISK-24253: Attended transfers with directmedia enabled sometimes set wrong rtp address
Reporter:Eli Hunter (elihunter)Labels:
Date Opened:2014-08-21 00:37:21Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Channels/chan_sip/General
Versions:12.4.0 13.18.4 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:( 0) dump.pcap
( 1) full_log
( 2) full_sample
( 3) sip.conf
Description:I've been testing directmedia with endpoints and see failures in about 1 out of 5 attended transfers.  It's using the endpoint's internal network address rather than the external IP.  The server is at a public IP and the endpoint is behind NAT.  I changed the IP the enpoint is behind to 1.1.1.1 and the sip provider's IP to 2.2.2.2.

I thought it was the same as ASTERISK-23497 but it seems to be different and it wasn't fixed by upgrading from 12.2.0 to 12.4.0.

Working transfer:
{noformat}
== Using SIP RTP TOS bits 184
 == Using SIP RTP CoS mark 5
   -- Called SIP/313
   -- SIP/313-0000060a is ringing
   -- SIP/313-0000060a answered SIP/312-00000609
   -- Channel SIP/312-00000609 joined 'simple_bridge' basic-bridge <bfdd32fe-19a3-4438-9b46-59af26be886a>
   -- Channel SIP/313-0000060a joined 'simple_bridge' basic-bridge <bfdd32fe-19a3-4438-9b46-59af26be886a>
      > Bridge bfdd32fe-19a3-4438-9b46-59af26be886a: switching from simple_bridge technology to native_rtp
      > 0x7fcde0015080 -- Probation passed - setting RTP source address to 1.1.1.1:2228

Got  RTP packet from    1.1.1.1:2228 (type 09, seq 011738, ts 3706243606, len 000160)
Sent RTP packet to      2.2.2.2:19500 (type 00, seq 012279, ts 2001056, len 000160)
Sent RTP P2P packet to 1.1.1.1:2228 (type 00, len 000160)
Got  RTP packet from    1.1.1.1:2228 (type 09, seq 011739, ts 3706243766, len 000160)
Sent RTP packet to      2.2.2.2:19500 (type 00, seq 012280, ts 2001216, len 000160)
{noformat}

Failed transfer:
{noformat}
   -- Called SIP/312
   -- SIP/312-00000608 is ringing
   -- SIP/312-00000608 answered SIP/313-00000607
   -- Channel SIP/313-00000607 joined 'simple_bridge' basic-bridge <36553219-70fa-46fa-a6cd-85b45e4e615b>
   -- Channel SIP/312-00000608 joined 'simple_bridge' basic-bridge <36553219-70fa-46fa-a6cd-85b45e4e615b>
      > Bridge 36553219-70fa-46fa-a6cd-85b45e4e615b: switching from simple_bridge technology to native_rtp
      > 0x7fcde8705c30 -- Probation passed - setting RTP source address to 1.1.1.1:2226
      > 0x7fcde8705c30 -- Probation passed - setting RTP source address to 1.1.1.1:2226

Sent RTP packet to      10.1.11.18:2228 (type 09, seq 044259, ts 28978992, len 000160)
Got  RTP packet from    2.2.2.2:19500 (type 00, seq 007364, ts 1178240, len 000160)
Sent RTP packet to      10.1.11.18:2228 (type 09, seq 044260, ts 28979152, len 000160)
{noformat}
Comments:By: Matt Jordan (mjordan) 2014-08-22 08:36:51.139-0500

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: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Go ahead and get a full debug log with the appropriate SIP debugging enabled. A pcap would also be helpful.
By: Eli Hunter (elihunter) 2014-08-22 09:05:43.588-0500

full debug log - call transfer between 313 and 15555555555 transferred 312 then back to 313
By: Eli Hunter (elihunter) 2014-08-22 09:10:41.530-0500

I've attached a full debug log calling 15555555555 (replaced the real phone number) from extension 313 then performing an attended transfer to 312 which gave dead air, and back to 313 which got audio working again.  

The debug log is rather busy since there's a lot of other endpoints registering and it's using a fairly complex ael script.  I replaced the asterisk server address with x.x.x.x and the endpoints are at 10.1.11.12 and 10.1.11.18.

By: Rusty Newton (rnewton) 2014-09-10 09:06:20.661-0500

Yeah it is unclear for me without a correlation packet capture so that I can see flow in wireshark.

Can you get debug again and a pcap that correlates to that traffic?
Still be sure to include the "sip set debug on" output in the asterisk log.

Anything you can do to simplify of course helps.. if you can reproduce without the complex scripts you mentioned then even better.
By: Rusty Newton (rnewton) 2014-09-25 16:29:00.300-0500

I'm closing this out, as there hasn't been a response for a while and we still need further information to determine if this is a bug or not.

It sounds like a bug, but I can't reproduce and I can't find any other reports of the issue. So, the developers don't have a way to reproduce on their systems for testing and diagnosing.

If someone wants to re-open this issue, then we need the following information:

* A guide to reproduction including
** sip.conf
** extensions.conf
** Any other configs required, and steps for reproduction.
* Logs/debug
** PCAP demonstrating the issue
** Asterisk log with VERBOSE and DEBUG correlating to the PCAP.

If you need to talk with a bug marshal or need help understanding how to get this information you can find us on irc.freenode.net in #asterisk-bugs and #asterisk-dev.

Thanks!
By: Eli Hunter (elihunter) 2014-10-17 02:50:04.391-0500

debug log and pcap
By: Eli Hunter (elihunter) 2014-10-17 14:54:34.687-0500

sip.conf
By: Eli Hunter (elihunter) 2014-10-17 14:59:58.817-0500

I've attached a pcap, log, and my sip.conf with my providers' trunks removed.
I setup an asterisk 12.4 server and just added two extensions in extensions.conf and a provider and tested this but was not able to reproduce this.  I think that means it has to have something to do with the ael script that's being used but I can't see how that would cause it.


By: Eli Hunter (elihunter) 2014-10-23 00:54:37.653-0500

I downgraded asterisk 12.2 to 11.12 and didn't change any config files and do not have this problem so it seems something changed with Asterisk 12 to cause this.
By: Eli Hunter (elihunter) 2015-08-23 01:35:55.724-0500

Can this one be reopened with the files attached last October?  I need to upgrade and am seeing the same behavior in current 12.x and 13.x versions.  I uploaded a pcap, log, and sip.conf last October.  I can run through this again if new logs are needed.
By: Asterisk Team (asteriskteam) 2015-08-23 01:35:56.307-0500

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.