Outbound Codec

dancms · January 3, 2014, 9:14pm

Need some clarification as there really isn’t documentation I could find -

Is it possible and if so how can you set the codec to use on outbound leg?

Using asterisk 11.
In SIP.conf peer definition :
disallow=all
allow=ulaw
allow=g729

Remote peer is forcing g729.

${SIP_CODEC_OUTBOUND} is listed here - wiki.asterisk.org/wiki/display/ … +Variables

exten => 1,Set(SIP_CODEC_OUTBOUND=ulaw)

I also saw some talk about appending a couple underscores to this but not documented anywhere -

exten => 1,Set(__SIP_CODEC_OUTBOUND=ulaw)

I execute this command before dial statement.

Is this the proper syntax for this command or am I missing something?

When performing a core debug:

DEBUG[13604][C-0000193d]: chan_sip.c:13085 add_sdp: ** Our prefcodec: (nothing)
DEBUG[13605][C-0000193e]: res_rtp_asterisk.c:2646 ast_rtp_write: Ooh, format changed from unknown to g729

I also see alot of this:

NOTICE[13996][C-0000209f]: channel.c:4257 __ast_read: Dropping incompatible voice frame on SIP/CMS-SIP-PROXY-00004140 of format ulaw since our native format has changed to (g729)

Is this correct behavior?

Any direction is appreciated.

Thanks!

david55 · January 3, 2014, 11:46pm

It’s documented in the basic documentation about variables.

The line you quote is missing either the extension or the priority.

dancms · January 3, 2014, 11:57pm

Yeah, I miss-typed the example and I did end up finding information on inheritance (the underscore).

exten => s,1,Set(__SIP_CODEC_OUTBOUND=ulaw)

Any other information about what this channel variable does? The only reason I ask is it appears based on the core debug something is out of place.

Thanks for the reply.

dancms · January 4, 2014, 2:43am

To clarify - I ask because when setting SIP_CODEC_OUTBOUND, asterisk still advertises its capabilities as set in peer definition / global sip settings. Is this the correct behavior?

c=IN IP4 x.x.x.x
t=0 0.
m=audio 30078 RTP/AVP 0 18 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.

Here is the core debug for a test call -

