SBB Activity Context Interface interface and Asterisk RA

[stefan.lilov]

According to JAIN SLEE 1.1 spec an SBB can define Activity Context
Interface interface extending generic ActivityContextInterface to
declare shareable attributes. These attributes can be shared between
the SBB entities of this SBB. It means that an SBB Developer can share
between these entities different type of information.

The effect of "sharing" attributes is not achieved when an SBB defines
an SBB Activity Context Interface interface and this SBB component
handles events fired from Asterisk RA. I looked into the code of the
RA and it seems that a new instance of Activity Context Interface is
instantiated every time new event is generated from the Asterisk the
Asterisk RA is connected to. In my opinion it shall be implemented the
other way around - there shall be only one Activity Context Interface
interface instanciated that is valid for the whole connection with the
Asterisk and thus all Asterisk generated events to be fired on that
Activity Context.

I have not reported an issue because I'd like first to verify with the
community my understanding.

[Michele]

You are right It's because there's a new Activity for each asterisk-
event.
But asterisk activity is still very poor.I think it's possible to
model four kind of activities
(SinglePartyCall,TwoPartiesCall,ConferenceCall,AgiScript) in a new
more powerful asterisk ra.At this point you will be able to share
attributes :)

Michele

[Eduardo Martins]

Michele, that's right, an activity per event is not really a good jain
slee RA, anyway 4 types of activities could be overkill and of
difficult implementation, can you provide a draft spec in a google
page, and perhaps also users may want to contribute with their
thoughts?

[stefan.lilov]

In fact i was thinking it would be better if there is only one
activity per connection to the Asterisk and all the events and logic
as suggested by Michele for example can be implemented in the SBBs (or
Services) relying on that connection with the Asterisk. Thus the usage
of Asterisk RA stays flexible and at the same time it provides more
JSLEE type of behaviour. It is also easier to be implemented I have
done some steps on that even though i don't have good progress on that
too.

> >> community my understanding.- Hide quoted text -
>
> - Show quoted text -

[Eduardo Martins]

The activity should be as much high level as possible, but without
compromising well defined instances (sbb entities) of a SLEE service,
as an example, if two parallel instances processing 2 sip calls need
to share a single connection to asterisk and listen for events than I
would say that would be a bad design, mandating instances to possibly
receive events for other instances...

Regards,
Eduardo

[Eduardo Martins]

I guess this email was supposed to be on the public mail list :-)

-- Eduardo

---------- Forwarded message ----------
From: Uijltje <tom.ui...@gmail.com>
Date: Mon, Dec 15, 2008 at 8:10 PM
Subject: Re: SBB Activity Context Interface interface and Asterisk RA
To: Eduardo Martins <emma...@gmail.com>


To anyone in this thread: any developments since the last post?

Currently, this RA only deals with the management interface which
generates [-a lot of-] events and provides the possibility to initiate
management actions.
These actions are currently synchronous and results are not tied to
the same activity.

For starters, I'd like to make the sendAction() asynchronous and tied
to some sort of action-activity so that responses can end up in the
same Sbb.

Any thoughts, objections?

TIA,
Tom.

On Sep 10, 6:35 pm, "Eduardo Martins" <emmart...@gmail.com> wrote:
> The activity should be as much high level as possible, but without
> compromising well defined instances (sbb entities) of a SLEE service,
> as an example, if two parallel instances processing 2 sip calls need

> to share a single connection toasteriskand listen for events than I

> would say that would be a bad design, mandating instances to possibly
> receive events for other instances...
>
> Regards,
> Eduardo
>

> On Wed, Sep 10, 2008 at 5:44 PM, stefan.lilov <stefan.li...@gmail.com> wrote:
>
> > In fact i was thinking it would be better if there is only one

> > activity per connection to theAsteriskand all the events and logic

> > as suggested by Michele for example can be implemented in the SBBs (or
> > Services) relying on that connection with theAsterisk. Thus the usage

> > ofAsteriskRA stays flexible and at the same time it provides more

