[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