[Serusers] Re: [Serdev] SIP Stack development

[Greger V. Teigre]

Hi Alan,
See inline.

Alan Basinger wrote:
> Thanks Greger,
> I know ho hard it is to keep up with the documentation of a rapidly 
> changing project and also know what a challenge it is to manage the 
> code. I hope we can use the base of SER to create some new and 
> exciting applications uing SIP and add some usefull features and 
> functionality to the base code for everyone to benifit from.
>  
> I appreciate the quick reply and answering a newbs questions as I may 
> have more as we move along.
:-) Sure, I realize that lack of documentation can be replaced 
(partially and only temporarily) by responsive support on mailing lists. 
It is also a way to establish the actual scope of documentation work.
>
> Hi Alan,
> I'm heading the new documentation effort. An updated list of the 
> supported rfcs and standards is on my list of needed docs... I'm on 
> mobile right now, so I
> cannot search for you, but on iptel.org/listsearch you can search for 
> Janak and supported rfcs. I think he posted an update recently.
>
> As for the specific draft, I'm not familiar with it. In general 
> though, media is not handled by ser, only messaging.
> The draft is for allowing messaging as well as media to be sent to a 
> loopback to mesure actual network conditions to and from the device 
> without actually setting up a call. Very usefull and we have many 
> vendors implimeting it in there CPE. (Linksys, Polycom, SNOM, 
> Panasonic, etc.)  I woul like to see about developing this and many 
> other features / functionaility into SER. I worked with one of the 
> authors of this draft and it realy makes sense. Here is a link to it.
>  
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-05.txt
>
Aha, I recognize the name now :-) Without knowing the details of the 
draft, I have the following comments:
* In general you want your servers out of the rtp path (i.e. direct 
media between UAs), in fact, ser is never in the rtp path. However ser 
is very good at doing message processing, forwarding and all sorts of 
"tricks"
* RTP may be handled by three separate software components: rtpproxy, 
mediaproxy, and sems (mediaproxy is not an iptel.org project, the others 
are). SER modules (nathelper and mediaproxy) are used to communicate 
with these external components (locally or over udp) and for mangling 
the SDP payload
* Your measurements will probably need to follow the media path of a 
normal session. If not, you will not be able to measure for example real 
latency on your ex. rtpproxy server(s). SEMS is a very good 
general-purpose media server, while rtpproxy/mediaproxy are more 
dedicated for proxying of rtp for NAT-purposes etc
* Hence, you probably need to implement sdp loopback intp the rtp 
handling component. SEMS may be the easiest way due to its very modular 
and powerful plugin interface (it's also a B2BUA). However, as sems 
don't stay in the media path except in conferences etc, you don't really 
measure "real world..."
* I suspect you can create a ser module (or extend nathelper) that 
implements the basic loopback stuff using rtpproxy without touching 
rtpproxy (too much)
> As for development, ser has a very efficient core exposing a module 
> interfaces. Modules can implement functions, parameters, avpairs (i.e. 
> set variables), and
> selects (give access to certain info related to a message).
> I found a copy of the 2002 developers guide and have been starting 
> there but an concerned that it may be too outdated any idea when a new 
> draft will be available for review?
The basic concepts are still relevant. It has not been updated to cover 
to the attribute value pairs and the selects.  We are currently focused 
on the user documentation for the next release, but we are debating what 
the next steps are. A how-to for module development is already on the 
list, possible with a retouch of the old developers guide.
You can start out with one of the simpler modules (like textops or 
dispatcher) and modify to your needs. Understand the plugin interface, 
lumps and shared memory, and you are pretty much there ;-)
>  
> Contributions are always welcome. We have just introduced a new 
> classification of modules, thus allowing experimental modules into the 
> cvs without too much
> fuss.
> Good to hear as me and my partner in crime and I hope to be able to 
> add some value with our ideas.
:-)
g-)
>
> BTW, start with ser ottendorf. It is getting close to release and has 
> many new important improvements.
>
> Feel free to ask questions on this list.
> g-)
>  
> Thanks again
>  
> Alan Basinger
>
> ------- Original message -------
> From: Alan Basinger <droidgeneral at yahoo.com>
> Sent: 27.12.'06,  12:43
>
> > Hello all,
> > I definitely am a newby with SER but not with SIP and I am trying to 
> find out where the supported SIP methods are?
> > Specifically how would I go about finding out if SER supports the 
> Media Loopback draft or other ratified or non ratified components.
> > Also if not supported where would I being the coder that I am not be 
> able to modify the code myself to add these functions and then 
> distribute them back to
> the community?
> >  
> > Thanks in advance
> >  
> > Alan
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com <http://mail.yahoo.com/>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20061229/113b6a18/attachment.htm>