[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
Thu Aug 31 15:10:07 CDT 2017
[ https://issues.asterisk.org/jira/browse/ASTERISK-27223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rusty Newton updated ASTERISK-27223:
------------------------------------
Description:
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.
was:
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)
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
---
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.
> 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: Unassigned
> Attachments: debug_log_123456_asymmetric_rtp_codec_is_no (default).txt, debug_log_123456_asymmetric_rtp_codec_is_yes.txt, 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