[asterisk-bugs] [JIRA] (ASTERISK-26423) res_pjsip_sdp_rtp: Asymmetric RTP codec can cause audio loss and wonkiness
Andreas Wetzel (JIRA)
noreply at issues.asterisk.org
Sat Oct 8 04:53:07 CDT 2016
[ https://issues.asterisk.org/jira/browse/ASTERISK-26423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=232562#comment-232562 ]
Andreas Wetzel edited comment on ASTERISK-26423 at 10/8/16 4:51 AM:
--------------------------------------------------------------------
This is what a short call from the S850A GO to an ekiga softphone that has been deliberately configured to allow for alaw and ulaw only looks like. This setup exhibits the same problem as when placing an outbound call from the S850A GO through my ITSP. All endpoints are set to allow for g722, alaw and ulaw and have direct_media disabled, so that audio has to pass through asterisk. You can see that from the moment the call is picked up, the S850A GO is continously sending reinvites to asterisk:
{noformat}
No. Timestamp (Dir) Address SIP Message
===== ========== ============================== ===================================
00000 1475913733 * <== 10.6.6.64:5060 INVITE sip:301 at rakanishu.de;user=phone SIP/2.0
00001 1475913733 * ==> 10.6.6.64:5060 SIP/2.0 401 Unauthorized
00002 1475913733 * <== 10.6.6.64:5060 ACK sip:301 at rakanishu.de;user=phone SIP/2.0
00003 1475913733 * <== 10.6.6.64:5060 INVITE sip:301 at rakanishu.de;user=phone SIP/2.0
00004 1475913733 * ==> 10.6.6.64:5060 SIP/2.0 100 Trying
00005 1475913733 * ==> 10.6.8.6:5060 INVITE sip:ekiga at 10.6.8.6 SIP/2.0
00006 1475913733 * <== 10.6.8.6:5060 SIP/2.0 100 Trying
00007 1475913733 * <== 10.6.8.6:5060 SIP/2.0 180 Ringing
00008 1475913733 * ==> 10.6.6.64:5060 SIP/2.0 180 Ringing
00009 1475913736 * <== 10.6.8.6:5060 SIP/2.0 200 OK
00010 1475913736 * ==> 10.6.8.6:5060 ACK sip:ekiga at 10.6.8.6 SIP/2.0
00011 1475913736 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00012 1475913737 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00013 1475913737 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00014 1475913737 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00015 1475913737 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00016 1475913737 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00017 1475913737 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00018 1475913737 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00019 1475913737 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00020 1475913737 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00021 1475913737 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00022 1475913737 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00023 1475913737 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00024 1475913737 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00025 1475913737 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00026 1475913737 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00027 1475913737 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00028 1475913738 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00029 1475913738 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00030 1475913738 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00031 1475913738 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00032 1475913738 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00033 1475913738 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00034 1475913738 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00035 1475913738 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00036 1475913738 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00037 1475913738 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00038 1475913738 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00039 1475913738 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00040 1475913738 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00041 1475913738 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00042 1475913738 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00043 1475913738 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00044 1475913738 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00045 1475913739 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00046 1475913739 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00047 1475913739 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00048 1475913739 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00049 1475913739 * <== 10.6.6.64:5060 BYE sip:10.6.6.1:5060 SIP/2.0
00050 1475913739 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00051 1475913739 * ==> 10.6.8.6:5060 BYE sip:ekiga at 10.6.8.6 SIP/2.0
00052 1475913739 * <== 10.6.8.6:5060 SIP/2.0 200 OK
{noformat}
The initial INVITE from the S850A GO to asterisk looks like this:
{noformat}
<--- History Entry 3 Received from 10.6.6.64:5060 at 1475913733 --->
INVITE sip:301 at rakanishu.de;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.6.6.64:5060;rport=5060;received=10.6.6.64;branch=z9hG4bKade1c634dd173d62f8c3eb3780f35d36
From: <sip:S850A-1 at rakanishu.de>;tag=1659051246
To: <sip:301 at rakanishu.de;user=phone>
Call-ID: 4125927375 at 10_6_6_64
CSeq: 3 INVITE
Contact: <sip:S850A-1 at 10.6.6.64:5060>
Authorization: Digest username="S850A-1", realm="rakanishu.de", nonce="1475913733/5c5efdb918c389e6c7a84fe1459d7a97", uri="sip:301 at rakanishu.de;user=phone", response="878fb5463208e432f9b8bc9bb987f640", algorithm=md5, cnonce="c6a6c96e27e5e5ccccfb17212c3e986", opaque="6205d84a6dbb5632", qop=auth, nc=00000001
Max-Forwards: 70
User-Agent: S850A GO/42.238.00.000.000
Supported: replaces
Allow-Events: message-summary, refer, ua-profile, talk, check-sync
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE
Content-Type: application/sdp
Content-Length: 240
Content-Type: application/sdp
Content-Length: 240
v=0
o=S850A-1 5012 4 IN IP4 10.6.6.64
s=Mapping
c=IN IP4 10.6.6.64
t=0 0
m=audio 5012 RTP/AVP 9 8 0 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
{noformat}
And asterisk's reply:
{noformat}
<--- History Entry 11 Sent to 10.6.6.64:5060 at 1475913736 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.6.6.64:5060;rport=5060;received=10.6.6.64;branch=z9hG4bKade1c634dd173d62f8c3eb3780f35d36
Call-ID: 4125927375 at 10_6_6_64
From: <sip:S850A-1 at rakanishu.de>;tag=1659051246
To: <sip:301 at rakanishu.de;user=phone>;tag=8c881966-ea65-40ea-8225-25247f769f23
CSeq: 3 INVITE
Server: ACME
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Contact: <sip:10.6.6.1:5060>
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length: 261
v=0
o=- 5012 6 IN IP4 78.51.220.96
s=ACME
c=IN IP4 10.6.6.1
t=0 0
m=audio 5006 RTP/AVP 9 8 0 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
{noformat}
>From the information in the sdp of the initial INVITE, asterisk seems to assume that it's ok to send alaw encoded RTP to the S850A GO, and as the audio coming in from the ekiga client is alaw encoded it tries to avoid transcoding and just wants to pass the data along as is. But when the S850A GO receives RTP encoded in a format different than the one it has chosen internally, it sends reINVITEs, asking for exclusive use of the chosen codec, which asterisk confirms in the OK reply. Yet asterisk/pjsip continues to send alaw encoded RTP to the S850A GO, leading to an endless loop of reINVITEs and only one way audio:
{noformat}
<--- History Entry 13 Received from 10.6.6.64:5060 at 1475913737 --->
INVITE sip:10.6.6.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.6.6.64:5060;rport=5060;received=10.6.6.64;branch=z9hG4bK370b7b836bef75f99801f70229a94f07
From: <sip:S850A-1 at rakanishu.de>;tag=1659051246
To: <sip:301 at rakanishu.de;user=phone>;tag=8c881966-ea65-40ea-8225-25247f769f23
Call-ID: 4125927375 at 10_6_6_64
CSeq: 4 INVITE
Contact: <sip:S850A-1 at 10.6.6.64:5060>
Authorization: Digest username="S850A-1", realm="rakanishu.de", nonce="1475913733/5c5efdb918c389e6c7a84fe1459d7a97", uri="sip:10.6.6.1:5060", response="7c1d4f6de1e80f2d3a7f07638f770794", algorithm=md5, cnonce="fd549e07868b0abc7f442e56782bc509", opaque="6205d84a6dbb5632", qop=auth, nc=00000002
Max-Forwards: 70
User-Agent: S850A GO/42.238.00.000.000
Supported: replaces
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE
Content-Type: application/sdp
Content-Length: 192
Content-Type: application/sdp
Content-Length: 192
v=0
o=S850A-1 5012 5 IN IP4 10.6.6.64
s=Mapping
c=IN IP4 10.6.6.64
t=0 0
m=audio 5012 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
<--- History Entry 14 Sent to 10.6.6.64:5060 at 1475913737 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.6.6.64:5060;rport=5060;received=10.6.6.64;branch=z9hG4bK370b7b836bef75f99801f70229a94f07
Call-ID: 4125927375 at 10_6_6_64
From: <sip:S850A-1 at rakanishu.de>;tag=1659051246
To: <sip:301 at rakanishu.de;user=phone>;tag=8c881966-ea65-40ea-8225-25247f769f23
CSeq: 4 INVITE
Contact: <sip:10.6.6.1:5060>
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Server: ACME
Content-Type: application/sdp
Content-Length: 213
v=0
o=- 5012 7 IN IP4 78.51.220.96
s=ACME
c=IN IP4 10.6.6.1
t=0 0
m=audio 5006 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
<--- History Entry 15 Received from 10.6.6.64:5060 at 1475913737 --->
ACK sip:10.6.6.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.6.6.64:5060;rport=5060;received=10.6.6.64;branch=z9hG4bKa1f03562b7d4df1ecde9e8251f06d528
From: <sip:S850A-1 at rakanishu.de>;tag=1659051246
To: <sip:301 at rakanishu.de;user=phone>;tag=8c881966-ea65-40ea-8225-25247f769f23
Call-ID: 4125927375 at 10_6_6_64
CSeq: 4 ACK
Contact: <sip:S850A-1 at 10.6.6.64:5060>
Authorization: Digest username="S850A-1", realm="rakanishu.de", nonce="1475913733/5c5efdb918c389e6c7a84fe1459d7a97", uri="sip:10.6.6.1:5060", response="7c1d4f6de1e80f2d3a7f07638f770794", algorithm=md5, cnonce="fd549e07868b0abc7f442e56782bc509", opaque="6205d84a6dbb5632", qop=auth, nc=00000002
Max-Forwards: 70
User-Agent: S850A GO/42.238.00.000.000
Content-Length: 0
Content-Length: 0
{noformat}
Excerpt from the RTP log shows that asterisk is indeed receiving g722 encoded RTP (type=09) from the S850A GO, but is sending alaw encoded RTP (type=08) to the S850A GO:
{noformat}
[2016-10-08 10:02:18.919] VERBOSE[100951][C-00000004] res_rtp_asterisk.c: Got RTP packet from 10.6.6.64:5012 (type 09, seq 000176, ts 17428160, len 000160)
[2016-10-08 10:02:18.923] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:18.939] VERBOSE[100951][C-00000004] res_rtp_asterisk.c: Got RTP packet from 10.6.6.64:5012 (type 09, seq 000177, ts 17428320, len 000160)
[2016-10-08 10:02:18.943] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:18.963] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:18.983] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.003] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.023] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.039] VERBOSE[100951][C-00000004] res_rtp_asterisk.c: Got RTP packet from 10.6.6.64:5012 (type 09, seq 000178, ts 17428480, len 000160)
[2016-10-08 10:02:19.042] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.059] VERBOSE[100951][C-00000004] res_rtp_asterisk.c: Got RTP packet from 10.6.6.64:5012 (type 09, seq 000179, ts 17428640, len 000160)
[2016-10-08 10:02:19.063] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.079] VERBOSE[100951][C-00000004] res_rtp_asterisk.c: Got RTP packet from 10.6.6.64:5012 (type 09, seq 000180, ts 17428800, len 000160)
[2016-10-08 10:02:19.083] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.099] VERBOSE[100951][C-00000004] res_rtp_asterisk.c: Got RTP packet from 10.6.6.64:5012 (type 09, seq 000181, ts 17428960, len 000160)
[2016-10-08 10:02:19.103] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.119] VERBOSE[100951][C-00000004] res_rtp_asterisk.c: Got RTP packet from 10.6.6.64:5012 (type 09, seq 000182, ts 17429120, len 000160)
[2016-10-08 10:02:19.123] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.143] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.163] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.183] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.203] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.223] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.226] VERBOSE[100951][C-00000004] res_rtp_asterisk.c: Got RTP packet from 10.6.6.64:5012 (type 09, seq 000183, ts 17429280, len 000160)
[2016-10-08 10:02:19.243] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.246] VERBOSE[100951][C-00000004] res_rtp_asterisk.c: Got RTP packet from 10.6.6.64:5012 (type 09, seq 000184, ts 17429440, len 000160)
[2016-10-08 10:02:19.264] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.291] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
[2016-10-08 10:02:19.303] VERBOSE[100954][C-00000004] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5012 (type 08, len 000160)
{noformat}
And the pjsip.conf file with personal information anonymized:
{noformat}
;===================================================================
; PJSIP Configuration
;===================================================================
;
; Global options that apply to all SIP communications.
;
[global]
type = global
user_agent = ACME
default_from_user = acme
default_realm = rakanishu.de
disable_multi_domain = yes
;
; Transport definitions.
;
[transport-udp]
type = transport
protocol = udp
bind = 0.0.0.0
tos = cs4
;
; Templates for use in other configuration sections.
;
[ep-common](!)
type = endpoint
transport = transport-udp
sdp_session = ACME
tos_audio = cs5
disallow = all
allow = g722,alaw,ulaw
user_eq_phone = yes
allow_subscribe = no
[ep-internal](!,ep-common)
context = local-in
device_state_busy_at = 2
direct_media = no
[ep-o2](!,ep-common)
context = o2-in
direct_media = no
from_domain = sip.my.itsp
trust_id_inbound = yes
allow_transfer = no
[auth-userpass](!)
type = auth
auth_type = userpass
[aor-dynamic](!)
type = aor
max_contacts = 1
[reg-o2](!)
type = registration
transport = transport-udp
server_uri = sip:sip.my.itsp
retry_interval = 60
line = yes
;
; Phone configuration
;
; Gigaset S850A-GO
[S850A-1](ep-internal)
aors = S850A-1
auth = auth-S850A-1
deny = 0.0.0.0/0
permit = 10.6.6.64
[S850A-1](aor-dynamic)
[auth-S850A-1](auth-userpass)
username = S850A-1
password = topsecret
; Ekiga
[ekiga](ep-internal)
aors = ekiga
auth = auth-ekiga
deny = 0.0.0.0/0
permit = 10.6.8.6
[ekiga](aor-dynamic)
[auth-ekiga](auth-userpass)
username = ekiga
password = topsecret
;
; Provider configuration
;
; Outbound authentication
[auth-o2-17](auth-userpass)
username = MY-DID-1
password = topsecret1
[auth-o2-18](auth-userpass)
username = MY-DID-2
password = topsecret2
[auth-o2-19](auth-userpass)
username = MY-DID-3
password = topsecret3
[auth-o2-20](auth-userpass)
username = MY-DID-4
password = topsecret4
; ITSP AOR
[aor-o2]
type = aor
contact = sip:sip.my.itsp
; ITSP endpoints
[ep-o2-17](ep-o2)
outbound_auth = auth-o2-17
aors = aor-o2
from_user = MY-DID-1
[ep-o2-18](ep-o2)
outbound_auth = auth-o2-18
aors = aor-o2
from_user = MY-DID-2
[ep-o2-19](ep-o2)
outbound_auth = auth-o2-19
aors = aor-o2
from_user = MY-DID-3
t38_udptl = yes
t38_udptl_ec = fec
[ep-o2-20](ep-o2)
outbound_auth = auth-o2-20
aors = aor-o2
from_user = MY-DID-4
; Outbound registrations
[reg-o2-17](reg-o2)
outbound_auth = auth-o2-17
client_uri = sip:MY-DID-1 at sip.my.itsp
contact_user = MY-DID-1
endpoint = ep-o2-17
[reg-o2-18](reg-o2)
outbound_auth = auth-o2-18
client_uri = sip:MY-DID-2 at sip.my.itsp
contact_user = MY-DID-2
endpoint = ep-o2-18
[reg-o2-19](reg-o2)
outbound_auth = auth-o2-19
client_uri = sip:MY-DID-3 at sip.my.itsp
contact_user = MY-DID-3
endpoint = ep-o2-19
[reg-o2-20](reg-o2)
outbound_auth = auth-o2-20
client_uri = sip:MY-DID-4 at sip.my.itsp
contact_user = MY-DID-4
endpoint = ep-o2-20
{noformat}
was (Author: rakanishu):
This is what a short call from the S850A GO to an ekiga softphone that has been deliberately configured to allow for alaw and ulaw only looks like. This setup exhibits the same problem as when placing an outbound call from the S850A GO through my ITSP. All endpoints are set to allow for g722, alaw and ulaw and have direct_media disabled, so that audio has to pass through asterisk. You can see that from the moment the call is picked up, the S850A GO is continously sending reinvites to asterisk:
{noformat}
No. Timestamp (Dir) Address SIP Message
===== ========== ============================== ===================================
00000 1474943946 * <== 10.6.6.64:5060 INVITE sip:301 at rakanishu.de;user=phone SIP/2.0
00001 1474943946 * ==> 10.6.6.64:5060 SIP/2.0 401 Unauthorized
00002 1474943946 * <== 10.6.6.64:5060 ACK sip:301 at rakanishu.de;user=phone SIP/2.0
00003 1474943946 * <== 10.6.6.64:5060 INVITE sip:301 at rakanishu.de;user=phone SIP/2.0
00004 1474943946 * ==> 10.6.6.64:5060 SIP/2.0 100 Trying
00005 1474943946 * ==> 10.6.8.6:5060 INVITE sip:ekiga at 10.6.8.6 SIP/2.0
00006 1474943946 * <== 10.6.8.6:5060 SIP/2.0 100 Trying
00007 1474943946 * <== 10.6.8.6:5060 SIP/2.0 180 Ringing
00008 1474943946 * ==> 10.6.6.64:5060 SIP/2.0 180 Ringing
00009 1474943949 * <== 10.6.8.6:5060 SIP/2.0 200 OK
00010 1474943949 * ==> 10.6.8.6:5060 ACK sip:ekiga at 10.6.8.6 SIP/2.0
00011 1474943949 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00012 1474943949 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00013 1474943949 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00014 1474943949 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00015 1474943949 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00016 1474943949 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00017 1474943949 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00018 1474943949 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00019 1474943949 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00020 1474943949 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00021 1474943949 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00022 1474943949 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00023 1474943949 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00024 1474943949 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00025 1474943950 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00026 1474943950 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00027 1474943950 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00028 1474943950 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00029 1474943950 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00030 1474943950 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00031 1474943950 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00032 1474943950 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00033 1474943950 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00034 1474943950 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00035 1474943950 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00036 1474943950 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00037 1474943950 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00038 1474943950 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00039 1474943950 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00040 1474943950 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00041 1474943950 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00042 1474943951 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00043 1474943951 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00044 1474943951 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00045 1474943951 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00046 1474943951 * <== 10.6.6.64:5060 INVITE sip:10.6.6.1:5060 SIP/2.0
00047 1474943951 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00048 1474943951 * <== 10.6.6.64:5060 ACK sip:10.6.6.1:5060 SIP/2.0
00049 1474943951 * <== 10.6.6.64:5060 BYE sip:10.6.6.1:5060 SIP/2.0
00050 1474943951 * ==> 10.6.6.64:5060 SIP/2.0 200 OK
00051 1474943951 * ==> 10.6.8.6:5060 BYE sip:ekiga at 10.6.8.6 SIP/2.0
00052 1474943951 * <== 10.6.8.6:5060 SIP/2.0 200 OK
{noformat}
The initial INVITE from the S850A GO to asterisk looks like this:
{noformat}
<--- History Entry 3 Received from 10.6.6.64:5060 at 1474943946 --->
INVITE sip:301 at rakanishu.de;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.6.6.64:5060;rport=5060;received=10.6.6.64;branch=z9hG4bK6368f87429c180f3c28af16b4704c109
From: <sip:S850A-1 at rakanishu.de>;tag=1896629790
To: <sip:301 at rakanishu.de;user=phone>
Call-ID: 108510824 at 10_6_6_64
CSeq: 3 INVITE
Contact: <sip:S850A-1 at 10.6.6.64:5060>
Authorization: Digest username="S850A-1", realm="rakanishu.de", nonce="1474943946/271e3214022754ddd80cd9d2f0c597a5", uri="sip:301 at rakanishu.de;user=phone", response="1811260a05e00c79a898867779a07071", algorithm=md5, cnonce="b5a856ad3a999305d5b04860900ff5f0", opaque="408339a9673ee8fb", qop=auth, nc=00000001
Max-Forwards: 70
User-Agent: S850A GO/42.238.00.000.000
Supported: replaces
Allow-Events: message-summary, refer, ua-profile, talk, check-sync
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE
Content-Type: application/sdp
Content-Length: 241
Content-Type: application/sdp
Content-Length: 241
v=0
o=S850A-1 5018 12 IN IP4 10.6.6.64
s=Mapping
c=IN IP4 10.6.6.64
t=0 0
m=audio 5018 RTP/AVP 9 8 0 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
{noformat}
And asterisk's reply:
{noformat}
<--- History Entry 5 Sent to 10.6.8.6:5060 at 1474943946 --->
INVITE sip:ekiga at 10.6.8.6 SIP/2.0
Via: SIP/2.0/UDP 10.6.8.1:5060;rport;branch=z9hG4bKPj13cbd5f2-bfb9-4431-9ac2-3d90c0bbf23d
From: <sip:S850A-1 at 77.180.12.87>;tag=79572edd-31a8-4c87-a42e-2ed49c02880f
To: <sip:ekiga at 10.6.8.6>
Contact: <sip:acme at 10.6.8.1:5060>
Call-ID: 79fb74cc-50f6-4874-b78c-951707b20278
CSeq: 5038 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: ACME
Content-Type: application/sdp
Content-Length: 274
v=0
o=- 965256989 965256989 IN IP4 77.180.12.87
s=ACME
c=IN IP4 10.6.8.1
t=0 0
m=audio 5008 RTP/AVP 9 8 0 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
{noformat}
>From the information in the sdp of the initial INVITE, asterisk seems to assume that it's ok to send alaw encoded RTP to the S850A GO, and as the audio coming in from the ekiga client is alaw encoded it tries to avoid transcoding and just wants to pass the data along as is. But when the S850A GO receives RTP encoded in a format different than the one it has chosen internally, it sends reINVITEs, asking for exclusive use of the chosen codec, which asterisk confirms in the OK reply. Yet asterisk/pjsip continues to send alaw encoded RTP to the S850A GO, leading to an endless loop of reINVITEs and only one way audio:
{noformat}
<--- History Entry 13 Received from 10.6.6.64:5060 at 1474943949 --->
INVITE sip:10.6.6.1:5060 SIP/2.0
Via: SIP/2.0/UDP 10.6.6.64:5060;rport=5060;received=10.6.6.64;branch=z9hG4bK18455ba8af14b2a461e7db96c333eb96
From: <sip:S850A-1 at rakanishu.de>;tag=1896629790
To: <sip:301 at rakanishu.de;user=phone>;tag=37192fea-ccee-401f-9931-ad661910ee57
Call-ID: 108510824 at 10_6_6_64
CSeq: 4 INVITE
Contact: <sip:S850A-1 at 10.6.6.64:5060>
Authorization: Digest username="S850A-1", realm="rakanishu.de", nonce="1474943946/271e3214022754ddd80cd9d2f0c597a5", uri="sip:10.6.6.1:5060", response="672257ec85309206254f9ded3238560a", algorithm=md5, cnonce="6487fc6713c76f7de0f37152d8f2dfec", opaque="408339a9673ee8fb", qop=auth, nc=00000002
Max-Forwards: 70
User-Agent: S850A GO/42.238.00.000.000
Supported: replaces
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE
Content-Type: application/sdp
Content-Length: 193
Content-Type: application/sdp
Content-Length: 193
v=0
o=S850A-1 5018 13 IN IP4 10.6.6.64
s=Mapping
c=IN IP4 10.6.6.64
t=0 0
m=audio 5018 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
<--- History Entry 14 Sent to 10.6.6.64:5060 at 1474943949 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.6.6.64:5060;rport=5060;received=10.6.6.64;branch=z9hG4bK18455ba8af14b2a461e7db96c333eb96
Call-ID: 108510824 at 10_6_6_64
From: <sip:S850A-1 at rakanishu.de>;tag=1896629790
To: <sip:301 at rakanishu.de;user=phone>;tag=37192fea-ccee-401f-9931-ad661910ee57
CSeq: 4 INVITE
Contact: <sip:10.6.6.1:5060>
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Server: ACME
Content-Type: application/sdp
Content-Length: 214
v=0
o=- 5018 15 IN IP4 77.180.12.87
s=ACME
c=IN IP4 10.6.6.1
t=0 0
m=audio 5006 RTP/AVP 9 101
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
{noformat}
Excerpt from the RTP log shows that asterisk is indeed receiving g722 encoded RTP (type=09) from the S850A GO, but is sending alaw encoded RTP (type=08) to the S850A GO:
{noformat}
[2016-09-27 04:39:11.178] VERBOSE[101491][C-00000008] res_rtp_asterisk.c: Got RTP packet from 10.6.6.64:5018 (type 09, seq 000110, ts 376480, len 000160)
[2016-09-27 04:39:11.196] VERBOSE[101547][C-00000008] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5018 (type 08, len 000160)
[2016-09-27 04:39:11.216] VERBOSE[101547][C-00000008] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5018 (type 08, len 000160)
[2016-09-27 04:39:11.236] VERBOSE[101547][C-00000008] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5018 (type 08, len 000160)
[2016-09-27 04:39:11.257] VERBOSE[101547][C-00000008] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5018 (type 08, len 000160)
[2016-09-27 04:39:11.268] VERBOSE[101491][C-00000008] res_rtp_asterisk.c: Got RTP packet from 10.6.6.64:5018 (type 09, seq 000111, ts 376640, len 000160)
[2016-09-27 04:39:11.277] VERBOSE[101547][C-00000008] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5018 (type 08, len 000160)
[2016-09-27 04:39:11.288] VERBOSE[101491][C-00000008] res_rtp_asterisk.c: Got RTP packet from 10.6.6.64:5018 (type 09, seq 000112, ts 376800, len 000160)
[2016-09-27 04:39:11.296] VERBOSE[101547][C-00000008] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5018 (type 08, len 000160)
[2016-09-27 04:39:11.308] VERBOSE[101491][C-00000008] res_rtp_asterisk.c: Got RTP packet from 10.6.6.64:5018 (type 09, seq 000113, ts 376960, len 000160)
[2016-09-27 04:39:11.316] VERBOSE[101547][C-00000008] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5018 (type 08, len 000160)
[2016-09-27 04:39:11.328] VERBOSE[101491][C-00000008] res_rtp_asterisk.c: Got RTP packet from 10.6.6.64:5018 (type 09, seq 000114, ts 377120, len 000160)
[2016-09-27 04:39:11.336] VERBOSE[101547][C-00000008] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5018 (type 08, len 000160)
[2016-09-27 04:39:11.348] VERBOSE[101491][C-00000008] res_rtp_asterisk.c: Got RTP packet from 10.6.6.64:5018 (type 09, seq 000115, ts 377280, len 000160)
[2016-09-27 04:39:11.356] VERBOSE[101547][C-00000008] res_rtp_asterisk.c: Sent RTP P2P packet to 10.6.6.64:5018 (type 08, len 000160)
{noformat}
And the pjsip.conf file with personal information anonymized:
{noformat}
;===================================================================
; PJSIP Configuration
;===================================================================
;
; Global options that apply to all SIP communications.
;
[global]
type = global
user_agent = ACME
default_from_user = acme
default_realm = rakanishu.de
disable_multi_domain = yes
;
; Transport definitions.
;
[transport-udp]
type = transport
protocol = udp
bind = 0.0.0.0
tos = cs4
;
; Templates for use in other configuration sections.
;
[ep-common](!)
type = endpoint
transport = transport-udp
sdp_session = ACME
tos_audio = cs5
disallow = all
allow = g722,alaw,ulaw
user_eq_phone = yes
allow_subscribe = no
[ep-internal](!,ep-common)
context = local-in
device_state_busy_at = 2
direct_media = no
[ep-o2](!,ep-common)
context = o2-in
direct_media = no
from_domain = sip.my.itsp
trust_id_inbound = yes
allow_transfer = no
[auth-userpass](!)
type = auth
auth_type = userpass
[aor-dynamic](!)
type = aor
max_contacts = 1
[reg-o2](!)
type = registration
transport = transport-udp
server_uri = sip:sip.my.itsp
retry_interval = 60
line = yes
;
; Phone configuration
;
; Gigaset S850A-GO
[S850A-1](ep-internal)
aors = S850A-1
auth = auth-S850A-1
deny = 0.0.0.0/0
permit = 10.6.6.64
[S850A-1](aor-dynamic)
[auth-S850A-1](auth-userpass)
username = S850A-1
password = topsecret
; Ekiga
[ekiga](ep-internal)
aors = ekiga
auth = auth-ekiga
deny = 0.0.0.0/0
permit = 10.6.8.6
[ekiga](aor-dynamic)
[auth-ekiga](auth-userpass)
username = ekiga
password = topsecret
;
; Provider configuration
;
; Outbound authentication
[auth-o2-17](auth-userpass)
username = MY-DID-1
password = topsecret1
[auth-o2-18](auth-userpass)
username = MY-DID-2
password = topsecret2
[auth-o2-19](auth-userpass)
username = MY-DID-3
password = topsecret3
[auth-o2-20](auth-userpass)
username = MY-DID-4
password = topsecret4
; ITSP AOR
[aor-o2]
type = aor
contact = sip:sip.my.itsp
; ITSP endpoints
[ep-o2-17](ep-o2)
outbound_auth = auth-o2-17
aors = aor-o2
from_user = MY-DID-1
[ep-o2-18](ep-o2)
outbound_auth = auth-o2-18
aors = aor-o2
from_user = MY-DID-2
[ep-o2-19](ep-o2)
outbound_auth = auth-o2-19
aors = aor-o2
from_user = MY-DID-3
t38_udptl = yes
t38_udptl_ec = fec
[ep-o2-20](ep-o2)
outbound_auth = auth-o2-20
aors = aor-o2
from_user = MY-DID-4
; Outbound registrations
[reg-o2-17](reg-o2)
outbound_auth = auth-o2-17
client_uri = sip:MY-DID-1 at sip.my.itsp
contact_user = MY-DID-1
endpoint = ep-o2-17
[reg-o2-18](reg-o2)
outbound_auth = auth-o2-18
client_uri = sip:MY-DID-2 at sip.my.itsp
contact_user = MY-DID-2
endpoint = ep-o2-18
[reg-o2-19](reg-o2)
outbound_auth = auth-o2-19
client_uri = sip:MY-DID-3 at sip.my.itsp
contact_user = MY-DID-3
endpoint = ep-o2-19
[reg-o2-20](reg-o2)
outbound_auth = auth-o2-20
client_uri = sip:MY-DID-4 at sip.my.itsp
contact_user = MY-DID-4
endpoint = ep-o2-20
{noformat}
> res_pjsip_sdp_rtp: Asymmetric RTP codec can cause audio loss and wonkiness
> --------------------------------------------------------------------------
>
> Key: ASTERISK-26423
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-26423
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Resources/res_pjsip_sdp_rtp
> Affects Versions: 13.11.2
> Environment: FreeBSD 10.3-RELEASE-p8 i386
> Gigaset S850A GO IP phone
> Reporter: Andreas Wetzel
> Assignee: Unassigned
>
> This is an interoperability issue between asterisk/pjsip and a Gigaset S850A GO IP telephone due to way codecs are negotiated between both devices.
> When a call is placed from the S850A GO the initial INVITE message contains the list of configured codecs in the preferred order, i.e. g722, pcma, pcmu. When asterisk responds with OK, it also presents the configured codec list and preferred order, lets assume it's also g722, pcma, pcmu. What the S850A GO now seems to be doing is to pick the first codec from asterisk's list which it also supports. If asterisk now sends RTP data to the S850A GO, that is encoded in a format different than the one it has picked, the phone sends reINVITEs whose sdp only contains the single codec it has chosen. Asterisk confirms that it would respect this and sends OK with also only the single codec, but continues to send RTP data encoded in a different format, leading to an endless loop of reINVITEs and OK messages, with only one way audio. This occurs for example when calling an extension that does only support pcma and pcmu, in which case asterisk will send alaw encoded RTP to the S850A GO, as it was in it's list of supported codecs.
> I understand that this issue is in part caused by the firmware of the S850A GO phone. Similar issues seem to exist with a number of other manufacturers like Grandstream, Yealink and Snom. Nevertheless I feel that asterisk/pjsip is not behaving correctly in this regard either. If asterisk acknowledges the use of a single codec as was requested by the device in the reINVITE message, then it should obey that and not continue sending differently encoded RTP to the device.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list