[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"

Wed Oct 3 16:28:29 CDT 2018

Thank you Richard.

That’s what I thought was happening.  Helps to have guidance from an expert.

Have a great day!

Dan

From: asterisk-users <asterisk-users-bounces at lists.digium.com> On Behalf Of Richard Mudgett
Sent: Wednesday, October 3, 2018 3:02 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com>
Subject: Re: [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"

On Wed, Oct 3, 2018 at 2:09 PM Dan Cropp <dan at amtelco.com<mailto:dan at amtelco.com>> wrote:
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?

Because Asterisk received a G729 RTP packet from the other side and is being accommodating because asymmetric_rtp_codec=no is set.
In this case the other side is in error by not honoring the negotiation.

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?

This is mostly historical.  chan_sip didn't keep track of the truly negotiated codecs in the channel's native capabilities.  So if the peer's INVITE
asked for five codecs and Asterisk supported three of them, we would respond with the three and then pick the one we were going to use and put it into the
channel's native capabilities.  chan_pjsip has the asymmetric_rtp_codec option to emulate this same behavior which results in the "Oooh"
message you are seeing.  If that option were disabled we would put those three codecs in the channel's native capabilities.  Then you would get
this debug message instead:
"Oooh, got a frame with format of %s on channel '%s' when it has not been negotiated"
and the frame would be discarded.

The primary reason for chan_sip's behavior and chan_pjsip's asymmetric_rtp_codec=no option is because phone DSP's can only handle
a single codec at a time.  Technically if the peer's INVITE offered five and we responded with three the peer should immediately renegotiate to narrow the
codec choice to one.

Richard

From: Dan Cropp
Sent: Wednesday, October 3, 2018 1:57 PM
To: asterisk-users at lists.digium.com<mailto: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@%20XXX.XXX.XXX.XXX%20> >
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 <sip:STUFF at YYY.YYY.YYY.YYY%20> >;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@%20XXX.XXX.XXX.XXX%20> >;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

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Astricon is coming up October 9-11!  Signup is available at: https://www.asterisk.org/community/astricon-user-conference

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
      https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20181003/1d847660/attachment.html>