[OpenSIPS-Users] [NEW] SDP codec manipulation feature

[Bogdan-Andrei Iancu]

Hi Iñaki,

Iñaki Baz Castillo wrote:
> 2009/7/23 andrei dragus <andreidragus at yahoo.com>:
>   
>> Hello,
>>
>> Methods have been added for SDP codec manipulation in the textops module.
>> Please update your module if you wish to use them.
>>
>> There are 4 methods:
>>  codec_exists(name[,clock]); //test if a codec exists
>>  codec_delete(name[,clock]); //delete a codec
>>  codec_move_up(name[,clock]); //move a codec to the front of the list
>>  codec_move_down(name[,clock]);//move a codec to the back of the list
>>
>> Each of them can take a codec name and an optional clock parameter. If the clock is unspecified all of the codecs with that name will match.
>>
>> All of the methods will act on all streams from all sessions inside the SDP.
>>     
>
> Hi Andrei. Please don't take me wrong, but is this a task for a proxy?
>   
The codec related ops are very "light" and suitable for a proxy, in the 
way that the proxy influence the codec negotiations, but without 
bringing the SDP negotiation into an inconsistent state. This is the 
reason why there is no "add_codec" operation (even if it is perfectly 
possible), but only "delete" and "swap priorities" were implemented - 
because only these ops do make sense from proxy pov.

Let's consider some typical cases:

1) you can a PSTN termination with a wholesale provider and you know 
that he provides a poor GSM codec, so you can simple remove GSM as 
advertise codec (from your customer's calls) and to offer a better 
quality (via G729, G711, etc).

2) you, as a SIP provider, handle media on your platform (media relaying 
or media services) and you want to force your customers to use G719 over 
G711 to avoid bandwidth exhaustion. So you  can change and set a higher 
priority for G719 over G711 in the SDP offer.

IMHO, both cases are perfectly applicable for a proxy.

> I wonder what would occur in the following cases:
>
> - The UAC/UAS use encrypted SDP (S/MIME...).
> - The UAC/UAS use multipart content (some devices do it for an INVITE).
>   
I can raise the same exceptions for the media relaying, or for whatever 
other functionality that require access to body.
I do not say they are not valid, but in SIP there are many other things 
that needs to be polished ;).

> From some time I'm realizing that OpenSIPS is trying to behave as a
> B2BUA, or it wants to manage dialogs (and it doesn't do it properly)
> and now it handles the SDP (just in case the SDP comes not encrypted
> in a single part body). Is it really the target of a proxy?
>   
I have to disagree with you here. OpenSIPS does not want to become a 
B2BUA - this is totally false. It started as a SIP proxy and it will 
never stop offering this  functionality with 0 penalties. But honestly 
speaking a simple proxy is not able to offer all the functionalities 
required by the SIP providers (more complex scenarios, more control over 
the traffic, etc).
Aside the simple proxy engine,  OpenSIPS added support for dialogs (even 
if it is still a proxy and not B2BUA) to give you more power in building 
services. In the same manner, the SDP support was added and also in the 
same idea the B2BUA support will be added.

So, OpenSIPS will be a SIP server able to act (in the same time) as the 
simple proxy (stateless or statefull), a dialog aware proxy, a B2BUA, 
etc . It will offer all of the them and it will be your choice to use it 
as you want.


Regards,
Bogdan