[Asterisk-Dev] (Re)Invite for codec change

Andrew Lindh asterisk at ntplx.net
Mon Nov 29 13:51:59 MST 2004


I don't always need asterisk in the media path. I need to make sure it stays
in there somewhere for billing/accounting, music on hold, "extension" status,
and other cool or required features. The only things it needs to be in the
media path for is pound (#) transfers, which I don't use, or
wiretaping/recording....not every call.

An issue is asterisk as an IVR/voice mail and mismatched calls. If I am
connected to the IVR/voicemail as G.711 and then transfer to a device/user
that uses G.729 it would be nice to have asterisk not have to transcode.
I don't care if it stays in the middle, but I don't want to burn CPU time
doing simething the device DSP can do.

Here is an example from a call from x301 to x389. The call is setup as
G.711 but the other phone only supports G729A. I don't want asterisk to
completely get out of the way, I just want it to make sure they both use
g.729 (x301 supports both, but defaults to g.711). There is no need for
asterisk to transcode as x301 supports g729 too. But I don't want to force
every call to the lowest codec....

(sip show channels)
204.213.176.229  389         323d84c72f0  00102/00000   G729A 
204.213.176.201  301         d02cda15-f9  00101/00002   ULAW  


>Date: Mon, 29 Nov 2004 15:12:32 -0500
>From: Karl Brose <khb at brose.com>
>Subject: Re: [Asterisk-Dev] (Re)Invite for codec change
>To: Andrew Lindh <asterisk at ntplx.net>, Asterisk Developers Mailing List 
<asterisk-dev at lists.digium.com>
>
>
>Don't know if I grasp the issue correctly, but I think if Asterisk where 
>smarter about SIP media
>setup it probably wouldn't have to stay in the media path just for DTMF 
>or transfers in many cases.
>To do so, it only needs a one-way channel from the end of the call from 
>where DTMF or other
>inband signaling is expected and doesn't have to stay in the path for 
>the translation of the entire
>call. That means your gateway could do all the hard work, and * would 
>just sit there and listen
>for any signaling.  It should be possible with some work on the SDP 
>offer/answer model in SIP.
>Is this what you would like to address?
>
>Andrew Lindh wrote:
>
>>Is there any thought to enable/support/force a (re)invite to only change
>>codecs on "bridged" channels that no longer have matching codecs? This
>>would reduce asterisk transcoding overhead while still allowing asterisk
>>to stay in the middle of a call for billing/hold/etc...It would be nice
>>to support lots of devices/users on the same system without killing it
>>or scaling with lots of systems.
>>
>>I'm not clear if SIP allows this and how well devices will deal with it.
>>
>>The idea is if a PRI is on a gateway (say cisco 5300) and it uses g.711 to
>>the asterisk for IVR and then gets transfered to an off-site location
>>that wants to use g.729. There is no reason asterisk should have to do
>>all the work. The gateway has DSPs that can do G.729......I know one answer
>>is to just use G.729 or GSM for everything, but it's not a usable answer.
>>The only thing that everything supports and does not eat CPU time is G.711
>>
>>Yes I know if it's a PRI on TDM card in the asterisk box then something has
>>to do compression anyway, but there are a lot of external gateways that
>>have lot's of DSP time waiting to be used.
>>
>>  Andrew
>>  
>>
>>_______________________________________________
>>Asterisk-Dev mailing list
>>Asterisk-Dev at lists.digium.com
>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>>To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>>  
>>




More information about the asterisk-dev mailing list