[Home]

Summary:ASTERISK-24585: One way speech when performing attended Xfer issue appears to be SIP invite related when switching back from native_rtp bridge
Reporter:Chris Wiltshire (cretti)Labels:
Date Opened:2014-12-02 16:08:21.000-0600Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Bridges/bridge_native_rtp Bridges/bridge_simple
Versions:13.0.1 Frequency of
Occurrence		Constant
Related
Issues:
is duplicated byASTERISK-24543 Asterisk 13 responds to SIP Invite with all possible codecs configured for peer as opposed to intersection of configured codecs and offered codecs
Environment:Server: Virtual image, VSphere 5.5, Guest OS: Ubuntu 14.10. Network: Simple LAN behind NAT'ing firewall. VoIP Service: External, IAX trunks providing external connectivity, registrations passing out through stateful firewall, no pinholing. Internal client devices: Linksys SPA942 SIP phones.Attachments:( 0) Asterisk_One_way_speech_native_rtp_to_simple_bridge.txt
( 1) Asterisk_One_way_speech_native_rtp_to_simple_bridge.txt
( 2) extensions_conf_edited.txt
( 3) issue_24585_full_log
( 4) rtp_conf.txt
( 5) sip_conf.txt
( 6) users_conf_edited.txt
Description:Outlined in additional detail in forum thread:
http://forums.asterisk.org/viewtopic.php?f=1&t=91945&p=204700#p204700

One way speech occurs after attended transfer of inward call.

Parties: Caller, Party A, Party B.

Caller calls in via IAX trunk and passes to Party A. Party A then performs an attended transfer and speaks to Party B. During this Caller hears music on hold. After introduction Party A completes attended transfer and connects Caller to Party B. At this point one way speech occurs, Party B can hear the Caller, but the Caller cannot hear Party B.

Work-around: suspend bridge technology native_rtp.

Hypothosis: When the two local parties talk during the attended transfer the bridging mode is switched to native_rtp. The IAX Caller channel is remote and cannot support rtp, so a switch back from native_rtp bridge mode to simple is attempted. During this switch back, it appears that there may be an issue with SIP commands issued?.

Investigations:
- A straight forward non-attended transfer does not bring about this issues.
- An attended transfer (exactly the same usecase) with native_rtp suspended does not bring about this issue.

Our experience in the forum was helpful with SIP debug and further tracing being performed. It was then that we were encouraged to log an issue here.

I have CLI trace for both active and suspended native_rtp test cases. I will upload them to this issue thread shortly (as attachments).
Comments:By: David Woolley (davidw) 2014-12-03 02:10:23.229-0600

The SIP trace on the forum shows a transition to simple bridge being logged, but no re-invite being sent.
By: Rusty Newton (rnewton) 2014-12-05 08:40:12.119-0600

Please attach all relevant traces and information from the forum post to this JIRA issue. The link is great, but all the info we need should be attached or formatted here.

Make sure the CLI logs have DEBUG messages enabled, and have the SIP trace integrated.
By: Rusty Newton (rnewton) 2014-12-05 08:40:36.889-0600

Press Enter Feedback or Send Back once you have attached all the relevant debug.
By: Chris Wiltshire (cretti) 2014-12-08 01:18:58.081-0600

This is all I have prepared for you.

If you need more, then it may take a while as I'm knee deep in RFP response writing and will be until the 17th Nov.

?? I uploaded a file with this, I have no idea where it went to. ??
By: Chris Wiltshire (cretti) 2014-12-08 01:20:58.887-0600

CLI trace and debug.
By: Chris Wiltshire (cretti) 2014-12-08 01:22:39.317-0600

Files appear to have been uploaded...
By: Richard Mudgett (rmudgett) 2014-12-08 12:02:54.767-0600

Only mark files as contributions when they are patches to Asterisk.  Code contributions are not visible unless you have signed the licensing agreement.  Debug trace files are not code contributions and should not be marked as contributions.
By: Rusty Newton (rnewton) 2014-12-09 15:54:14.951-0600

Due to the issues Richard mentioned, you'll need to re-attach your debug. However I was able to look at it in the history tab and it does not include the "DEBUG" logger channel type.