> > JSLEE type of behaviour. It is also easier to be implemented I have
> > done some steps on that even though i don't have good progress on that
> > too.
>
> > On Sep 9, 2:28 pm, "Eduardo Martins" <emmart...@gmail.com> wrote:
> >> Michele, that's right, an activity per event is not really a good jain
> >> slee RA, anyway 4 types of activities could be overkill and of
> >> difficult implementation, can you provide a draft spec in a google
> >> page, and perhaps also users may want to contribute with their
> >> thoughts?
>
> >> On Thu, Sep 4, 2008 at 7:51 AM, Michele <michele.lapo...@gmail.com> wrote:
>
> >> > You are right It's because there's a new Activity for eachasterisk-
> >> > event.

> >> > Butasteriskactivity is still very poor.I think it's possible to

> >> > model four kind of activities
> >> > (SinglePartyCall,TwoPartiesCall,ConferenceCall,AgiScript) in a new

> >> > more powerfulasteriskra.At this point you will be able to share

> >> > attributes :)
>
> >> > Michele
>
> >> > On 4 Set, 07:13, "stefan.lilov" <stefan.li...@gmail.com> wrote:
> >> >> According to JAIN SLEE 1.1 spec an SBB can define Activity Context
> >> >> Interface interface extending generic ActivityContextInterface to
> >> >> declare shareable attributes. These attributes can be shared between
> >> >> the SBB entities of this SBB. It means that an SBB Developer can share
> >> >> between these entities different type of information.
>
> >> >> The effect of "sharing" attributes is not achieved when an SBB defines
> >> >> an SBB Activity Context Interface interface and this SBB component

> >> >> handles events fired fromAsteriskRA. I looked into the code of the

> >> >> RA and it seems that a new instance of Activity Context Interface is
> >> >> instantiated every time  new event is generated from theAsteriskthe

> >> >>AsteriskRA is connected to. In my opinion it shall be implemented the

> >> >> other way around - there shall be only one Activity Context Interface
> >> >> interface instanciated that is valid for the whole connection with the

> >> >>Asteriskand thus allAsteriskgenerated events to be fired on that

[Michele]

Hi Tom
see my inlines comment.

On 15 Dic, 22:39, "Eduardo Martins" <emmart...@gmail.com> wrote:
> I guess this email was supposed to be on the public mail list :-)
>
> -- Eduardo
>
> ---------- Forwarded message ----------
> From: Uijltje <tom.uijld...@gmail.com>
> Date: Mon, Dec 15, 2008 at 8:10 PM
> Subject: Re: SBB Activity Context Interface interface and Asterisk RA
> To: Eduardo Martins <emmart...@gmail.com>
>
> To anyone in this thread: any developments since the last post?
>
> Currently, this RA only deals with the management interface which
> generates [-a lot of-] events and provides the possibility to initiate
> management actions.
> These actions are currently synchronous and results are not tied to
> the same activity.

Correct.It's because the resource adaptor it's modeled to generate an
activity per message without a mechanism to re-combine a event with a
particular activity (for example actionId can be used for re-combine a
outgoing ManagerAction with an incoming ManagerResponse).

>
> For starters, I'd like to make the sendAction() asynchronous and tied
> to some sort of action-activity so that responses can end up in the
> same Sbb.

+1

If actually there's an activity per message with this model there will
be one activity each ManagerAction/ManagerResponse pair?

>
> Any thoughts, objections?

What about the other events coming from Asterisk connection?

[Tom Uijldert]

Hi,

Well, I'm a firm believer in small steps, hence the proposal to tackle the
Action/Response problem first (indeed using the actionId, 1 activity per
message).

As for the events, I'm not quite sure what should be done yet.
The current implementation sort of makes sense: events are fairly standalone
things.
You can limit what's thrown at you by defining a root-sbb for certain
event-types.
The event-avalanche can further be limited by configuration (type of
connection you make to asterisk). So I don't have a problem with that
(yet:).

Issues that I have a more along the lines of:
- what if we connect multiple asterisk Pbx's?
- what about AGI/fastAGI interfacing? (I believe this requires a new RA
type...)

Regards,
Tom Uijldert

[Michele La Porta]

2008/12/16 Tom Uijldert <tom.ui...@gmail.com>

Hi,

Well, I'm a firm believer in small steps, hence the proposal to tackle the
Action/Response problem first (indeed using the actionId, 1 activity per
message).

+1

