[asterisk-dev] [Code Review] SIP project planning page

Joshua Colp jcolp at digium.com
Wed Nov 7 15:10:46 CST 2012


Saúl Ibarra Corretgé wrote:
> Hi,

Hola,

> Sorry to reply to the list instead reviewboard, I don't have an account
> there and since this is not about code (yet!) I thought email would be ok.
>
> First, let me just say how exciting this is! A new chan_sip!

Party!

> Now, I'd like to propose a couple of things for the "Media sessions"
> section:
>
> 1. Handling of unknown streams. Currently Asterisk implements audio and
> video streams and if the offer contains unknown streams Asterisk just
> ignores them and the other party doesn't "see" them. This currently
> happens with MSRP, for example. A nice feature would be to have Asterisk
> copy those unknown streams verbatim to the other call leg, and let the
> endpoints negotiate.

Having this traverse Asterisk internally at all really isn't feasible 
right now without major media rework, so it would have to be a partial 
transparent SDP that you mention below.

> 2. Transparent SDP. In this mode Asterisk would not touch de SDP, it
> would just mirror it to the other call leg and just stay in the
> signaling path. Asterisk could interface with a RTP relay like
> MediaProxy just to fix the NAT, and this way the load in the server
> would be much lower because Asterisk wouldn't need to do RTP relaying
> itself. Since Asterisk would be in the middle of the signaling, it can
> always send a re-INVITE to each call leg and redirect the audio to
> itself if needed.

With the modular design that the new chan_sip should be this should be 
easily achievable. Do I think it needs to be done right now? No, but the 
design shouldn't discount it and I don't expect it to.

>
> In the "Subscriptions" section:
>
> 1. Implementing support for RFC4575 and 4579 would be great. SIP
> endpoints implementing this specification would be able to get
> information and control a conference (running in ConfBridge) using
> standard SIP mechanisms.

Much like the above I think given the modular nature this can be 
completely separate and implemented in the future easily.

Cheers,

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org



More information about the asterisk-dev mailing list