[NCP500] Ring multiple extensions 2

[smokeyjones]

I am trying to add a 2nd office telephone (a DT343 handset with ext: 212) and have it ring along with the original handset (ext: 201). I have added both to the 601 IDC Group and pointed incoming calls to that instead of 201.

I have set ring to immediate but only 201 rings still. What am I doing wrong (or haven't yet done)?

Thanks,

Dave

 

[FTPMmike]

What are your CO lines? SIP, PRI, POTS? If SIP/PRI, you need to reirect the DID in the DID section, under the appropriate DID listing. If POTS, you'll need to direct the line at the DIL section. Redirect to 601.

Put both members in ICD601, with Ring:Immediate. Make sure both phones have their ringers on

If the phones have log-in/log-out buttons, make sure both phones are also logged-in to the ICD group.

 

[smokeyjones]

Yes, we're using SIP and I've already got the 601 IDC group listed in the DDI/DID Destination tab of the 10.3 DDI/DIL Table. The only thing I've not checked is the phone's ring setting...although if it rings on an internal call, wouldn't that indicate it already has its ringer on?

 

[obtsystems]

down load the sip trace from the system and see what is coming in, you will have to match what is coming in

Have you dialled 601 internally to see if both ring?

 

[smokeyjones]

OK, I have downloaded the SIP trace but can't see anything that helps?!

Yes, if I dial 601 internally, both ring as intended.

 

[smokeyjones]

In 4.1.1 Extension Settings, extension 201 has a COS of 64 whereas every other extension has a COS of 1. (There is one extension that is tied to a particular number and that has a COS of 2).

 

[bigglesnz11]

I would take a guess they ext.212 is set as the operator and there is an issue with the ddi digit mapping on the SIP trunks,
If the mapping is incorrect, the system doesnt recognise the ddi destination, so the call is sent to the operator
two ways to make it work
1: check and correct the incoming DDI table
2: set the operator as ICD 601

the 1st option would be the preferred one

this is only an educated guess without seeing any of the program...

 

[bigglesnz11]

I would take a guess they ext.212 is set as the operator and there is an issue with the ddi digit mapping on the SIP trunks,
If the mapping is incorrect, the system doesnt recognise the ddi destination, so the call is sent to the operator
two ways to make it work
1: check and correct the incoming DDI table
2: set the operator as ICD 601

the 1st option would be the preferred one

this is only an educated guess without seeing any of the program...

 

[smokeyjones]

Don't know if this helps at all? The first row did have the CLI Ring set as Disabled for all four Day, Night, etc so have changed that as you can see - not sure if that would have any effect? (Can't test till the morning.)

Edit: I'd already changed the operator settings from 201 to 601 to see if that would make any difference.

 

[obtsystems]

You have to convert into wireshark to look at trace

Cli routing is only enabled if using call routing for a caller in the phonebook

How many digits are the sip provider sending in. If national or international

This can be seen in the trace or your provider could tell you

 

[bigglesnz11]

So if you ring the operator - Both phones ring?
If you ring ICD 601 - Both phones ring?
If you ring the ddi - Only 214 rings?

I think it is an issue with matching the amount of digits the provider is sending in ( Here , we can get anything from 3 to 10 digits depending on the Telco)

 

[smokeyjones]

Yes, yes and yes.

So the trace contains this:

sip:1234555666@[our public IP]:35060;user=phone SIP/2.0
Max-Forwards: 69
Session-Expires: 3600;refresher=uac
Min-SE: 600
Supported: timer, 100rel
To: "Office 1" <sip:1234555666@[SIP Provider IP>;tag=19338
From: <sip:01234987654@[SIP Provider IP]>;tag=3682750548-667662

Our DDIs however, are listed as 01234555666 (i.e. 11 digits as opposed to the 10 digits shown in the trace) - is this what you both mean?

 

[bigglesnz11]

I would look at deleting the 1st 0 on your ddi table (back to 10 Digits)
another way to confirm that the string is not matching would be to change the operator extension to some other extension (maybe 212) make an inbound call , if it rings to 212 ten that would definitely point to a mis-match of the number of incoming digits from your provider

 

[obtsystems]

Is that a mix of headers, as I would not expect to see To: "Office 1 <sip:1234555666@[SIP Provider IP>;tag=19338 come in from your provider, that looks like outgoing.

We used to have problems years ago with basic rate isdn sending in different length of numbers on different exchanges, some times from where the call came from so since then we would strip the number down on basic rate ISDN.

so if the number is 0123456789 the table would look like this

0123456789 601
123456789 601
23456789 601
3456789 601
456789 601
56789 601
6789 601
789 601

it never went below 3 digits. a little extra work but saved us a lot of time in the long run.

don't normally do this with sip or PRI lines as they are normally the same length once we found what that was.

 

[smokeyjones]

Bingo...I think! Removing the leading zero has made everything work as intended. We haven't tested properly yet but the first hurdle appears to be overcome. Thank you both for your help and patience.