As for the events, I'm not quite sure what should be done yet.
The current implementation sort of makes sense: events are fairly standalone
things.

 

Even standalone, a logical sequence of events can model a Call (single party,two parties,conference). In the new model activity is one way from slee service layer to asterisk.For inverse case we can change acutal model to an activity per connection ( there's will be an activity for the time asterisk-ra is active).

You can limit what's thrown at you by defining a root-sbb for certain
event-types.
The event-avalanche can further be limited by configuration (type of
connection you make to asterisk). So I don't have a problem with that
(yet:).

Issues that I have a more along the lines of:
- what if we connect multiple asterisk Pbx's?

 

for connecting multiple asterisk we will need to modify actual resource adaptor to use a pool of asterisk connections and associated controllers for managing incoming/ougoing events from different pbxs.

- what about AGI/fastAGI interfacing? (I believe this requires a new RA
type...)

Yes requires new.
Ra will needs to bind a DefaultAgiServer,sbb interface should be able to send AgiCommand
and ra should be able to receive AgiReply reply.Don't know much about AGI which activity handle identifier will be used in this case?Am I right on my agi-ra idea?

--
Michele

[Tom Uijldert]

 

---

From: mobicent...@googlegroups.com [mailto:mobicent...@googlegroups.com] On Behalf Of Michele La Porta
Sent: dinsdag 16 december 2008 14:24
To: mobicent...@googlegroups.com

Subject: [mobicents-public] Re: Fwd: SBB Activity Context Interface interface and Asterisk RA

2008/12/16 Tom Uijldert <tom.ui...@gmail.com>

Hi,

Well, I'm a firm believer in small steps, hence the proposal to tackle the
Action/Response problem first (indeed using the actionId, 1 activity per
message).

+1

 

I'll get on it so.

 

As for the events, I'm not quite sure what should be done yet.
The current implementation sort of makes sense: events are fairly standalone
things.

 

Even standalone, a logical sequence of events can model a Call (single party,two parties,conference). In the new model activity is one way from slee service layer to asterisk.For inverse case we can change acutal model to an activity per connection ( there's will be an activity for the time asterisk-ra is active).

Modelling a call on events wil be very hard:

- what;'s the common denominator (channel?)

- what wll actually start/end the activity?

 

You can limit what's thrown at you by defining a root-sbb for certain
event-types.
The event-avalanche can further be limited by configuration (type of
connection you make to asterisk). So I don't have a problem with that
(yet:).

Issues that I have a more along the lines of:
- what if we connect multiple asterisk Pbx's?

 

for connecting multiple asterisk we will need to modify actual resource adaptor to use a pool of asterisk connections and associated controllers for managing incoming/ougoing events from different pbxs.

 

Ok..., but that's a bit too broadly specified for my taste.

Can you come up with more specifics, like how we tie this to an activity model?

Maybe we should look more closely at "org.asteriskjava.live" as that already supplies a higher-level API for AMI.

 
- what about AGI/fastAGI interfacing? (I believe this requires a new RA
type...)

Yes requires new.
Ra will needs to bind a DefaultAgiServer,sbb interface should be able to send AgiCommand
and ra should be able to receive AgiReply reply.Don't know much about AGI which activity handle identifier will be used in this case?Am I right on my agi-ra idea?

 

Now "org.asteriskjava.fastagi" may be of inspiration here.

The RA indeed establishes an "AgiServer" with asterisk. The "AgiScript" that is fired by Asterisk toward this server might be the activity we're looking for, allowing the Sbb to fire AgiCommands through the RA and catching AgiReply's as events.

[Eduardo Martins]

If the connection activity would be shared by different SBB entities that would be a bad model, due to concurrency.  The request/response is a good first step, but does asterisk provide something a little bit more high level without compromising the concurrency "isolation" of a service logic instance, such as sip dialogs? Also, if the main target is media server funcionalities it may be worth to look for something similar to MMS or MGCP.

-- Eduardo

[Tom Uijldert]

Refer to google issue 508, a first stab at handling request/response properly.

 

Hope this makes some sense.

 

---

From: mobicent...@googlegroups.com [mailto:mobicent...@googlegroups.com] On Behalf Of Eduardo Martins
Sent: woensdag 17 december 2008 13:00