Pls Help on Incoming call routes 1

[Millsey]

I have just ordered an additional DDI range on our PRI circuit. The existing DDI range is
ABCDE 5031XX (where that is a 5 digit STD code) , we have just added
ABCDE 5151XX range.

I cannot get the incoming routes working. If I have a user Craig (extn 117) with DDI 503117 I can add that and it works. But then I want DDI 516117 as his fax number - but it always mathces to the first route and rings his phone. I have tried left to right number matching with and without the ABCDE code but it does not work, it falls through to the default route.

Does anyone see a way I can get this working short of asking for a different DDI range with a different 4th number such as 5162XX which I think we could definitely get working??

Cheers
Millsey

 

[tlpeter]

change the extension lenght to 4 digits
then your problem is solved
or change the fax extension number to a different range
this can also be a 4 digit range (example 2117)
you can not have a duplicate extension number

 

[disturbedone]

The telco (BT??) are only sending you 3 digits. It matches from the right hand side so it effectively receives 7 then 1 then 1. As soon as it's got those (117) it matches to the first ICR it comes across which is for Craig's User.

You need to get the telco to send mroe digits. At least 6 would be best, if not more.

 

[Millsey]

Well the faxes are diverted to shortcode F. which does DialExtn to 499 which is a huntgroup with two members 181 and 182, this was the only way to preserve the dialled number to give tot he fax server on those two extensions.

I don't have a different extension number for each person, I have a two port fax server. There are no duplicate numbers at all.

 

[Millsey]

Yes it is BT and you might be right disturbedone. I will check with our broker ASAP.

Thanks for inputs
Millsey

 

[disturbedone]

It's strange. BT default is 6 digits. But who knows, they do what they want when they want!!! lol

You can prove it with a Monitor trace with ISDN layer 2&3 you will see what they're sending you.

But this is definitely what it sounds like.

 

[intrigrant]

Changing the number plan can solve the problem, but it can be done in the incoming Call Field:

The IP Office matches incoming DDI digits from right to left.
So as soon as the ipo sees 17 it will match the first incoming call route programmed.
If you want to compare against the whole DDI number then just put a minus sign before the DDI number in the incoming call route.
Like this:
Line ID = 0
DDI = -ABCDE503117
Dest = Ext117

lineID = 0
DDI = -ABCDE515117
Dest = Ext217

This way each DDI number is treated differently.

 

[disturbedone]

intrigant & tlpeter......changing the internal numbering plan has nothing to do with it.

He has an ICR for 503117 point to User 'Craig' which is xtn 117. He also has an ICR for 515117 pointing to Short Code 'F' which dials 499. The ICRs have two different destinations. The reason both are going to the same place is that both DDIs are only being sent from the telco as digits 117. The telco is not differentiating between 503117 and 515117. They need to send more digits ie 3117 and 5117 (or more digits) so the ICRs can tell the difference.

 

[intrigrant]

I our country we always receive the complete DDI number, it was not clear to me that he only received the extension number.

 

[disturbedone]

BT (UK major telco) are like the majority of telcos around the world....they do what they want, when they want. The default when they set up DDIs are to send 6 digits. However, if the temperature is between 11.3 or 15.9 degrees outside and Bob is having sandwiches for lunch today then for some stupid reason they decide to change their rules and do whatever they want on that particular day!! They don't have any rhyme or reason for doing what they do, they just do it. Which makes techs lives difficult. If they did what they were supposed to do all the time then we wouldn't have any problems.

When you say your telco always sends the full DDI, you're lucky. That's the way it should be. But in this case they clearly aren't doing that.

 

[Millsey]

It looks like BT are only sending 3 digits as suggested; The monitor shows me

34797mS ISDNL3Evt: v=5 stacknum=5 State, new=Present, old=NullState id=20
34802mS PRN: National Number in prefix 0
34802mS CMLineRx: v=5
CMSetup
Line: type=Q931Line 5 Call: lid=5 id=20 in=1
Called[117] Type=Unknown (0) SndComp Calling[01704515500] Type=National (2) Pres=Allowed (0)
BC: CMTC=Speech CMTM=Circuit CMTR=64 CMST=Default CMU1=ALaw
BChan: slot=0 chan=2
34803mS CD: CALL: 5.20.1 BState=Idle Cut=1 Music=0.0 Aend="Line 5" (0.2) Bend="" [] (0.0) CalledNum=117 () CallingNum=01704515500 () Internal=0 Time=0 AState=Idle
34804mS PRN: AdjustCount 1,0 -> cur=1 out=0 v=1 d=0
34805mS CMTARGET: LOOKUP CALL ROUTE:39 type=0 called_party=117 sub= calling=01704515500 in=1 complete=1
34806mS CMTARGET: SET BESTMATCH:39 length 0 vs 0 match= dest=VM:INCOMING
34806mS CMTARGET: SET BESTMATCH:39 length 3 vs 0 match=117 dest=117
34806mS CMTARGET: LOOKUP INCOMING CALL ROUTE:39, calling party is 01704515500. Using destination 117
34807mS CMTARGET: ADD TARGET:39 number=117 type=0 depth=1 nobar=1 setorig=1
34807mS CMTARGET: SET USER:39 CraigS orig=1
34807mS CMTARGET: ADD USER:39 CraigS(117, state=Idle) (depth=2 B=0) cw=0
34808mS CMTARGET: LOOKUP CALL ROUTE:39 returned 1

Looks like BT are the villain
Millsey

 

[aarenot]

request more digits from the telco. we have never had issue recieving nore digits from telco.

 

[tlpeter]

those stubborne english
also keep driving on the wrong side off the road

 

[Millsey]

Thanks all for your inputs. Star to disturbedone for getting me on the right tracks.

Regards
Millsey

 

[disturbedone]

although BT have their monents, they're the same as telcos all over the world. I've had the (dis)pleasure of running into telcos in several countries all around the world and they're all the same. They do what they want, when they want and answer to no one. When you ring them they always have the same answer - "it's not our fault". Even before you've explained the problem. You learn not to trust anything they say and prove it yourself.