[asterisk-users] Any idea what causes "Oooh, got a frame with format of g729 on channel 'PJSIP/121-000001d2' when we're sending 'ulaw', switching to match"

[Dan Cropp]

I'm reaching out to the asterisk users e-mail list in hopes someone there can provide guidance.  A couple of Digium's developers check this e-mail group so they may respond.  Unfortunately, they are basically in the get ready for show mode.  Major show is next week and they are also releasing the next major version in a matter of days.

Asking if them...
What causes asterisk to output the Oooh, got a frame with format of g729 on channel 'PJSIP/121-000001d2' when we're sending 'ulaw', switching to match
message?
Is it asterisk detecting rtp stream with g729?
Why would asterisk change to g729 stream if the codec negotiation is clearly ulaw in the SIP packets?

Dan Cropp
Senior Software Engineer, R&D Software Dept.
AMTELCO, 4800 Curtin Drive, McFarland, WI 53558-9424
608 838-4197 ext. 291
1-800-238-5275 ext 291
www.amtelco.com<http://www.amtelco.com/>


Statement of Confidentiality
The contents of this e-mail message and any attachments are confidential to American Tel-A-Systems, Inc. (AMTELCO), and are intended solely for the addressee(s). The information contained in this transmission also may be of a legally privileged nature. This transmission is sent in trust and is meant solely for delivery to the intended recipient(s). Receipt of this transmission does not convey any right to reproduce or disseminate any of the information it contains. If you are not the intended recipient, please immediately notify the sender by reply e-mail or telephone and delete this message and any attachments.

From: Dan Cropp
Sent: Wednesday, October 3, 2018 1:57 PM
To: asterisk-users at lists.digium.com
Subject: Any idea what causes "Oooh, got a frame with format of g729 on channel 'PJSIP/121-000001d2' when we're sending 'ulaw', switching to match"

The PJSIP endpoint is configured for ulaw only.  Not sure how or why we are seeing the g729 on calls for this endpoint.

Would this be a case that asterisk detects the rtp stream is g729 even though it's negotiated as ulaw?
Why would asterisk change the format to g729 when disallow = all and allow = ulaw are the endpoint settings?

[121]
type = endpoint
context = IS
transport = transport1
aors = 121
accountcode = 2
dtmf_mode = inband
device_state_busy_at = 96
force_rport = no
identify_by = username,ip
disallow = all
allow = ulaw
from_user = 121
acl = acl1

[10/03 11:29:34.240] DEBUG[21414][C-00000226] chan_pjsip.c: Oooh, got a frame with format of g729 on channel 'PJSIP/121-000001d2' when we're sending 'ulaw', switching to match


INVITE sip:2197 at XXX.XXX.XXX.XXX:5060 SIP/2.0
Via: SIP/2.0/UDP YYY.YYY.YYY.YYY:5060;branch=z9hG4bKxqyYl2Jg84158000
To: <sip:2197@ XXX.XXX.XXX.XXX <sip:2197 at 192.168.11.176> >
From: <sip:STUFF at YYY.YYY.YYY.YYY <sip:STUFF at YYY.YYY.YYY.YYY%20> >;tag=I0n4X7KK
Contact: <sip:STUFF @YYY.YYY.YYY.YYY:5060<sip:STUFF%20 at YYY.YYY.YYY.YYY:5060>>
Call-ID: OlrmFuyOq-0000-@ YYY.YYY.YYY.YYY <mailto:OlrmFuyOq-0000- at 192.168.10.213>
CSeq: 2223 INVITE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,REFER,NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 335

v=0
o=- 11264000 11264000 IN IP4 YYY.YYY.YYY.YYY
s=-
c=IN IP4 192.168.10.213
t=0 0
m=audio 32768 RTP/AVP 0 2 8 18 110 120 100
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:110 G723/5300
a=rtpmap:120 G723/6300
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=sendrecv

Send
SIP/2.0 200 OK
Via: SIP/2.0/UDP YYY.YYY.YYY.YYY:5060;received=YYY.YYY.YYY.YYY;branch=z9hG4bKxqyYl2Jg84158000
Call-ID: OlrmFuyOq-0000- at YYY.YYY.YYY.YYY <mailto:OlrmFuyOq-0000- at YYY.YYY.YYY.YYY%20>
From: <sip:STUFF at YYY.YYY.YYY.YYY >;tag=I0n4X7KK
To: <sip:2197 at XXX.XXX.XXX.XXX <sip:2197 at XXX.XXX.XXX.XXX%20> >;tag=b4134118-08f4-4dbc-a145-573d04438092
CSeq: 2223 INVITE
Server: Asterisk PBX 13.20.0
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Contact: <sip:YYY.YYY.YYY.YYY:5060>
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length:   181

v=0
o=- 11264000 11264002 IN IP4 YYY.YYY.YYY.YYY
s=Asterisk
c=IN IP4 192.168.11.176
t=0 0
m=audio 18380 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
a=maxptime:150
a=sendrecv


Receive
ACK sip:XXX.XXX.XXX.XXX:5060 SIP/2.0
Via: SIP/2.0/UDP YYY.YYY.YYY.YYY:5060;branch=z9hG4bKCIJuiRuH8415a000
To: <sip:2197@ XXX.XXX.XXX.XXX <sip:2197 at 192.168.11.176> >;tag=b4134118-08f4-4dbc-a145-573d04438092
From: <sip:STUFF@ YYY.YYY.YYY.YYY <sip:STUFF@%20YYY.YYY.YYY.YYY%20> >;tag=I0n4X7KK
Max-Forwards: 70
Call-ID: OlrmFuyOq-0000- at YYY.YYY.YYY.YYY<mailto:OlrmFuyOq-0000- at YYY.YYY.YYY.YYY>
CSeq: 2223 ACK


Asterisk debugging outputs the following.
[10/03 11:29:34.240] DEBUG[21414][C-00000226] chan_pjsip.c: Oooh, got a frame with format of g729 on channel 'PJSIP/121-000001d2' when we're sending 'ulaw', switching to match
[10/03 11:29:34.240] DEBUG[21414][C-00000226] channel.c: Channel PJSIP/121-000001d2 setting write format path: ulaw -> g729
[10/03 11:29:34.240] DEBUG[21414][C-00000226] channel.c: Channel PJSIP/121-000001d2 setting read format path: ulaw -> g729
[10/03 11:29:34.240] DEBUG[21414][C-00000226] channel.c: Channel PJSIP/121-000001d2 setting read format path: g729 -> g729

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20181003/daf77b54/attachment.html>