[asterisk-bugs] [JIRA] (ASTERISK-27223) chan_pjsip: unable to agree on audio codec with AVM Fritz!Box trunk (async rtp issue)
M. Ustermann (JIRA)
noreply at issues.asterisk.org
Tue Aug 29 04:25:08 CDT 2017
[ https://issues.asterisk.org/jira/browse/ASTERISK-27223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=238282#comment-238282 ]
M. Ustermann edited comment on ASTERISK-27223 at 8/29/17 4:23 AM:
------------------------------------------------------------------
I've attached the required debug log, two of them - one with asymmetric_rtp_codec=no (which is default)
==> chan_pjsip.c: Oooh, got a frame with format of alaw on channel 'PJSIP/pj_42002013-00000069' when it has not been negotiated
And one which was made with asymmetric_rtp_codec=yes (which this bug is more about) in which I can see the following suspicious lines:
==> translate.c: Sample size different 160 vs 320
In the second case (asymmetric_rtp_codec=yes) which this bug is more about, I can hear the other side (call to 08003301000) just fine, but audio I send is being garbled.
PJSIP endpoint configuration:
[15]
type=endpoint
aors=15
auth=15-auth
allow=g722,alaw
context=from-internal
callerid=15 <15>
dtmf_mode=rfc4733
aggregate_mwi=yes
use_avpf=no
rtcp_mux=no
ice_support=no
media_use_received_transport=no
trust_id_inbound=yes
media_encryption=no
timers=yes
media_encryption_optimistic=no
send_pai=yes
rtp_symmetric=yes
rewrite_contact=yes
force_rport=yes
language=en
[pj_42002013]
type=endpoint
transport=0.0.0.0-udp
context=from-pstn
disallow=all
allow=g722,alaw,ulaw,gsm,g726
aors=pj_42002013
language=en
outbound_auth=pj_42002013
from_user=0000042002013
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
t38_udptl_nat=no
dtmf_mode=auto
====> THIS LINE IS SET TO YES OR NO DEPENDING ON THE TEST ##########
asymmetric_rtp_codec=yes
====> THIS LINE IS SET TO YES OR NO DEPENDING ON THE TEST ##########
[15-identify]
type=identify
endpoint=15
[pj_42002013]
type=identify
endpoint=pj_42002013
match=192.168.7.1
[pj_42002013]
type=registration
transport=0.0.0.0-udp
outbound_auth=pj_42002013
retry_interval=60
max_retries=10
expiration=600
line=yes
endpoint=pj_42002013
auth_rejection_permanent=yes
contact_user=0000042002013
server_uri=sip:192.168.7.1:5060
client_uri=sip:0000042002013 at 192.168.7.1:5060
PJSIP transport configuration:
[0.0.0.0-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060
allow_reload=yes
local_net=192.168.7.0/255.255.255.0
was (Author: ustermann):
I've attached the required debug log, two of them - one with asymmetric_rtp_codec=no (which is default)
==> chan_pjsip.c: Oooh, got a frame with format of alaw on channel 'PJSIP/pj_42002013-00000069' when it has not been negotiated
And one which was made with asymmetric_rtp_codec=yes (which this bug is more about) in which I can see the following suspicious lines:
==> translate.c: Sample size different 160 vs 320
In the second case (asymmetric_rtp_codec=yes) which this bug is more about, I can hear the other side (call to 08003301000) just fine, but audio I send is being garbled.
PJSIP endpoint configuration:
[15]
type=endpoint
aors=15
auth=15-auth
allow=g722,alaw
context=from-internal
callerid=15 <15>
dtmf_mode=rfc4733
aggregate_mwi=yes
use_avpf=no
rtcp_mux=no
ice_support=no
media_use_received_transport=no
trust_id_inbound=yes
media_encryption=no
timers=yes
media_encryption_optimistic=no
send_pai=yes
rtp_symmetric=yes
rewrite_contact=yes
force_rport=yes
language=en
[pj_42002013]
type=endpoint
transport=0.0.0.0-udp
context=from-pstn
disallow=all
allow=g722,alaw,ulaw,gsm,g726
aors=pj_42002013
language=en
outbound_auth=pj_42002013
from_user=0000042002013
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
t38_udptl_nat=no
dtmf_mode=auto
########## THIS LINE IS SET TO YES OR NO DEPENDING ON THE TEST ##########
asymmetric_rtp_codec=yes
########## THIS LINE IS SET TO YES OR NO DEPENDING ON THE TEST ##########
[15-identify]
type=identify
endpoint=15
[pj_42002013]
type=identify
endpoint=pj_42002013
match=192.168.7.1
[pj_42002013]
type=registration
transport=0.0.0.0-udp
outbound_auth=pj_42002013
retry_interval=60
max_retries=10
expiration=600
line=yes
endpoint=pj_42002013
auth_rejection_permanent=yes
contact_user=0000042002013
server_uri=sip:192.168.7.1:5060
client_uri=sip:0000042002013 at 192.168.7.1:5060
PJSIP transport configuration:
[0.0.0.0-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060
allow_reload=yes
local_net=192.168.7.0/255.255.255.0
> 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)
> 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.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list