SIP call-limit and Realtime

Hi,

I've been trying to get working SIP "in use"
indications for usage in
queue, however they are not working with Realtime, unless i
enable
"rtcachefriends". Are there any significant
problems behind this like
with hints and qualify, or this is a bug?

Without "rtcachefriends" i get nothing in
"sip show peers/users/objects/inuse".

Asterisk version - 1.4.17

Regards,
Atis

-- 
Atis Lezdins
VoIP Developer,
IQ Labs Inc.
atisiq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Work phone: +1 800 7502835

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Atis Lezdins wrote:
> I've been trying to get working SIP "in use"
indications for usage in
> queue, however they are not working with Realtime,
unless i enable
> "rtcachefriends". Are there any significant
problems behind this like
> with hints and qualify, or this is a bug?
> 
> Without "rtcachefriends" i get nothing in
"sip show peers/users/objects/inuse".
> 
> Asterisk version - 1.4.17

(Short version)

This is a known issue, that will be non-trivial to resolve. 
It certainly can't 
be done for Asterisk 1.4.

(Long version)

The reason that this happens comes down to the way device
state reporting works 
in Asterisk (1.4).  For a typical state change, something
happens in chan_sip 
that changes the state of a device.  Then, it calls
ast_device_state_changes() 
or something similar.  Now, here is where things get silly.

This function simply queues up an event to the device state
processing thread to 
tell it that the state of "SIP/something" just
changed.  But, to get what the 
state changed to, it has to call a callback in chan_sip. 
For this function in 
chan_sip to find out the state of a device, it has to look
at the SIP peer 
struct.  To get it, it calls find_peer(), which is an
expensive lookup in the 
peer list for the case of non-realtime.  In the case of
realtime, the peer is 
already gone from memory, and it is has to build it from the
realtime backend 
again.  Because of this, important information needed to
determine what the 
state change was is no longer available in the peer struct.

The way this all works has bothered me for a while.  I
improved the situation in 
Asterisk trunk (and 1.6), but the benefits of the changes
have not been applied 
to chan_sip, yet.  Basically, the main change that I made
was to change the 
device state API such that when you call
ast_device_state_changed() or whatever 
it is, you actually provide the state that the device
changed to, as opposed to 
making another thread issue a callback and do some expensive
logic to figure it out.

So, the fix, at least for trunk, is to go through and modify
the uses of 
ast_device_state_changed() and friends to use
ast_devstate_changed() and friends 
so that the new device state is immediately provided.  It
makes the process 
_much_ more efficient, and gets the information out of the
realtime peer before 
it disappears from memory.

Also, not all device state changes are done through device
state API calls in 
the channel drivers.  ast_setstate() also generates a device
state change, which 
is used for _all_ channel types.

Now, here is where it gets a bit more tricky.  There is some
logic in the device 
state handling code that checks to see if the state of the
device has been 
provided for us.  If it has, then it knows device states are
being provided, and 
are truly event driven, and they do not need to be polled
for by issuing the 
device state provider's callback.  In that case, if someone
asks for the state 
of the device, and the device states are being given to us
instead of being 
retrieved with a callback, the last known state from the
cache is returned, 
instead of using the callback.

At this point, none of the channel drivers are using this
new method of 
providing device state.  Only the simpler device state
providers such as MeetMe, 
SLA, Parking, and Custom do.  Because ast_setstate() is
involved, if one channel 
driver gets converted, they all need to get converted.  It's
a big job, but it 
needs to be done.

Getting this done is actually the biggest thing in the way
of implementing 
distributed device state support.  It has been in my head
for a long time, but I 
just haven't been motivated enough to focus down and get it
done.

-- 
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

