libss7 and IAM/ACM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Barry O'Donovan <barry at opensolutions.ie> writes:

> For testing purposes, I have the following simple dialplan:
>
> [ss7]
>
> exten => 0766016007,1,Hangup(34)
>
>
> So you can see that for testing we do an immediate Hangup(). This works with 
> chan_ss7 but we'd prefer to use libss7.

Why do you prefer libss7 over chan_ss7?

(Just interested in knowing your reasons. I know that libss7 has the advantage
that it inherits all the features of chan_zap, and that it is done by Digium
so included in main sources. While chan_ss7 has the advantage to support
clustering with MTP3 and failover, so one asterisk server can be down without
disrupting calls. I was wondering if there were other important differences?)

> libss7 sends an ACM packet after it receives the IAM. The ACM means that a 
> channel has been reserved for the call but we are trying to indicate 
> conjestion. But, also, in any application such as operating a SS7 to VoIP 
> gateway, we need to verify the available of channels/bandwidth/etc before 
> sending the ACM.

The ISUP meaning of ACM is "address complete message".

This is a heritage of old-style telephones, where there is no need or
possibility for indicating when one is done entering digits of a phone number.

The scenario is that a person is dialing the digits of a number one by
one. But the first switch may be able to determine the routing of the call
from just some initial part of the number, without knowing all of the
digits. In fact the first switch may not know how many digits are needed at
all, so it may be unable to determine on its own whether the person is done
dialing. This would be typical eg. in an international call, as the
originating switch is unlikely to know the dialplan of every location in the
world.

So call routing can be started even before all digits have been dialed. But
once some switch (maybe the terminating switch) has determined, from its
knowledge of the local dialplan, that all digits needed have been dialed, it
can send back ACM to inform switches earlier on the route about this fact.

(There are more details of course, Q.76x has them all).

So my point is that probably the sending of ACM should actually be under the
control of the dialplan in Asterisk, as it is the dialplan that determines
when the address can be considered complete. SIP and other similar protocols
do not have the notion of incomplete address and partial routing (the
destination address is always available as a whole), so this aspect of SS7
does not fit in well with Asterisk as it is...

I do not know how libss7 works in this respect, and I do not fully remember
how chan_ss7 handles it either (sorry).

But I do remember we discussed this quite a bit for chan_ss7. One idea (that I
_think_ was implemented) was that the address is considered complete if the
number received so far matches any extension in the dialplan. This seems
natural, but actually will not work for your scenario. Another option is to
not send ACM at all, but send CON directly (this is probably what you were
using when working with chan_ss7).

Probably what needs to be implemented for your scenario (in libss7 and
chan_ss7) is to either have an explicit dialplan command that sends ACM, or
alternatively to delay sending ACM/CON until the first ringing/answer
indication (which would also make good sense).

Anyway, just a bit of background information, hopefully it helps.

 - Kristian.



[Index of Archives]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite Backpacking]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]     [Asterisk Books]

  Powered by Linux