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@xxxxxxxxxxxxxxxx > [mailto:asterisk-ss7-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Marc Storck > Sent: Montag, 5. M?rz 2007 14:34 > To: asterisk-ss7@xxxxxxxxxxxxxxxx > 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@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 >> > >
|