|
Replies:
18
-
Last Post:
Jan 25, 2006 2:49 PM
by: ivelin
|
Threads:
[
Previous
|
Next
]
|
|
|
|
|
|
SIP RA Type
Posted:
Aug 14, 2005 10:48 PM
|
|
|
Hi all, my name is Ben Evans and I work at Open Cloud writing SIP RAs and services. I see has Ranga mentioned me in an earlier thread - we have talked in the past about cooperating on a common JAIN SIP RA Type definition, however not much has been done yet, so I would like to kick off a discussion here.
My goal would be for us to converge on a "standard" RA Type so that SIP SBBs can be easily portable between Mobicents and Open Cloud's Rhino SLEE, and others. I think they are probably pretty similar already, both based on the SLEE spec recommendation, so this should not be too difficult.
Another topic to consider is what additional features would people like to see in a standard SIP RA Type. JAIN SIP by itself is quite low-level, perhaps there are some higher level APIs we could come up with that would make life easier for SBB developers. One that springs to mind is some form of built-in proxying, as in SIP Servlets.
If you want to check out Open Cloud's SIP RA Type and some examples, these are distributed with the Rhino SDK, which is publically available at https://stampede.opencloud.com. The examples include demo SIP proxy and registrar SBBs which may be of interest, and we don't mind if you borrow from them. These have been used successfully in several trials and should be reasonably correct.
Cheers
Ben
|
|
|
|
|
|
|
Re: SIP RA Type
Posted:
Aug 15, 2005 6:48 AM
in response to: ben_evans
|
|
|
Hi Ben,
Very nice to see your name on the forums. I have heard good things about your work at Open Cloud and Vodafone.
SIP RA has been in fact a hot topic recently and we have expected Open Cloud to respond to Ranga's call for collaboration.
The bugzilla issue to track progress on SIP RA Type is #35:
https://mobicents.dev.java.net/issues/show_bug.cgi?id=35
I granted developer rights to your account so that you have CVS commit rights.
Standard set of SBB services is also an interesting topic that we would like to approach. As you suggest SIP proxy
and registrar are among the top two candidates. Other interesting ideas include SIMPLE Presence and SIMPLE Instant Messaging.
When you say that we can borrow from the Rhino examples, do you mean that their license is compatible with LGPL and we can reuse and modify code for the purposes of Mobicents?
Cheers,
Ivelin
|
|
|
|
|
|
|
|
|
Re: SIP RA Type
Posted:
Aug 17, 2005 4:03 PM
in response to: ivelin
|
|
|
Hi Ivelin thanks for setting me up. Re you licensing question - the example SIP services source code, distributed with the Rhino SDK, is under a BSD license, see licenses/SERVICES.LICENSE in the distribution. So you can pretty much do what you want with them. 
The examples you already have in thirdparty/oc-sip-examples are a bit out of date, we have done a complete rewrite since then to make them perform better, more robust and better architected, so I would encourage you to look at the new examples in the latest Rhino SDK.
|
|
|
|
|
|
|
|
|
Re: SIP RA Type
Posted:
Aug 17, 2005 4:49 PM
in response to: ben_evans
|
|
|
Excelent! I knew the license was open source but wasn't clear it was BSD.
A new suggestion then. Since we all want to work on improving these examples, would you consider contributing them as a sub-project, e.g. slee-examples? That would solve the problem with merging code periodically.
Ivelin
|
|
|
|
|
|
|
|
|
Re: SIP RA Type
Posted:
Aug 17, 2005 5:44 PM
in response to: ivelin
|
|
|
Yes we should be able to do that. Some of the examples depend on OC extensions to JAIN SIP (eg. Dialog activities), but our proxy and registrar SBBs use a similar SIP RA Type to Mobicents', so I think it would be simplest just to contribute those SBBs at this stage, they will have the best chance of working! Also our build and deploy scripts are written for Rhino, I'm not sure how easy it will be to convert them, maybe I can have an initial try and others can tidy up 
|
|
|
|
|
|
|
|
|
Re: SIP RA Type
Posted:
Jan 12, 2006 9:50 PM
in response to: ben_evans
|
|
|
Ben,
I am not sure how I missed your message on porting the examples back in August. If you are still interested I can help with the scripts. There are now a number of mobicents examples that should be useful guidance:
https://mobicents-examples.dev.java.net/
Ivelin
|
|
|
|
|
|
|
|
|
Re: SIP RA Type
Posted:
Jan 17, 2006 1:03 AM
in response to: ivelin
|
|
|
Back to this thread after a long time.
I agree with Ben that pushing functionality like presence in the RA can be a problem if you lately need to extend this feature.
The proxy looks to me as a good candidate to be pushed into the SIP RA. My only doubt is that the proxy strongly needs a Location Service to perform the call routing.
If the location service is inside an Sbb the resource adaptor strongly depends on this particular service. I think that it would be better to include inside the RA the SIP Registrar too and expose a registration interface to the service that will allow Sbbs to retrieve and add registration infos.
Regarding the B2BUA, there is no need to push such functionality in the SIP RA, infact once we'll have the concept of "two dialog leg actvity" it will be really easy to implement B2BUA services.
FRAM
Message was edited by: fram
|
|
|
|
|
|
|
|
|
Re: SIP RA Type
Posted:
Jan 17, 2006 1:23 PM
in response to: fram
|
|
|
Hello again! I disagree about the location service idea. I can see why you would want to do that, but the location service is not something that every proxy needs to know about. For example in an IMS network, you have the S-CSCF performing this function, and the AS (where a SLEE would most likely be deployed initially) can behave like a proxy , but only has to forward requests to the next hop in the Route header, rather than doing a location service lookup itself.
Also there is no standard for a location service, so implementing this in an SBB means you can do it any way you like, and make use of SLEE facilities. For example, Open Cloud's current SIP examples (which I hope to contribute soon) can use CMP or JDBC to store location service info, and this is hidden behind an SBB local interface which is called by proxy and registrar SBBs. If the location service was implemented inside the RA it would make it harder to switch to a different implementation.
Ben
|
|
|
|
|
|
|
|
|
|
|
|
Re: SIP RA Type
Posted:
Jan 19, 2006 7:27 AM
in response to: ben_evans
|
|
|
Regarding the activity one simple solution could be to use a PeerRelation activity, this activity is not started and ended by the resource adaptor, the JSLEE service should be responsible to create the activity and destroy the activity.
The activity is the set of all the sip message exchanged between two peers, even if the SIP Dialog is not yet established between the two sip uri. Everytime the stack receive an event with "From" and "To" header matching the two peers, it will fire the event on the PeerRelation activity.
What do you think ? Too simple ?
francesco
|
|
|
|
|
|
|
|
|
Re: SIP RA Type
Posted:
Jan 19, 2006 3:48 PM
in response to: fram
|
|
|
How would this idea extend to more than 2 parties participating in a call (e.g. conference)?
Ivelin
|
|
|
|
|
|
|
|
|
Re: SIP RA Type
Posted:
Jan 20, 2006 12:47 AM
in response to: ivelin
|
|
|
The conference scenario can be addressed by creating a number of activities corresponding to the participants in the call. For instance if you have user a@here.com, b@there.com, c@nowhere.com the service will create three activities and attach to them:
<a@here.com>:<conference@bridge.com>
<b@there.com>:<conference@bridge.com>
<c@nowhere.com>:<conference@bridge.com>
This scheme allows the service to have enough flexibility to add participant to the conference dynamically.
An alternative could be to have a peer relation one-to-many. The Sbb attached to such a peer relation will receive all the messages to or from a peer.
Message was edited by: fram
|
|
|
|
|
|
|
|
|
Re: SIP RA Type
Posted:
Jan 20, 2006 9:54 AM
in response to: fram
|
|
|
The first alternative sounds reasonable.
Can you detail the second alternative? How would a service identify or establish a one-to-many relationship?
|
|
|
|
|
|
|
|
|
Re: SIP RA Type
Posted:
Jan 24, 2006 12:39 AM
in response to: ivelin
|
|
|
I was thinking of using a mechanism like wildcard char or separate methods to support an activity that includes all the sip messages to or from a sip uri.
SipProvider.createPeerRelation(sipUri1, sipUri2)
SipProvider.createPeerFromRelation(sipUri1)
This method will create an activity that will receive all the messages with the sip from header matching sipUri1
SipProvider.createPeerToRelation(sipUri1)
This method will create an activity that will receive all the messages with the sip to header matching sipUri1
The Sip RA will have to implement the logic to filter the sip messages against the activity created by the Sbb.
Any thoughts ?
Francesco
|
|
|
|
|
|
|
|
|
Re: SIP RA Type
Posted:
Jan 25, 2006 2:49 PM
in response to: fram
|
|
|
Your suggestions are great. I like the idea of a realtionship based activity context.
Let me focus on the conference call service example.
Instead of adding more complexity to the RA, I would suggest a conference call SBB.
It will be a root SBB for a conference call service. The initial event selector will be designed to select a convergence name based on a Conference Call Number listed in a Conference Numbers Address Profile associated with the SBB.
Any SIP message that is To or From a Conference Call address will be delivered to an SBB Entity associated with a specific conference call.
Furthermore the Conf Call SBB could use a Named Activity Contexts for Call Control. Let's name it ConferenceCallControlAC.
The SBB can define a set of inbound Events to be received on the AC such as Add_User_To_Call, Remove_User_To_Call, Get_Users_In_Call, etc.
Also a set of outbound Events to be send on the AC such as Conference_Started, User_Dropped, User_Added and so on.
This sounds like a reasonable way to build scalable conference call services in SLEE.
Please comment.
Ivelin
|
|
|
|
|
|
|
|
|
Re: SIP RA Type
Posted:
Aug 15, 2005 7:00 AM
in response to: ben_evans
|
|
|
Ben,
Welcome. I look forward to collaborating with you. A couple of things about the SIP RA. I think it would be good to :
1. Provide inbuilt proxy capability much like sip servlets so that the SLEE does not need to be frequently interrupted.
2. Allow the service to push down filters to reduce the number of service upcalls. For example, a billing service is interested in the INVITE and BYE but not all the intermediate transactions. Not much point in waking up the SLEE only to simply proxy the request.
3. Allow for call stateful operation ( much like JCC but SIP specicfic ) so that the SIP RA is call stateful and not necessarily transaction stateful. Such a SIP RA can essentially be a stateless proxy that simply interrupts the slee on messages of interest.
4. We need to clearly define what state an SBB is expected to keep on failover.
Just thought I'd put out some ideas to get the ball rolling. Yes we do use your Proxy SBB ( see thirdparty/oc-sip-examples ) with some modifications in the project. Good thing about this project is we can open source prototype our ideas as we discuss them ( I like English discussions but I prefer Java. )
Ranga.
Message was edited by: mranga
|
|
|
|
|
|
|
|
|
Re: SIP RA Type
Posted:
Aug 15, 2005 7:39 AM
in response to: mranga
|
|
|
Hi Ben,
welcome to the project, this is an interesting topic and something crucial for the JAIN SLEE standard to be succesful.
We already had some discussion with Ranga during a visit here at NIST of some people from TILAb (Massimo Valla and Walter Goix). The common feeling is that the JAIN SIP RA as it is "defined" in the JAIN SLEE appendix does not satisfy the requirement of a service platform. The JAIN SIP interfaces are too fine grained and they lack some higher level functionality that a SIP service is likely to use.
As you said the interface should look more like the Sip Servlet interfaces and should provide the Sbb developer with some common features:
1) a Proxy interface
2) Register interface
3) B2BUA interface
4) 3rd party call control
4) a presence and IM interface
5) a jain sip like interface
This feature can be grouped in a single RA Type or splitted in different RA Type.
The crucial part for the design of the new resource adaptor type is the definition of the Activity.
A solution could be to identify the Activity with the CallId that is associated with every SIP Message.
By following this design the proxy service and the register will no longer be implemented by the Service logic but such feature will be implemented by the resource. Some good example of services for the new resource adaptor would be a call blocking, call forwarding and a push to talk application.
Francesco
|
|
|
|
|
|
|
|
|
Re: SIP RA Type
Posted:
Aug 17, 2005 7:06 PM
in response to: fram
|
|
|
When designing an RA type I would want to be wary of putting "too much" functionality into the RA, since its not as easy to extend an RA if you want to customise its behaviour.
Clearly proxying is something that is done most of the time, and follows strict rules, so that would be good to have in the RA. Higher level functions such as presence or registrar could be wrapped up in child SBBs with a local interface that can be invoked by other SBBs.
Fransesco raises a good point about the definition of the Activity. Unfortunately with the SIP protocol as complicated as it is, we will need to have several Acivities. The current OC SIP RA has the following:
- ServerTransaction
- ClientTransaction
- Dialog
(these correspond to the JAIN SIP interfaces)
I think there will always be a need for the transaction activities, these are fundamental to SIP and a lot of simple apps don't need much more than this.
We added a Dialog activity to help us write B2BUA apps, or apps that are call-stateful. Unfortunately the JAIN SIP Dialog is not really the ideal thing to use here, since to stay on a call and handle all in-dialog requests, the app needs to attach to two Dialogs - one represents the A<->SLEE leg, the other represents the SLEE<->B leg (where "A" and "B" are the UAs calling via the SLEE).
What would be nice is some variant of a Dialog activity that represents the A<->B relationship, so SBBs attached to this single activity automatically see all in-dialog requests from A or B, making the application logic much simpler. This is what SIP Servlet's SipSession does. I would like to see something similar in a SIP RA. This activity would be kind of like what Fransesco suggested with the Call-Id.
|
|
|
|
|
|
|
|
|
Re: SIP RA Type
Posted:
Jan 12, 2006 9:04 PM
in response to: ben_evans
|
|
|
So this thread is revived again, let's try to drive it to completion this time.
Here is the most recent discussion related to the SIP Dialog support problem:
http://forums.java.net/jive/thread.jspa?threadID=2503&tstart=0
Fran and Ben, do you have suggestions how to implement the higher level Dialog concept in the SIP RA to achieve similar functionality as in SIP Servlet Session.
Keep in mind that the version of JSIP used in Mobicents HEAD is (almost) 1.2 compliant. Hopefully JSIP 1.2 is flexible enough to allow for a performant SIP RA Dialog.
Ivelin
|
|
|
|
|
java.net RSS
