[asterisk-bugs] [JIRA] (ASTERISK-27223) chan_pjsip: unable to agree on audio codec with AVM Fritz!Box trunk (async rtp issue)
Rusty Newton (JIRA)
noreply at issues.asterisk.org
Fri Sep 1 14:41:08 CDT 2017
[ https://issues.asterisk.org/jira/browse/ASTERISK-27223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=238427#comment-238427 ]
Rusty Newton commented on ASTERISK-27223:
-----------------------------------------
The capture looks pretty much the same in terms of flow. The correlating Asterisk debug shows me that Asterisk seems to be simply ignoring the codec change in the 200 OK SDP from the far end. When that is received I'd expect Asterisk/PJSIP to do something about the fact that we are transmitting in an unsupported codec. Looks like a bug to me. I'm going to open this up.
> chan_pjsip: unable to agree on audio codec with AVM Fritz!Box trunk (async rtp issue)
> -------------------------------------------------------------------------------------
>
> Key: ASTERISK-27223
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-27223
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_pjsip
> Affects Versions: 14.6.0
> Environment: FreePBX Distro 7
> Reporter: M. Ustermann
> Assignee: Rusty Newton
> Attachments: debug_log_123456_asymmetric_rtp_codec_is_no (default).txt, debug_log_123456_asymmetric_rtp_codec_is_yes.txt, logs-new-2017-08-31.zip, pruned-pcap.pcapng
>
>
> I'm trying to use the SIP server integrated in the AVM Fritz!Box router (a popular and well supported model in Germany) as an Asterisk Trunk. Everything works fine with chan_sip, but with chan_pjsip there are problems negotiating the audio codec.
> I can call some external destinations just fine, but other destinations, presumably those which request PCMA (instead of the prioritized G722) audio will lead to no audio I can hear and garbled audio for the other side.
> rtp_symmetric=yes/no => has no effect
> asymmetric_rtp_codec=yes => this makes it possible for me to hear the other side just fine, but the other side still receives garbled audio from me. I've looked a packet capture and can see the following:
> 1) Asterisk sends an INVITE to the Fritz!Box SIP Server, offering both G722 and G711 PCMA
> 2) Fritz!Box responds in the Status: 183 Session Progress" packet, also offering G722 and G711 PCMA
> Both devices now send G722 packets back and forth during the call setup phase (ringing).
> 3) the call is now accepted by the remote party and Fritz!Box sends a "Status: 200 OK" packet to Asterisk, now only offering G.711 PCMA
> From now on, all voice data coming from the Fritz!Box is using G.711 (which I can properly hear, provided I've set asymmetric_rtp_codec=yes) but all voice data sent to the remote party is still G.722 (which arrives garbled at the remote party).
> My guess is the SIP packet #3 after which the Fritz!Box starts sending PCMA data is also is supposed to make asterisk switch to PCMA. But I of course have no clue if this SIP package is not using the correct syntax for this of if asterisk is not interpreting it correctly.
> SIP Packet #3 contains the following:
> (192.168.7.1 = Fritz!Box, 192.168.7.5 = Asterisk 14.6.0)
> {noformat}
> Session Initiation Protocol (200)
> Status-Line: SIP/2.0 200 OK
> Message Header
> Via: SIP/2.0/UDP 192.168.7.5:5060;rport=5060;branch=z9hG4bKPj35b15360-cba5-42d8-9ba5-c9b3bc89b8f4
> From: <sip:0000042002014 at 192.168.7.5>;tag=2fe7fc32-3275-41a9-9474-58c884b1e53b
> To: <sip:46201501 at 192.168.7.1>;tag=D1E915482207B644
> Call-ID: c80a694c-1953-4a0f-9931-0e832cb6bbab
> CSeq: 9330 INVITE
> Contact: <sip:5EFC81EFC5C6FB7AEB414899110F7 at 192.168.7.1>
> Session-Expires: 1800;refresher=uac
> Min-SE: 90
> User-Agent: AVM FRITZ!Box 7490 113.06.88 (Aug 22 2017)
> Supported: 100rel,replaces,timer
> Allow-Events: telephone-event,refer
> Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
> Content-Type: application/sdp
> Accept: application/sdp, multipart/mixed
> Accept-Encoding: identity
> Content-Length: 216
> Message Body
> Session Description Protocol
> Session Description Protocol Version (v): 0
> Owner/Creator, Session Id (o): user 6757382 6757383 IN IP4 192.168.7.1
> Session Name (s): Asterisk
> Connection Information (c): IN IP4 192.168.7.1
> Time Description, active time (t): 0 0
> Media Description, name and address (m): audio 7082 RTP/AVP 8 101
> Media Type: audio
> Media Port: 7082
> Media Protocol: RTP/AVP
> Media Format: ITU-T G.711 PCMA
> Media Format: DynamicRTP-Type-101
> Media Attribute (a): rtpmap:8 PCMA/8000
> Media Attribute Fieldname: rtpmap
> Media Format: 8
> MIME Type: PCMA
> Sample Rate: 8000
> Media Attribute (a): rtpmap:101 telephone-event/8000
> Media Attribute Fieldname: rtpmap
> Media Format: 101
> MIME Type: telephone-event
> Sample Rate: 8000
> Media Attribute (a): fmtp:101 0-15
> Media Attribute Fieldname: fmtp
> Media Format: 101 [telephone-event]
> Media format specific parameters: 0-15
> Media Attribute (a): sendrecv
> Media Attribute (a): rtcp:7083
> Media Attribute Fieldname: rtcp
> Media Attribute Value: 7083
> {noformat}
> Is this something that needs to be fixed in Asterisk or is it clearly a violation from AVM, the manufacturer of the Fritz!Box? The specific Fritz!Box Model is a 7490, I've tried both the latest final firmware 6.83 as well as the current beta firmware 06.88-46101.
> I will try to attach the .pcap file to this bug.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list