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@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

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com