[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] SIP service - technical details

From: Kristian Kielhofner
Subject: Re: [Linphone-developers] SIP service - technical details
Date: Thu, 27 Jan 2011 11:53:22 -0500

I'm curious... At the point you're focusing on media features, why not
implement (or use) a B2BUA that's more well suited to handle the
requirements - SIP body (SDP) parsing, codec negotiation, transcoding, etc?

SIP proxies are perfect for the RFC 3261 reference call scenarios (the
Alice/Bob trapezoid) where the endpoints are left to negotiate media
parameters and the proxy stays out of the body (SDP or anything else)
altogether. For services providing user location functionality they are
perfect because the users can determine what the session is meant to
establish. SDP can setup audio and video but what about file transfer, ISUP
encapsulation, etc? These things are all possible with a by the book SIP
proxy. It really keeps the internet "end to end" model intact.

Imagine IP grew up in an age when routers didn't simply forward packets at
layer 3 and instead crept into the upper layers?

As soon as you touch the body (like a typical B2BUA) you impose restrictions
(rarely enhanced functionality) on the end users.

Kristian Kielhofner
Sent from a mobile device.

----- Original Message -----
From: address@hidden
To: address@hidden <address@hidden>
Sent: Thu Jan 27 11:18:43 2011
Subject: Re: [Linphone-developers] SIP service - technical

Hi Kristian,

I agree with your analysis of the current open source proxies state of
Indeed my feeling is that ser clones require a quite deep understanding
of SIP that plenty of people don't have: they just want to deploy an
"internet telephony service", or just want two SIP capable devices to
communicate. This is one challenge of flexisip to bring the simplicity.
The other challenge is to bring media features using our currently
existing mediastreamer2 engine: the transcoder is the first step in this


Le mercredi 26 janvier 2011 à 13:45 -0500, Kristian Kielhofner a écrit :
> Simon,
>   I agree that choice an competition is important as long as there is
> a logical reason for the split in development effort and resulting
> fragmentation - different goals, direction, etc.
>   I've used SER-family proxies for about seven years.  My largest
> installation is about 100,000 business users across the internet.
> I've been very, very happy with the flexibility and stability of the
> various members of the SER family.  If anything I feel their
> installation, configuration, and operation is too complex.  Unlike any
> other network daemon I've seen, SERs require you to have detail
> knowledge of the protocol in question (SIP).  While this isn't a
> problem for me it can be a significant challenge for new users
> attempting to configure a SIP proxy.  When was the last time Apache
> httpd required someone to read the HTTP 1.1 spec just to serve a few
> basic web pages?  This is what life is like using SER and I only
> imagine it being more difficult for new users to represent their SIP
> routing constructs in C++ (perhaps unless they already know C++).
>   I was hoping this project would provide a powerful SIP proxy with a
> simpler configuration method.  I feel there is room for this in the
> Open Source world.  Absent that you see a lot of people trying to use
> B2BUAs like FreeSWITCH or Asterisk as a "SIP Proxy" because they are
> significantly easier to configure even if they aren't the right tool
> for the job (SER is).  Something like Brekeke (only open source) would
> be nice:
>   It's still a proxy (not as powerful as SER) but it's pretty easy to
> configure via the web interface.
> On Wed, Jan 26, 2011 at 11:44 AM, Simon Morlat
> <address@hidden> wrote:
> > Hi Kristian,
> >
> > Indeed I was pretty sure that somebody will ask this question, though it
> > finally came quicker than I thought :-)
> >
> > The answer is "why not ?"
> >
> > Indeed the SER/Kamailio/OpenSIPS has a very impressive feature list,
> > however quite a few media-procesing related features. But the
> > web/database ecosystem around it is very complete.
> >
> > SER/Kamailio/OpenSIPS is the only SIP open-source proxy product, I think
> > it is always good to have a the choice, like ekiga and linphone for
> > example.
> >
> > Before going further to the debate, I have one question for you: did you
> > try already personaly to install and setup a SER/Kamailio/OpenSIPS by
> > yourself to setup a SIP network on the public internet ? if yes what
> > were your impressions ?
> >
> > Actually, some answers to this question we asked to several people
> > around us lead us to the conclusion that there could be a strong need
> > for another SIP proxy, based on different architures and concepts.
> >
> > SER/Kamailio/OpenSIPS is mostly script oriented (even the SIP routing
> > and message processing logic is a script). For flexisip we thought that
> > the best language for doing SIP processing is to use a real language,
> > like C++, with perhaps java binding in the future. A real programming
> > language provides strong syntax and type checking, thus less errors.
> > One idea behind flexisip is: no scripts, just C++ code and interfaces,
> > and extend flexsip with new features by writing a flexisip C++ module.
> >
> > Best regards,
> >
> > Simon

Linphone-developers mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]