thr3ads.net - asterisk users - [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" [Oct 2018]

If this information is useful, please help other people find it:
Share via:

Dan Cropp

2018-Oct-03 18:57 UTC

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

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/8dc68c19/attachment.html>

Dan Cropp

2018-Oct-03 19:08 UTC

head link

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

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>

Richard Mudgett

2018-Oct-03 20:02 UTC

head link

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

asterisk users - Oct 2018 - 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"

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

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

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