chan_ss7 SAM and overlap signaling

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

 



I think the best way for getting SAM working, like you already
mentioned, is to implement the national and as possible as the
international numbering format, then chan_ss7 waits for additional SAM's
and only for same international numbers, the timeout will be active.

In my case (ABCDE is our carrier selection code) here in Switzerland

_ABCDE0041xxxxxxxxx 
_ABCDE01xxxxxxx
_ABCDE02xxxxxxx
_ABCDE03xxxxxxx
_ABCDE04xxxxxxx
_ABCDE05xxxxxxx
_ABCDE06xxxxxxx
_ABCDE07xxxxxxx
_ABCDE08xxxxxxx
_ABCDE09xxxxxxx
_ABCDE00xxxxxxxxxxxxx (00+13 digits for the rest of the world)

for many countries it's also possible to implement such a dialplan
(numbering plan)

BR
Ercan





-----Original Message-----
From: asterisk-ss7-bounces@xxxxxxxxxxxxxxxx
[mailto:asterisk-ss7-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Ercan
Y?cebas
Sent: Donnerstag, 1. M?rz 2007 16:06
To: asterisk-ss7@xxxxxxxxxxxxxxxx
Subject: RE: chan_ss7 SAM and overlap signaling

I see

I changed the code to not to check a maching dialplan in order to not
stop receiving SAM's, and just with t35 it's working now. Maybe I gonna
work more on it, then I gonna send this to community, i will test it now
for a while...

After I get all the dialed digits properly, now the call can pass
through the dial plan to match to shortest pattern, the timeout is too
short with 100-200 msec.

>From one point of view, it's wrong, that chan_ss7 stops receiving of
further digits, further SAM's, if it knows that they exists. Because
then it will not be able to forward the right dialled digits. From one
another point of view, like you mentioned - i.e. call center - maybe
this behaviour is an expected one.

I think that the expected behaviour on an asterisk FXO interface
connected to a Phone and an ss7/E1 interface and Gateway functionalities
can be totally different.

BR
Ercan


-----Original Message-----
From: asterisk-ss7-bounces@xxxxxxxxxxxxxxxx
[mailto:asterisk-ss7-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Kai Militzer
Sent: Donnerstag, 1. M?rz 2007 15:30
To: asterisk-ss7@xxxxxxxxxxxxxxxx
Subject: Re: chan_ss7 SAM and overlap signaling

Hello Ercan,

On 01.03.2007 11:59, Ercan Y?cebas wrote:
> I just find out that the number of SAM's are depending on from what
type
> of line (analog or isdn) you are making the calls
> 
>>From an isdn line, all pending digits are sended in one SAM
> But
>>From an analog line, every pending digit are sended in a separated SAM


It seems to you you have some problems understanding how SAMs work
(should
work) with chan_ss7, so I will try to shed some light on it.

At first you need to know that it depends on the phone on the
originating
side of the call and the involved switches on the way to you asterisk if
and how digits are submitted in subsequent address messages. For example
with modern digital or analog DECT phones that dialed number is in most
cases submitted in one block (digital phones do this directly on the
ISDN
layer, analog phones because they dial the digits very "closely" to each
other), with an old analog phone you can easily trigger the generation
of
SAMs on the originating switch by dialing slowly.


On the asterisk side the handling of SAMs depends on what you are doing
and
how your dialplan looks. If you have a "real" dialplan on the asterisk
that
terminates the SS7 connection, e.g. because you use it for a
call-center,
you may want to handle the matching there. For this case the handling of
SAMs implemented in chan_ss7 works just fine (at least that's what the
source looks like, I have never tested it myself).

If your dialplan is not able to handle SAMs, e.g. because you use your
asterisk only as a "dumb" gateway from SS7 to IAX2 or SIP, it gets
trickier. In this case you only have knowledge if the number is
complete,
if the switch you are connected to tells you so by attaching a 0xf after
the last digit to the last SAM. The problem is, that can only be the
case
in some defined situations, for example if you reach the maximum of
allowed
digits. In all other cases you have to find a way to detect by yourself
if
the number is complete. The only way to do this is to use a timer, in
this
case the t35 timer. Simply put, after each received IAM or SAM you wait
a
defined amount of time if a(nother) SAM arrives. If you receive one, the
timer is stopped and started again to wait for another SAM and the
number(s) in the SAM are put at the end of the already received digits
(from the IAM and/or previous SAMs). If the timer times out without
receiving another SAM the dialed number is complete and you can transmit
it
to asterisk, that then matches it with the dialplan.

In chan_ss7 you can define the timeout for t35 and if a received 0xf in
an
IAM or SAM should stop the timer, the only problem is, that at least in
chan_ss7-0.8.4 this is broken and works not as it should. I attach a
patch
that I think fixes this behavior, but I cannot guarantee that it works,
and
won't break any other wanted behavior handling SAMs and t35.

I hope I could make you understand the handling of SAMs in asterisk and
chan_ss7 a bit better, if not, feel free to ask.

Regards,
Kai

-- 
Kai Militzer                  WESTEND GmbH  |
Internet-Business-Provider
Technik                       CISCO Systems Partner - Authorized
Reseller
                              L?tticher Stra?e 10      Tel
0241/701333-14
km@xxxxxxxxxxx                D-52064 Aachen              Fax
0241/911879
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
Die Gesellschaft ist eingetragen im Handelsregister Aachen unter HRB
7608
Gesch?ftsf?hrer:           Thomas Neugebauer, Thomas Heller, Michael
Kolb

_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

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


[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