On 1/19/08, Russell Bryant <russelldigium.com> wrote:
> Atis Lezdins wrote:
> > I've been trying to get working SIP "in
use" indications for usage in
> > queue, however they are not working with Realtime,
unless i enable
> > "rtcachefriends". Are there any
significant problems behind this like
> > with hints and qualify, or this is a bug?
> >
> > Without "rtcachefriends" i get nothing
in "sip show peers/users/objects/inuse".
> >
> > Asterisk version - 1.4.17
>
> (Short version)
>
> This is a known issue, that will be non-trivial to
resolve.  It certainly can't
> be done for Asterisk 1.4.
>
> (Long version)
>
> The reason that this happens comes down to the way
device state reporting works
> in Asterisk (1.4).  For a typical state change,
something happens in chan_sip
> that changes the state of a device.  Then, it calls
ast_device_state_changes()
> or something similar.  Now, here is where things get
silly.
>
> This function simply queues up an event to the device
state processing thread to
> tell it that the state of "SIP/something"
just changed.  But, to get what the
> state changed to, it has to call a callback in
chan_sip.  For this function in
> chan_sip to find out the state of a device, it has to
look at the SIP peer
> struct.  To get it, it calls find_peer(), which is an
expensive lookup in the
> peer list for the case of non-realtime.  In the case of
realtime, the peer is
> already gone from memory, and it is has to build it
from the realtime backend
> again.  Because of this, important information needed
to determine what the
> state change was is no longer available in the peer
struct.
>
> The way this all works has bothered me for a while.  I
improved the situation in
> Asterisk trunk (and 1.6), but the benefits of the
changes have not been applied
> to chan_sip, yet.  Basically, the main change that I
made was to change the
> device state API such that when you call
ast_device_state_changed() or whatever
> it is, you actually provide the state that the device
changed to, as opposed to
> making another thread issue a callback and do some
expensive logic to figure it out.
>
> So, the fix, at least for trunk, is to go through and
modify the uses of
> ast_device_state_changed() and friends to use
ast_devstate_changed() and friends
> so that the new device state is immediately provided. 
It makes the process
> _much_ more efficient, and gets the information out of
the realtime peer before
> it disappears from memory.
>
> Also, not all device state changes are done through
device state API calls in
> the channel drivers.  ast_setstate() also generates a
device state change, which
> is used for _all_ channel types.
>
> Now, here is where it gets a bit more tricky.  There is
some logic in the device
> state handling code that checks to see if the state of
the device has been
> provided for us.  If it has, then it knows device
states are being provided, and
> are truly event driven, and they do not need to be
polled for by issuing the
> device state provider's callback.  In that case, if
someone asks for the state
> of the device, and the device states are being given to
us instead of being
> retrieved with a callback, the last known state from
the cache is returned,
> instead of using the callback.
>
> At this point, none of the channel drivers are using
this new method of
> providing device state.  Only the simpler device state
providers such as MeetMe,
> SLA, Parking, and Custom do.  Because ast_setstate() is
involved, if one channel
> driver gets converted, they all need to get converted. 
It's a big job, but it
> needs to be done.
>
> Getting this done is actually the biggest thing in the
way of implementing
> distributed device state support.  It has been in my
head for a long time, but I
> just haven't been motivated enough to focus down and
get it done.

Thanks for bothering and explaining this in detail  I hope
this will
be useful not only to me.

Event driven arch sounds great, but wouldn't it be
good(possible) to
keep previous state in realtime engine, like it's with
registration
timeout?

Regards,
Atis

-- 
Atis Lezdins
VoIP Developer,
IQ Labs Inc.
atisiq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Work phone: +1 800 7502835

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

On 1/19/08, Russell Bryant <russelldigium.com> wrote:
> Atis Lezdins wrote:
> > Event driven arch sounds great, but wouldn't it be
good(possible) to
> > keep previous state in realtime engine, like it's
with registration
> > timeout?
>
> It might be possible.  I think that's what Mark
Michelson had in mind when he
> just created a branch to work on this.  But, there are
some issues and
> limitations involved with this approach.  For example,
a severe limitation is
> that it can't work if you share the same database
between more than one server.

I think - that shouldn't be a problem with rtsavesysname.

Thank you guys for info, and keep up the good work 

Regards,
Atis


-- 
Atis Lezdins
VoIP Developer,
IQ Labs Inc.
atisiq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Work phone: +1 800 7502835

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

This also touches my earlier questions about what realtime
SIP buddies  
really are.
Today, we have an unsatisfactory mix between the old sip
buddies that  
are classified
as realtime dynamic objects and the "cached"
objects.

The cached objects should really be just another way of
loading a  
static object
in memory and keep it there as long as it is needed - during
 
registration for
peers that register and from first activity and forever for
peers with  
a host definition.

In addition to that we need cli and manager commands for
releasing,  
loading
and reconfiguring these objects to match the database
changes.

People expect the cached realtime objects to be static. They
are not.
And as such, we cannot provide the same services to them
today.

I would like to see a cleanup here.

/O

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev