[OpenSIPS-Users] codec manipulation feature

[Brett Nemeroff]

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, so I'm not sure how you'd do
things like "removing g729 codec including the annex=b annotation". But
imaging that anything is possible:
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> 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> 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>
> 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> 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://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> _______________________________________________
> Users mailing list
> 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/20090615/6a5d80b5/attachment.htm