[Jan 3 20:59:32] DEBUG[14585][C-0000000e]: chan_sip.c:10686 process_sdp: We’re settling with these formats: (ulaw|g729)
[Jan 3 20:59:32] DEBUG[14585][C-0000000e]: chan_sip.c:7911 sip_new: *** Our native formats are (ulaw)
[Jan 3 20:59:32] DEBUG[14585][C-0000000e]: chan_sip.c:7912 sip_new: *** Joint capabilities are (ulaw|g729)
[Jan 3 20:59:32] DEBUG[14585][C-0000000e]: chan_sip.c:7913 sip_new: *** Our capabilities are (ulaw|g729)
[Jan 3 20:59:32] DEBUG[14585][C-0000000e]: chan_sip.c:7914 sip_new: *** AST_CODEC_CHOOSE formats are ulaw
[Jan 3 20:59:32] DEBUG[14690][C-0000000e]: pbx.c:4633 pbx_extension_helper: Launching ‘Set’
– Executing [s@sub_prefcodec:4] Set(“SIP/xxxxxxxxxxxxxx-0000001c”, “__SIP_OUTBOUND_CODEC=g729”) in new stack
[Jan 3 20:59:32] DEBUG[14690][C-0000000e]: chan_sip.c:29520 sip_request_call: Asked to create a SIP channel with formats: (ulaw)
[Jan 3 20:59:32] DEBUG[14690][C-0000000e]: chan_sip.c:7911 sip_new: *** Our native formats are (ulaw)
[Jan 3 20:59:32] DEBUG[14690][C-0000000e]: chan_sip.c:7912 sip_new: *** Joint capabilities are (ulaw)
[Jan 3 20:59:32] DEBUG[14690][C-0000000e]: chan_sip.c:7913 sip_new: *** Our capabilities are (ulaw|g729)
[Jan 3 20:59:32] DEBUG[14690][C-0000000e]: chan_sip.c:7914 sip_new: *** AST_CODEC_CHOOSE formats are ulaw
[Jan 3 20:59:32] DEBUG[14690][C-0000000e]: chan_sip.c:7916 sip_new: *** Our preferred formats from the incoming channel are (ulaw)
[Jan 3 20:59:32] DEBUG[14690][C-0000000e]: channel.c:6503 ast_channel_inherit_variables: Copying hard-transferable variable SIP_OUTBOUND_CODEC.
[Jan 3 20:59:32] DEBUG[14690][C-0000000e]: chan_sip.c:13084 add_sdp: ** Our capability: (ulaw|g729) Video flag: False Text flag: False
[Jan 3 20:59:32] DEBUG[14690][C-0000000e]: chan_sip.c:13085 add_sdp: ** Our prefcodec: (ulaw)
[Jan 3 20:59:32] DEBUG[14690][C-0000000e]: chan_sip.c:13222 add_sdp: – Done with adding codecs to SDP
[Jan 3 20:59:32] DEBUG[14690][C-0000000e]: chan_sip.c:13420 add_sdp: Done building SDP. Settling with this capability: (ulaw|g729)
[Jan 3 20:59:34] DEBUG[14585][C-0000000e]: chan_sip.c:22457 handle_response_invite: SIP response 200 to standard invite
[Jan 3 20:59:34] DEBUG[14585][C-0000000e]: chan_sip.c:10009 process_sdp: Processing session-level SDP v=0… UNSUPPORTED OR FAILED.
[Jan 3 20:59:34] DEBUG[14585][C-0000000e]: chan_sip.c:10009 process_sdp: Processing session-level SDP s=-… UNSUPPORTED OR FAILED.
[Jan 3 20:59:34] DEBUG[14585][C-0000000e]: chan_sip.c:10009 process_sdp: Processing session-level SDP t=0 0… UNSUPPORTED OR FAILED.
[Jan 3 20:59:34] DEBUG[14585][C-0000000e]: chan_sip.c:10415 process_sdp: Processing media-level (audio) SDP a=rtpmap:18 G729a/8000… OK.
[Jan 3 20:59:34] DEBUG[14585][C-0000000e]: chan_sip.c:10415 process_sdp: Processing media-level (audio) SDP a=fmtp:18 annexb=no… OK.
[Jan 3 20:59:34] DEBUG[14585][C-0000000e]: rtp_engine.c:641 ast_rtp_codecs_payloads_unset: Unsetting payload 100 on 0xb6e446d8
[Jan 3 20:59:34] DEBUG[14585][C-0000000e]: chan_sip.c:10415 process_sdp: Processing media-level (audio) SDP a=rtpmap:100 NSE/8000… UNSUPPORTED OR FAILED.
[Jan 3 20:59:34] DEBUG[14585][C-0000000e]: chan_sip.c:10415 process_sdp: Processing media-level (audio) SDP a=fmtp:100 192-193… UNSUPPORTED OR FAILED.
[Jan 3 20:59:34] DEBUG[14585][C-0000000e]: chan_sip.c:10415 process_sdp: Processing media-level (audio) SDP a=rtpmap:101 telephone-event/8000… OK.
[Jan 3 20:59:34] DEBUG[14585][C-0000000e]: chan_sip.c:10415 process_sdp: Processing media-level (audio) SDP a=fmtp:101 0-15… UNSUPPORTED OR FAILED.
[Jan 3 20:59:34] DEBUG[14585][C-0000000e]: chan_sip.c:10415 process_sdp: Processing media-level (audio) SDP a=ptime:30… OK.
[Jan 3 20:59:34] DEBUG[14585][C-0000000e]: chan_sip.c:10415 process_sdp: Processing media-level (audio) SDP a=sendrecv… OK.
[Jan 3 20:59:34] DEBUG[14585][C-0000000e]: chan_sip.c:10686 process_sdp: We’re settling with these formats: (g729)
[Jan 3 20:59:34] DEBUG[14585][C-0000000e]: chan_sip.c:10693 process_sdp: We have an owner, now see if we need to change this call
[Jan 3 20:59:34] DEBUG[14585][C-0000000e]: channel.c:5361 set_format: Set channel SIP/xxxxxxxxxxxxxx-0000001d to read format ulaw
[Jan 3 20:59:34] DEBUG[14585][C-0000000e]: channel.c:5361 set_format: Set channel SIP/xxxxxxxxxxxxxx-0000001d to write format ulaw
[Jan 3 20:59:34] DEBUG[14690][C-0000000e]: chan_sip.c:13084 add_sdp: ** Our capability: (ulaw|g729) Video flag: True Text flag: True
[Jan 3 20:59:34] DEBUG[14690][C-0000000e]: chan_sip.c:13085 add_sdp: ** Our prefcodec: (nothing)
[Jan 3 20:59:34] DEBUG[14690][C-0000000e]: chan_sip.c:13222 add_sdp: – Done with adding codecs to SDP
[Jan 3 20:59:34] DEBUG[14690][C-0000000e]: chan_sip.c:13420 add_sdp: Done building SDP. Settling with this capability: (ulaw|g729)
[Jan 3 20:59:34] DEBUG[14690][C-0000000e]: rtp_engine.c:989 local_bridge_loop: rtp-engine-local-bridge: Oooh, formats changed, backing out
[Jan 3 20:59:34] DEBUG[14690][C-0000000e]: res_rtp_asterisk.c:2646 ast_rtp_write: Ooh, format changed from unknown to ulaw
[Jan 3 20:59:34] DEBUG[14690][C-0000000e]: res_rtp_asterisk.c:2681 ast_rtp_write: Created smoother: format: ulaw ms: 20 len: 160
[Jan 3 20:59:34] DEBUG[14690][C-0000000e]: res_rtp_asterisk.c:2646 ast_rtp_write: Ooh, format changed from unknown to g729
[Jan 3 20:59:34] DEBUG[14690][C-0000000e]: res_rtp_asterisk.c:2681 ast_rtp_write: Created smoother: format: g729 ms: 20 len: 20

