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-boun...@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@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 <d...@amtelco.com<mailto:d...@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@lists.digium.com<mailto:asterisk-users@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:2...@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:st...@yyy.yyy.yyy.yyy <sip:st...@yyy.yyy.yyy.yyy%20> >;tag=I0n4X7KK Contact: <sip:STUFF @YYY.YYY.YYY.YYY:5060<sip:stuff...@yyy.yyy.yyy.yyy:5060>> Call-ID: OlrmFuyOq-0000-@ YYY.YYY.YYY.YYY <mailto:OlrmFuyOq-0000-@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-00...@yyy.yyy.yyy.yyy <mailto:olrmfuyoq-00...@yyy.yyy.yyy.yyy%20> From: <sip:st...@yyy.yyy.yyy.yyy <sip:st...@yyy.yyy.yyy.yyy%20> >;tag=I0n4X7KK To: <sip:2...@xxx.xxx.xxx.xxx <sip:2...@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-00...@yyy.yyy.yyy.yyy<mailto:olrmfuyoq-00...@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
-- _____________________________________________________________________ -- 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
