<HTML>
<HEAD>
<TITLE>Re: [OpenSIPS-Users] codec manipulation feature</TITLE>
</HEAD>
<BODY>
<FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'>Exactly. This would be so incredibly useful.<BR>
<BR>
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.<BR>
<BR>
We’ve already worked out the math and routing logic in Opensips, provided we have the following items in the customer’s profile:<BR>
</SPAN></FONT><UL><LI><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'>Total bandwidth available to customer (pick a circuit type, or input raw kbps)
</SPAN></FONT><LI><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'>Minimum percentage bandwidth reserved for data
</SPAN></FONT><LI><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'>Total number of calls required<BR>
</SPAN></FONT></UL><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'><BR>
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.<BR>
<BR>
<BR>
- Jeff<BR>
<BR>
<BR>
<BR>
On 6/15/09 9:23 PM, "Brett Nemeroff" <<a href="brett@nemeroff.com">brett@nemeroff.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'>Nice.. That's about what I had in mind.. I'll be looking for more discussion regarding this. :)<BR>
-Brett<BR>
<BR>
<BR>
On Mon, Jun 15, 2009 at 8:21 PM, Bogdan-Andrei Iancu <<a href="bogdan@voice-system.ro">bogdan@voice-system.ro</a>> wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'>Hi Brett,<BR>
<BR>
<BR>
Brett Nemeroff wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'>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,<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'>there is an SDP parser in the core :)<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'>so I'm not sure how you'd do things like "removing g729 codec including the annex=b annotation".<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'>but not sure if so complex :D (like relation between the SDP fields).<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'>But imaging that anything is possible:<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'>what we had in mind was to add functions to:<BR>
<BR>
1) test if a codec is advertised<BR>
2) remove codecs<BR>
3) change the priority between the existing codecs<BR>
<BR>
<BR>
Regards,<BR>
bogdan<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'>I imagine functions:<BR>
reject_codec: reject a call if a codec matches<BR>
remove_codec: remove an offered codec<BR>
codec_present: returns true if codec specified is offered<BR>
<BR>
if (reject_codec('ulaw')) {<BR>
sl_send_reply("488","ULAW Calls not allowed");<BR>
exit;<BR>
}<BR>
<BR>
<BR>
if ((codec_present('ULAW')) && codec_present('G729a')) {<BR>
remove_codec('ULAW');<BR>
xlog("L_INFO","Removing bad codec: ULAW");<BR>
}<BR>
<BR>
if (!codec_present('G729a')){<BR>
sl_send_reply("488","Please send G729a calls");<BR>
}<BR>
<BR>
<BR>
On Mon, Jun 15, 2009 at 3:02 PM, Jeff Pyle <<a href="jpyle@fidelityvoice.com">jpyle@fidelityvoice.com</a> <<a href="mailto:jpyle@fidelityvoice.com>">mailto:jpyle@fidelityvoice.com></a>> wrote:<BR>
<BR>
Hi Bogdan,<BR>
<BR>
It’s been a little while since we talked about this. I was<BR>
wondering if there was anything in the works to detect and/or<BR>
manipulate the codecs present in an SDP.<BR>
<BR>
<BR>
<BR>
- Jeff<BR>
<BR>
<BR>
<BR>
<BR>
On 2/1/09 4:08 AM, "Steve Kurzeja" <<a href="steve.kurzeja@gmail.com">steve.kurzeja@gmail.com</a><BR>
<<a href="http://steve.kurzeja@gmail.com">http://steve.kurzeja@gmail.com</a> <<a href="http://gmail.com">http://gmail.com</a>> >> wrote:<BR>
<BR>
This idea is quite standard in SBCs, typically called codec<BR>
profiles, where you permit only certain codecs to be passed<BR>
through the SBC in an INVITE and all the rest are stripped out.<BR>
<BR>
We use it to get around interop issues with certain codecs.<BR>
E.g. we have some end devices/customers that have issues using<BR>
g729a so we choose to remove this codec for these specific<BR>
endpoints.<BR>
<BR>
The poor man's method to implementing this is just doing<BR>
header manipulations in the SDP but it would be nice to be<BR>
standardized.<BR>
<BR>
Regards,<BR>
Steve<BR>
<BR>
<BR>
On Fri, Jan 30, 2009 at 2:20 AM, Jeff Pyle<BR>
<<a href="jpyle@fidelityvoice.com">jpyle@fidelityvoice.com</a> <<a href="http://jpyle@fidelityvoice.com">http://jpyle@fidelityvoice.com</a> <<a href="http://fidelityvoice.com">http://fidelityvoice.com</a>> >> wrote:<BR>
<BR>
Hi Bogdan,<BR>
<BR>
I'm looking for the ability to selectively remove codec<BR>
advertisements from<BR>
the SDP. For example, if my customer sends a call to me<BR>
for PSTN<BR>
termination he may advertise G711 and G729, with G711<BR>
preferred. By looking<BR>
at the number of existing dialogs I may know that he's<BR>
running low on<BR>
bandwidth, so I would like to suppress the G711<BR>
advertisement ultimately<BR>
causing a 200 OK from the carrier with G729.<BR>
<BR>
Generically, in this application we're looking only to<BR>
suppress G711 at<BR>
certain times.<BR>
<BR>
I understand normally codec selection is done completely<BR>
by the gateway<BR>
device. However, my gateway devices aren't smart enough to<BR>
take bandwidth<BR>
utilization into consideration when choosing which codecs<BR>
to advertise. I'm<BR>
hoping my proxy might be. :)<BR>
<BR>
Does that make sense?<BR>
<BR>
<BR>
<BR>
- Jeff<BR>
<BR>
<BR>
<BR>
On 1/29/09 5:04 AM, "Bogdan-Andrei Iancu"<BR>
<<a href="bogdan@voice-system.ro">bogdan@voice-system.ro</a> <<a href="http://bogdan@voice-system.ro">http://bogdan@voice-system.ro</a> <<a href="http://voice-system.ro">http://voice-system.ro</a>> >><BR>
<BR>
wrote:<BR>
<BR>
> Hi Jeff,<BR>
><BR>
> right now there is only available some functionality to<BR>
check the codecs<BR>
> (to see what codecs are advertised in the SDP)... What<BR>
exactly are you<BR>
> looking for (like codec ops) ?<BR>
><BR>
> Regards,<BR>
> Bogdan<BR>
><BR>
> Jeff Pyle wrote:<BR>
>> Bogdan,<BR>
>><BR>
>> Some months back you mentioned an upcoming feature that<BR>
would allow<BR>
>> Opensips to manipulate the codecs present in the SDP.<BR>
Just wondering<BR>
>> if there is anything available to test yet. This feature, in<BR>
>> combination with dialog contexts, will be of great use<BR>
to us to allow<BR>
>> us to take a guess at the bandwidth consumption for a<BR>
particular<BR>
>> customer and force the use of a compressed codec if<BR>
necessary.<BR>
>><BR>
>><BR>
>> Thanks,<BR>
>> Jeff<BR>
><BR>
<BR>
<BR>
_______________________________________________<BR>
Users mailing list<BR>
<a href="Users@lists.opensips.org">Users@lists.opensips.org</a> <<a href="http://Users@lists.opensips.org">http://Users@lists.opensips.org</a> <<a href="http://lists.opensips.org">http://lists.opensips.org</a>> ><BR>
<BR>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><BR>
<BR>
<BR>
<BR>
<BR>
_______________________________________________<BR>
Users mailing list<BR>
<a href="Users@lists.opensips.org">Users@lists.opensips.org</a> <<a href="mailto:Users@lists.opensips.org">mailto:Users@lists.opensips.org</a>><BR>
<BR>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>