[OpenSIPS-Users] codec manipulation feature
Jeff Pyle
jpyle at fidelityvoice.com
Tue Jun 16 13:48:20 CEST 2009
Exactly. This would be so incredibly useful.
Imagine a customer with a SIP-based PRI and a T1¹s worth of bandwidth behind
it. This is a common scenario for my customers. We try to avoid running
all G.729 wherever possible because of the obvious and ugly audio quality
hit. At G.711 I can only let them use 17 channels on their 23 channel PRI.
That¹s fine for many customers but a fraction think they need or actually
need all 23 channels. Some can afford second T1 to allow them access to the
remaining 6 channels. How about <drum roll please> dynamic codec selection
by the proxy.
We¹ve already worked out the math and routing logic in Opensips, provided we
have the following items in the customer¹s profile:
* Total bandwidth available to customer (pick a circuit type, or input raw
kbps)
* Minimum percentage bandwidth reserved for data
* Total number of calls required
Given this information, Opensips can compute how many calls we can leave at
G.711 and after what point we have to start compressing them into G.729 (by
verifying G.729 in the SDP, and removing G.711). Thank you dialog module.
For example, on a 1.5 meg T1 with 15% reserved for data, the formula says I
can allow 12 channels at G.711, but have to compress the remaining 11. With
a 5% data margin I can get away with 15 uncompressed and 8 compressed.
Everything¹s just about ready except for the ability to work on the SDP to
make it happen.
- Jeff
On 6/15/09 9:23 PM, "Brett Nemeroff" <brett at nemeroff.com> wrote:
> Nice.. That's about what I had in mind.. I'll be looking for more discussion
> regarding this. :)
> -Brett
>
>
> On Mon, Jun 15, 2009 at 8:21 PM, Bogdan-Andrei Iancu <bogdan at voice-system.ro>
> wrote:
>> Hi Brett,
>>
>>
>> Brett Nemeroff wrote:
>>> my $0.02 here.. I'm not sure if this is what you guys had in mind.. but I've
>>> had situations where this would be handy.. It'd need to have some way of
>>> identifing the codec (by number?). I'm not sure if the core really has
>>> anything that parses the SDP by RFC spec,
>> there is an SDP parser in the core :)
>>
>>> so I'm not sure how you'd do things like "removing g729 codec including the
>>> annex=b annotation".
>> but not sure if so complex :D (like relation between the SDP fields).
>>
>>> But imaging that anything is possible:
>>>
>> what we had in mind was to add functions to:
>>
>> 1) test if a codec is advertised
>> 2) remove codecs
>> 3) change the priority between the existing codecs
>>
>>
>> Regards,
>> bogdan
>>
>>> I imagine functions:
>>> reject_codec: reject a call if a codec matches
>>> remove_codec: remove an offered codec
>>> codec_present: returns true if codec specified is offered
>>>
>>> if (reject_codec('ulaw')) {
>>> sl_send_reply("488","ULAW Calls not allowed");
>>> exit;
>>> }
>>>
>>>
>>> if ((codec_present('ULAW')) && codec_present('G729a')) {
>>> remove_codec('ULAW');
>>> xlog("L_INFO","Removing bad codec: ULAW");
>>> }
>>>
>>> if (!codec_present('G729a')){
>>> sl_send_reply("488","Please send G729a calls");
>>> }
>>>
>>>
>>> On Mon, Jun 15, 2009 at 3:02 PM, Jeff Pyle <jpyle at fidelityvoice.com
>>> <mailto:jpyle at fidelityvoice.com>> wrote:
>>>
>>> Hi Bogdan,
>>>
>>> It¹s been a little while since we talked about this. I was
>>> wondering if there was anything in the works to detect and/or
>>> manipulate the codecs present in an SDP.
>>>
>>>
>>>
>>> - Jeff
>>>
>>>
>>>
>>>
>>> On 2/1/09 4:08 AM, "Steve Kurzeja" <steve.kurzeja at gmail.com
>>> <http://steve.kurzeja@gmail.com <http://gmail.com> >> wrote:
>>>
>>> This idea is quite standard in SBCs, typically called codec
>>> profiles, where you permit only certain codecs to be passed
>>> through the SBC in an INVITE and all the rest are stripped out.
>>>
>>> We use it to get around interop issues with certain codecs.
>>> E.g. we have some end devices/customers that have issues using
>>> g729a so we choose to remove this codec for these specific
>>> endpoints.
>>>
>>> The poor man's method to implementing this is just doing
>>> header manipulations in the SDP but it would be nice to be
>>> standardized.
>>>
>>> Regards,
>>> Steve
>>>
>>>
>>> On Fri, Jan 30, 2009 at 2:20 AM, Jeff Pyle
>>> <jpyle at fidelityvoice.com <http://jpyle@fidelityvoice.com
>>> <http://fidelityvoice.com> >> wrote:
>>>
>>> Hi Bogdan,
>>>
>>> I'm looking for the ability to selectively remove codec
>>> advertisements from
>>> the SDP. For example, if my customer sends a call to me
>>> for PSTN
>>> termination he may advertise G711 and G729, with G711
>>> preferred. By looking
>>> at the number of existing dialogs I may know that he's
>>> running low on
>>> bandwidth, so I would like to suppress the G711
>>> advertisement ultimately
>>> causing a 200 OK from the carrier with G729.
>>>
>>> Generically, in this application we're looking only to
>>> suppress G711 at
>>> certain times.
>>>
>>> I understand normally codec selection is done completely
>>> by the gateway
>>> device. However, my gateway devices aren't smart enough to
>>> take bandwidth
>>> utilization into consideration when choosing which codecs
>>> to advertise. I'm
>>> hoping my proxy might be. :)
>>>
>>> Does that make sense?
>>>
>>>
>>>
>>> - Jeff
>>>
>>>
>>>
>>> On 1/29/09 5:04 AM, "Bogdan-Andrei Iancu"
>>> <bogdan at voice-system.ro <http://bogdan@voice-system.ro
>>> <http://voice-system.ro> >>
>>>
>>> wrote:
>>>
>>> > Hi Jeff,
>>> >
>>> > right now there is only available some functionality to
>>> check the codecs
>>> > (to see what codecs are advertised in the SDP)... What
>>> exactly are you
>>> > looking for (like codec ops) ?
>>> >
>>> > Regards,
>>> > Bogdan
>>> >
>>> > Jeff Pyle wrote:
>>> >> Bogdan,
>>> >>
>>> >> Some months back you mentioned an upcoming feature that
>>> would allow
>>> >> Opensips to manipulate the codecs present in the SDP.
>>> Just wondering
>>> >> if there is anything available to test yet. This feature, in
>>> >> combination with dialog contexts, will be of great use
>>> to us to allow
>>> >> us to take a guess at the bandwidth consumption for a
>>> particular
>>> >> customer and force the use of a compressed codec if
>>> necessary.
>>> >>
>>> >>
>>> >> Thanks,
>>> >> Jeff
>>> >
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <http://Users@lists.opensips.org
>>> <http://lists.opensips.org> >
>>>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090616/7bedef46/attachment.htm
More information about the Users
mailing list