[Serusers] ser features
peter.3.edwards at bt.com
peter.3.edwards at bt.com
Mon Feb 7 19:40:16 CET 2005
Ah.
Thanks very much for the replies Dragos and Jan - I'll take a closer
look at the developer documentation (I can't believe I missed it!).
Hmm .. I think I have got the wrong end of the stick somewhere, though -
I thought ser was a variant of a SIP Application Server. If it is just
a SIP proxy that probably doesn't fit the purpose we're looking at (not
that it'll stop me installing it anyway .. ;).
Is there anything in the open source world in the SIP Application Server
space, or is ser as close as it gets?
Many thanks for the very fast responses!!
Peter.
> -----Original Message-----
> From: Jan Janak [mailto:jan at iptel.org]
> Sent: 07 February 2005 11:37
> To: Edwards,PR,Peter,XKD44 R
> Cc: serusers at lists.iptel.org
> Subject: Re: [Serusers] ser features
>
> On 07-02 00:09, peter.3.edwards at bt.com wrote:
> > Hi,
> >
> > Being one of those who tend towards open source, I'm trying
> to put forward ser for use within my current project as, from
> my reading, it seems to have most of the features I think
> we're going to need. Problem is, before I've had a chance to
> get it in and play with it, there's a paper sift going on
> which may see it being shelved before I get a chance to even
> propose it. :(
> >
> > I realise it's entirely unforgivable, netiquette-wise, but
> I was hoping if I posted the list of criteria I was looking
> at whether someone could help confirm or deny what I've
> cobbled together wrt ser. Any links to more information on
> the web would be ideal.
> >
> > Any help at all would be gratefully received!
> >
> > Many thanks,
> >
> > Peter.
> >
> > 1) Support for SIP - (preferably 3GPP ISC interface)
> > - Obviously SIP is supported but I can't see any
> explicit mention in the docs wrt to 3GPP ISC .. ? Has ser
> been developed with this in mind?
>
> SIP yes, 3GPP ISC no.
>
> > 2) Provide flexible application run time support in terms
> of standard / well-defined API sets such as SIP servlets
> > - As ser is written in C, it's obviously not exposing
> SIP servlets internally, but I can't seem to find a specific
> API specificiation. I think it sounds like applications are
> created as C modules which plug into ser. Is that right (I'm
> not a C developer, so any clarification appreciated)? Is it
> a ser-properietary interface or something that follows a
> particular standard?
>
> There is nothing comparable to SIP Servlets, SER is not a servlet
> container, but a SIP message mangler with the possibility to keep
> transaction state.
>
> SER modules are written in C and can access SER internals directly.
> Each module can export function that the administrator can then call
> in the configuration file.
>
> There is no particular standard for this, it is very
> similar to the Apache
> module API.
>
> > 3) support carrier grade non functional requirements e.g.
> %age availability, multi-site installation, latency, throughputs etc.
> > - I can't see any specific claims for reliability, or
> any info on how to deal with redundancy etc. Has this been
> looked at before?
>
> Yes, high availability extensions are available under comercial
> license from iptel.org.
>
> > 4) Any interfaces that can be exposed to application logic
> hosted on a remote platform in an untrusted environment -
> e.g. a Java RMI, Web Services etc.
>
> No.
>
> > - Does ser expose anything else, other than SIP? How
> would a third party application running on, let's say for
> argument's sake, a J2EE application running on a separate
> JBoss server? Would a C module need to be written and
> plugged into ser to expose, say web services? Has anything
> like that been done already?
>
> No, that is not possible. SER is not an application server, it is a
> sip proxy.
>
> > 5) Application Developer support / tools
> > - Is there anything like a forum or tools to aid a
> module developer?
>
> The C sources and SER developers guide describing the API.
>
> http://iptel.org/ser/devel.html
>
> >
> > 6) OSS integration
> > - Is there any?
>
> No.
>
> Jan.
>
More information about the sr-users
mailing list