I don’t see any problem to call this destination too in this dial plan
with
00xxxxxxxxxxxxx (13 digits)
after the system gets
003524781
because no more digits are following and there isn't a shirt dial plan
for this destination that matches, t35 timer will expire, and the call
will be processes.
BR
Ercan
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marc Storck
Sent: Montag, 5. März 2007 14:34
To: asterisk-ss7@lists.digium.com
Subject: Re: [asterisk-ss7] chan_ss7 SAM and overlap signaling
This works perfect as long as you have a closed numberingplan with fixed
length numbers, but open numberingplans still exist.
In your example the fixed length of 13 digits for the world won't work
if you would like to call the Governement in Luxembourg (+352 478-1,
this is not a special shortcode but a shortend geographic number.) or
any of the extension which are generally +352 478 NXXX. This is just one
example from many.
Best regards,
Marc
Ercan Yücebas wrote:
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ercan
Yücebas
Sent: Donnerstag, 1. März 2007 16:06
To: asterisk-ss7@lists.digium.com
Subject: RE: [asterisk-ss7] 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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kai
Militzer
Sent: Donnerstag, 1. März 2007 15:30
To: asterisk-ss7@lists.digium.com
Subject: Re: [asterisk-ss7] 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