david55 · January 4, 2014, 9:30am

I don’t actually see a media offer in the returned SDP. You probably need to do “sip set debug on” to capture the actual SDP.

The important information here is in NOTICE level messages, not DEBUG ones. If the variable is recognized, you should get a NOTICE saying it was used, or why it wasn’t used.

Do you actually have a G.729 codec and licenses?

dancms · January 4, 2014, 3:45pm

I posted asterisks sdp from sip capture above the core debug, I left out a few lines.

There are no notice messages.

G729 is installed and is licensed. It ultimately works in the call from the core debug and ‘g729 show licenses’ output shows it’s transcoding.

If any other information would be helpful let me know and I will post.

david55 · January 4, 2014, 8:22pm

NOTICE level logs, please. If the variable is recognized, you will get a NOTICE level message, one way, or the other.

I also noticed that your logs had an entry for the Set, but not the Dial. I was wondering if you are using AGI, or something like that, to sequence your applications.

dancms · January 4, 2014, 9:16pm

The only thing in notice log is:
[Jan 4 16:08:34] Asterisk 11.7.0 built by xx @ xx on a i686 running Linux on 2014-01-04 06:31:54 UTC

As for the logs I posted, I omitted everything except SDP related messages. I am using Dial application.

dancms · January 4, 2014, 9:33pm

Ok, cancel that. Here is what notice log shows:

[Jan 4 16:28:38] NOTICE[2802][C-00000040] chan_sip.c: Changing codec to ‘g729’ for this call because of ${SIP_CODEC} variable

However debug shows this behavior -

[Jan 4 16:28:46] DEBUG[2802][C-00000040]: res_rtp_asterisk.c:2707 ast_rtp_write: Ooh, format changed from unknown to ulaw

[Jan  4 16:28:46] DEBUG[2802][C-00000040]: res_rtp_asterisk.c:2707 ast_rtp_write: Ooh, format changed from unknown to g729

david55 · January 4, 2014, 11:31pm

I think the changed format messages indicate that it is receiving G.729 from one peer and Mu-law from the other, which is correct, given that the incoming side preferred ulaw and you forced g.729 on the outgoing side. In other words, I think it is normal behaviour.

dancms · January 4, 2014, 11:50pm

Thats what I wasn’t sure on, given the asterisk sdp message on outbound call identified both ulaw and g729 as it’s capabilities although setting sip codec variable.

Thanks for the information, I will assume its normal at this point.

Thanks again-

david55 · January 5, 2014, 12:58pm

It should only have specified G.729 on the outgoing side, but you would still have the other messages.