Here are some instructions to help you get the right settings turned on: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Once you have CLI logs with the DEBUG logger channel turned on (level 5 or above please and showing in the log) and SIP trace integrated then attach it to the issue (not as a contribution, so it'll show up).
By: Rusty Newton (rnewton) 2014-12-30 18:56:38.388-0600

We still need the requested information. However, can you also test this in the very latest SVN of 13?

Additionally can you provide an example configuration for the endpoints and dialplan involved in your reproduction scenario?

Thanks!
By: Chris Wiltshire (cretti) 2015-01-11 22:38:00.840-0600

Full debug and sip trace for failing call. Can you please take a look at this and if you need me to get into providing segments of my dialplan or other specific config files please let me know. - This was running a freshly compiled build from the very latest SVN checkout.

Asterisk SVN--r430470
By: Chris Wiltshire (cretti) 2015-01-11 22:39:25.375-0600

Have built new version today based on Asterisk SVN--r430470 and created full debug with SIP trace integrated and uploaded that full log file as an attachment. Hopefully I've done everything correctly.

Thanks, sorry this has taken me so long to get to, it has been hard to free up the time required.
By: Matt Jordan (mjordan) 2015-01-12 09:28:37.868-0600

This actually looks like a duplicate of ASTERISK-24543. There is a bug in {{chan_sip}} that specifying {{allow=all}} will cause Asterisk to respond back to an incoming INVITE request with all codecs configured on the SIP peer, as opposed to the intersection of the offer and the configured codecs.

This can be seen here in the log:

{noformat}
[Jan 12 17:29:11] VERBOSE[3052] chan_sip.c:
<--- SIP read from UDP:192.168.5.107:5060 --->
INVITE sip:021624717@192.168.5.47:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.5.107:5060;branch=z9hG4bK-ccf81029
From: <sip:707@192.168.5.107>;tag=641d5f7eb383343di0
To: "6421624717" <sip:021624717@192.168.5.47>;tag=as68de609c
Call-ID: 4ce527a87e4754a34d129d6e3907d0c7@192.168.5.47:5060
CSeq: 101 INVITE
Max-Forwards: 70
Contact: "Anonymous" <sip:707@192.168.5.107:5060>
Expires: 30
User-Agent: Linksys/SPA942-6.1.3(a)
Content-Length: 230
Content-Type: application/sdp

v=0
o=- 27200292 27200293 IN IP4 192.168.5.107
s=-
c=IN IP4 0.0.0.0
t=0 0
m=audio 16386 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-15
a=ptime:30
a=sendonly
<------------->
{noformat}

To which we respond with:

{noformat}
[Jan 12 17:29:11] VERBOSE[3052][C-0000000b] chan_sip.c:
<--- Reliably Transmitting (no NAT) to 192.168.5.107:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.5.107:5060;branch=z9hG4bK-ccf81029;received=192.168.5.107
From: <sip:707@192.168.5.107>;tag=641d5f7eb383343di0
To: "6421624717" <sip:021624717@192.168.5.47>;tag=as68de609c
Call-ID: 4ce527a87e4754a34d129d6e3907d0c7@192.168.5.47:5060
CSeq: 101 INVITE
Server: Asterisk PBX SVN--r430470
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:021624717@192.168.5.47:5060>
Content-Type: application/sdp
Content-Length: 1097

v=0
o=root 479982219 479982220 IN IP4 192.168.5.47
s=Asterisk PBX SVN--r430470
c=IN IP4 192.168.5.47
t=0 0
m=audio 19218 RTP/AVP 0 9 4 8 3 111 112 5 10 122 118 123 124 125 126 127 96 7 18 110 117 119 97 102 115 116 107 101
a=rtpmap:0 PCMU/8000
a=rtpmap:9 G722/8000
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:112 AAL2-G726-32/8000
a=rtpmap:5 DVI4/8000
a=rtpmap:10 L16/8000
a=rtpmap:122 L16/12000
a=rtpmap:118 L16/16000
a=rtpmap:123 L16/24000
a=rtpmap:124 L16/32000
a=rtpmap:125 L16/44000
a=rtpmap:126 L16/48000
a=rtpmap:127 L16/96000
a=rtpmap:96 L16/192000
a=rtpmap:7 LPC/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:110 speex/8000
a=rtpmap:117 speex/16000
a=rtpmap:119 speex/32000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=0
a=rtpmap:102 G7221/16000
a=fmtp:102 bitrate=32000
a=rtpmap:115 G7221/32000
a=fmtp:115 bitrate=48000
a=rtpmap:116 G719/48000
a=fmtp:116 bitrate=64000
a=rtpmap:107 opus/48000/2
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=maxptime:20
a=recvonly

<------------>
{noformat}

It isn't surprising this would cause a codec mishap in a native RTP bridge.

Can you confirm the configuration of the codecs on the SIP peers - in particular, {{707}}?
By: Chris Wiltshire (cretti) 2015-01-13 18:58:07.699-0600

Just to ensure that I was clear previously:
- Call from external party arrives over IAX, presented directly to 707.
- 707 starts an attended Xfer and speaks to 706. - This is when the native rtp bridge functions, and this works fine.
- When 707 pushes the caller through to 706, this is when the speech path from 706 to the caller is never established.
- Its when 706 transitions back from native rtp (with 707) to simple bridge (with caller) that the 706 speech path into that bridge (or the caller's listening path from the bridge) is not correctly established.

You've said it's likely to cause problems with native_rtp, however that portion between the two local SIP peers is working fine.
You've asked specifically for the config relating to 707, however the issue is more closely related to 706.

It's these two points which made me want to re-state the problem. Can you please let me know what portions of the configs you're specifically interested in. This is our production system so I'm likely to need to pull portions out as needed.

Thanks,

Chris.
By: Chris Wiltshire (cretti) 2015-01-13 19:18:34.153-0600

Attached are the config files I think you might need / take an interest in... I've had to edit sections of the files which I've renamed as edited. If you need any more info from me please feel free to ask. I'll try to respond quickly.

Thanks, Chris.
By: Chris Wiltshire (cretti) 2015-01-13 19:19:18.533-0600

Additional content added for your review. Thanks.
By: Chris Wiltshire (cretti) 2015-02-05 17:11:59.513-0600

Do you need anything else from me? Did I provide everything you wanted?

Thank you. - Chris.
By: Rusty Newton (rnewton) 2015-04-13 19:28:38.429-0500

I think that is everything we need at the moment. Thanks!