[asterisk-ss7] chan_ss7 SAM and overlap signaling

Tue Mar 6 01:49:48 MST 2007

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
>>
> 
> 