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

[Saúl Ibarra Corretgé]

Mark Michelson wrote:
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2183/
>
>
> Note: The SIP stack research is a sub-page of the project page but is *not* in a state where it is ready for review. A review for that will go up as a separate review.
>
>
> - Mark
>
>
> On November 6th, 2012, 5:23 p.m., Mark Michelson wrote:
>
> Review request for Asterisk Developers.
> By Mark Michelson.
>
> /Updated Nov. 6, 2012, 5:23 p.m./
>
>
>   Description
>
> Have a look at the SIP project page that has been created here: https://wiki.asterisk.org/wiki/display/AST/New+SIP+channel+driver as well as its subpages.
>
> At the moment, the content is pretty bare. This is because the project is not very far underway and so there isn't much to be able to put there right now.
>
> A few notes:
>
> The list of features on the project page is a list that more or less came off the top of my head and is supposed to represent a high level set of features. Feel free to let me know about things that should be added, but keep in mind that features listed there should be SIP-specific. We are not planning to do many changes to the media handling in Asterisk as of right now, so features like SRTP, STUN/TURN/ICE, and DTLS-SRTP are already provided by Asterisk's media handling and does not need to be addressed as a SIP feature (aside from potentially some SDP parsing).
>
> The use cases are written from a *very* high level. For instance, the two-party call use case has dozens, if not hundreds, of variants. However, since these are not necessarily observable by Alice and Bob, they have not been included as separate use cases. So when evaluating use cases, information such as codecs in use, encryption of media, authentication, direct media, and NAT are irrelevant. Keep this in mind if you have additional use cases for me to document.
>
> Please let me know what all can be added, removed, or clarified.
>
>
>   Diffs
>
> View Diff <https://reviewboard.asterisk.org/r/2183/diff/>
>
> --
> _____________________________________________________________________
> -- 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

Hi,

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!

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.

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.


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.


In the Configuration section it says that the new chan_sip configuration 
MUST be backwards compatible with the current one. I hope we can lift 
that constraint :-)

If I understood correctly (I listened to the AstriDevCon stream) the 
idea was not to replace chan_sip in Asterisk 12 but have a new chan_sipX 
or something and deprecate the current chan_sip, which would eventually 
be removed. Is this still the case?

If it is, then why maintain backwards compatibility? The current 
"register =>" line is horrible to use, for example. IMHO using the old 
config may affect how new options are designed or added. I'd rather 
start with a blank slate and then, if a compatibility layer can be built 
great, but I don't like the idea of having it as a must.


Regards,

-- 
Saúl Ibarra Corretgé
http://saghul.net/blog | http://about.me/saghul