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@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: [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@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: [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 > -- Marc Storck (CIO) voipGATE S.A. Tel: +352 20 200 222 Fax: +352 20 200 922 mstorck@xxxxxxxxxxxx http://www.voipgate.com Datacenter Group Tel: +352 20 200 522 www.datacenter.lu | www.eurodns.com | www.voipgate.com
|