[asterisk-ss7] chan_ss7 SAM and overlap signaling

Tue Mar 6 02:47:18 MST 2007

In my case, i never wrote this dialplan _ABCDE00352XXXXXXXXXX, because I
don’t have a specific dialplan for Luxembourg, for me this doesn't
apply. With the carrier selection code in front of number, we are
getting only swiss numbers in national or international format and
international numbers in international format. For me it works fine now.

And for you, 

You shouldn't make something like that

_ABCDE00352XXXX.,1,....

because in this case you will be never able to get longer numbers! 

But this dialplan below 

_ABCDE00352XXXXXXXXXX,1,...  (I don’t know how many x's you need)

will work for you fine, because

a) if your customer are dialing longer numbers, it will match and
chan_ss7 will stop receiving more SAM's and it process the call.

b) if your customer are dialing short numbers, it will not match to
dialplan above, chan_ss7 will wait for additional SAM's but the t35
timer will expires and chan_ss7 will stop receiving SAM's and it will
process your call

BR
Ercan

-----Original Message-----
From: asterisk-ss7-bounces at lists.digium.com
[mailto:asterisk-ss7-bounces at lists.digium.com] On Behalf Of Marc Storck
Sent: Dienstag, 6. März 2007 09:50
To: asterisk-ss7 at lists.digium.com
Subject: Re: [asterisk-ss7] chan_ss7 SAM and overlap signaling

Well, if you implement this with

_ABCDE00352XXXXXXXXXX,1,...

it will not work, unless you use

_ABCDE00352XXXX.,1,....

but then in that case we would need to have a working overlap support as

in chan_zap.

I may get things wrong however. If you have another idea, please share 
it so we can all test it.

Best regards,

Marc

Ercan Yücebas wrote:
> 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: asterisk-ss7-bounces at lists.digium.com
> [mailto:asterisk-ss7-bounces at lists.digium.com] On Behalf Of Marc
Storck
> Sent: Montag, 5. März 2007 14:34
> To: asterisk-ss7 at 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: asterisk-ss7-bounces at lists.digium.com
>> [mailto:asterisk-ss7-bounces at lists.digium.com] On Behalf Of Ercan
>> Yücebas
>> Sent: Donnerstag, 1. März 2007 16:06
>> To: asterisk-ss7 at 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: asterisk-ss7-bounces at lists.digium.com
>> [mailto:asterisk-ss7-bounces at lists.digium.com] On Behalf Of Kai
> Militzer
>> Sent: Donnerstag, 1. März 2007 15:30
>> To: asterisk-ss7 at 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
>>
> 
> 
_______________________________________________
--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