[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 15:02:11 CDT 2018

On Wed, Oct 3, 2018 at 2:09 PM Dan Cropp <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

>
>
> 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
>
>
>
>
>
> *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 >
>
> From: <sip:STUFF at YYY.YYY.YYY.YYY >;tag=I0n4X7KK
>
> Contact: <sip:STUFF @YYY.YYY.YYY.YYY:5060>
>
> Call-ID: OlrmFuyOq-0000-@ YYY.YYY.YYY.YYY <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
> <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 >;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 >;tag=b4134118-08f4-4dbc-a145-573d04438092
>
> From: <sip:STUFF@ YYY.YYY.YYY.YYY >;tag=I0n4X7KK
>
> Max-Forwards: 70
>
> Call-ID: 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/eedd7a70/attachment.html>