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

[Saúl Ibarra Corretgé]

Hi Josh,

On Wed, Nov 7, 2012 at 10:10 PM, Joshua Colp <jcolp at digium.com> wrote:
> 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
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev

Of course I didn't expect all this day one :-) I just wanted to throw
these ideas out there so that they are not impossible to implement
eventually. I'm glad to hear you keep them in mind :-)


Cheers,

-- 
/Saúl
http://saghul.net | http://sipdoc.net