Skip to main content

share data during entire call

7 replies [Last post]
nijie8
Offline
Joined: 2005-06-09

i found that if i use callid instead of activity to routing event to SBB,i really can get the SBB cmp data in later sip transaction such as ack.But in fact that is a bug.Because transaction should be over ,so activity should be removed and SBB entity will be removed also.How can we route a event to a removed SBB entity? The reason is that SIP Ra report activityend event when transaction.complete. But according to RFC3261 200ok for Invite transaction will bring to terminate status. So the activity will never be removed.

Even we can share data during the entire call,we consume too much because SBB entity always exist. Remember that SLEE is a low latancy container. how can we do like this?

In SIP servlet modle ,we can share data in Session. So i really want to know how to share data during entire call in slee.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
fram
Offline
Joined: 2004-05-13

If the an Sbb Entity does exist for the duration of the call that is not a big deal. The Sbb Entity will not be associated to any Sbb object and it will not consume any resource inside the container. Only when an event would be delivered to the Sbb the Sbb Entity will be associated with an Sbb Object.
I have the feeling that some ActivityContext just hang inside the container, probably there is an issue with the SIP RA.
If you want to share data during a call you can follow different strategy:
- use an external resource i.e. in memory db to store your data
- you can create a null activity context and assign the callId name to it by using the naming facility. You can share data by using this Activity Context in your service.
- use the callid as a convergence name for your proxy service and attach the proxy to a null activity, this will allow the sbb entity to live until you don't explicitly end the null activity.
- If you have any other solution please let me know.
I'm going to check what is wrong with the Sip RA, can you please send me the service jar with the code that you used.
Thanks,
Francesco

mranga
Offline
Joined: 2003-06-06

> i found that if i use callid instead of activity to
> routing event to SBB,i really can get the SBB cmp
> data in later sip transaction such as ack.But in fact
> that is a bug.

It is not a bug. This is the way in which convergence names are supposed to work. You specify the convergence name to map an activity to the root sbb of your service. If you return call id, then a new service with a new root sbb node is created for each call. Since the call id does not change during the call, you get the desired effect.

Please abstract your code into a small example and share it with us ( like the earlier example posted by Marco). It would be very valuable and can form the basis for a tutorial / user manual at some point.

Regards,

Ranga

nijie8
Offline
Joined: 2005-06-09

i just follow the example of Marco,that's not new at all.
But it should be transaction stateful and not call stateful from the SIP RA source code.
If we want it be call sateful then we should use callid instead of branch to let the activity lifecyle longer in the whole dialog than in transaction. And SIP RA should post activityend event when sip RA detect dialog complete.

fram
Offline
Joined: 2004-05-13

In order to map the ActivityContext to a call, you should define a new Resource Adaptor Type. The activity end event is sent by the Jain Sip RA when an activity ends.According to the jain slee 1.0 spec appendix an activity is a Sip Transaction.
It would be interesting to define a SIP Stateless Resource Adaptor that maps Activity to CallID.
Francesco

nijie8
Offline
Joined: 2005-06-09

hi,i totally understand.you are right.So that means when service logic is over,SBB should send the activityend event for null activity.

The bug is as follow in SipResourceAdapter.java .
I know that means when sip transaction is completed,activity life cycle should be terminated.
But according to RFC3261 for Invite transaction,when 2xx status received transaction status become directly terminate.And the activity will exist for ever.So i think completed status is not good to judge whether a transaction is over.
There should be another choice to judge it.

The last question is that why we call it SIP Stateless Resource Adaptor .Indeed it is call stateful that maps Activity to CallID.

if (t.getState() == TransactionState.COMPLETED) {
//ra.log.debug("Removing completed transaction");
//ra.log.debug(ra);
ra.sendActivityEndEvent(t);

fram
Offline
Joined: 2004-05-13

Yep, you're right this is indeed a bug, I will change the check from COMPLETED to the TERMINATED state.
Regarding the Resource Adaptor we can discuss the issues in the new sub project, this is a really interesting discussion and I'm looking forward to it. We could start by defining in a draft document a new SIP Resource Adaptor Type and start from there.
Thanks
Francesco

ivelin
Offline
Joined: 2003-07-13

This is a very educational thread. I'm learning. Let's keep the discussions on this forum instead of the sub-project forums. At least for a while until the traffic grows high.

Thanks,

Ivelin