[asterisk-bugs] [JIRA] (ASTERISK-24585) One way speech when performing attended Xfer issue appears to be SIP invite related when switching back from native_rtp bridge
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Mon Jan 12 09:29:35 CST 2015
[ https://issues.asterisk.org/jira/browse/ASTERISK-24585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=224379#comment-224379 ]
Matt Jordan commented on ASTERISK-24585:
----------------------------------------
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 at 192.168.5.47:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.5.107:5060;branch=z9hG4bK-ccf81029
From: <sip:707 at 192.168.5.107>;tag=641d5f7eb383343di0
To: "6421624717" <sip:021624717 at 192.168.5.47>;tag=as68de609c
Call-ID: 4ce527a87e4754a34d129d6e3907d0c7 at 192.168.5.47:5060
CSeq: 101 INVITE
Max-Forwards: 70
Contact: "Anonymous" <sip:707 at 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 at 192.168.5.107>;tag=641d5f7eb383343di0
To: "6421624717" <sip:021624717 at 192.168.5.47>;tag=as68de609c
Call-ID: 4ce527a87e4754a34d129d6e3907d0c7 at 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 at 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}}?
> One way speech when performing attended Xfer issue appears to be SIP invite related when switching back from native_rtp bridge
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: ASTERISK-24585
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-24585
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Bridges/bridge_native_rtp, Bridges/bridge_simple
> Affects Versions: 13.0.1
> 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.
> Reporter: Chris Wiltshire
> Assignee: Rusty Newton
> Attachments: Asterisk_One_way_speech_native_rtp_to_simple_bridge.txt, Asterisk_One_way_speech_native_rtp_to_simple_bridge.txt, issue_24585_full_log
>
>
> 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).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list