New SIP trunks keep disappearing, calls hit system but get busy tone

[bigdave1980]

One of our customers has an SV9100 CP10 system which has been working on ISDN30 trunks for years. We have just added SIP trunks to the system as well, although the ISDN will remain in place for now. One of our engineers attended the site and installed the GPZ-IPLE VOIP card on the CPU. I have remotely installed the licenses (they 5103 VoIP Channel License x 16 and 5001 IP Trunk license x 12 installed) and have configured the system for SIP in exactly the same way as we've configured other customer sites.

I tell the system that there are 10 SIP trunks starting at trunk port 41, although the customer only has 8 trunks on their SIP service. I've assigned the first 8 SIP trunks as trunk group 2, with the remaining 2 assigned to trunk group 100 (not used). On the Blades page in PCPro I see the SIP field under the Trunks section populate with the 10 new trunks. I've got a test DDI set up on the SIP and I've pointed that directly at an extension via the DDI routing table. I call the test number and I get busy tone. The same happens wherever I point the test DDI. I know the calls are hitting the NEC because our network engineers were observing the Cisco router whilst I made test calls, and also I connected to the debug terminal in PCPro and could see the calls being rejected with an error message I've not seen before. The SIP service provider took a look from their side and have advised me that the calls are being rejected with a "Busy Here" error message.

I pulled a download of the database again and the Blades page no longer shows the 10 new SIP trunks that were definitely showing there before. I have repeated this many times - set the trunks, take a download, they disappear. Rebooting the system makes no difference.

Below is a screenshot of the Blades page with the SIP trunks showing, in case there's anything wrong I've overlooked there that you can spot, and below that is a sample output from a failed test call I've grabbed from the debug terminal (phone numbers redacted, replaced with xxx).

Any suggestions you may have will be very much appreciated.

Thanks,

Dave

== 7/JUN/2021, 17:11:6 ==
*(EVENT),ID:00000323H,P1:00000000H,P2:00000000H,P3:100DA24CH,P4:00000000H,P5:00000001H
R ISDN : <<<<<<<<<<<<<<<<
3E 0B A1 04 01 01 00 USL(0,0),SETUP IND
08 02 00 38 05 Callref:ORG(56),SETUP
04 03 80 90 A3 Bearer capability [speech]
18 01 AB Channel identification
28 0B 30 31 39 3x 3x 3x Display [019xxxxxxxx]
+3x 3x 3x 3x 3x
6C 0D 00 80 30 31 39 3x Calling party number [019xxxxxxxx]
+3x 3x 3x 3x 3x 3x 3x
70 0C 80 30 32 34 37 35 Called party number [02475xxxxxx]
+3x 3x 3x 3x 3x 3x
this is H323_DMY_PORT_L...
S ISDN : >>>>>>>>>>>>>>>>
13 A1 10 01 01 00 USL(0,0),REJECT REQ
08 02 80 38 5A CallrefES(56),RELEASE COMPLETE
08 02 80 91 Cause (17)
cevent_h323 : Error(lport not find)

 

[bigdave1980]

I tried to add a bigger version of the screenshot image but it didn't work out, sorry. I think the link works though if you want to download it.

Thanks,

Dave

 

[daddybadger]

Has the test ext got access to that trunk group in the access map?

 

[bigdave1980]

Daddybadger,

No it hasn't yet, since I am testing incoming calls only at the moment and I thought the trunk access map etc was only related to outgoing calls. Does it need to have access to it for incoming?

Many thanks,

Dave

 

[daddybadger]

Correct.

 

[bigdave1980]

Sorry Daddybadger, but did you mean that I was correct in saying trunk access map is only for outgoing, or correct that it's required for incoming as well?

Thanks very much,

Dave

 

[daddybadger]

Yes sorry needs setting to all access or incoming,outgoing,when trunk on hold

 

[bigdave1980]

I'll have a look at doing that this afternoon if I can. Also, I had the DDI pointed at a VRS message in order to provide basic auto attendant functionality, something that we've done in may other places without issues but that didn't work either, I just get busy tone when calling the test DDI. Is the trunk access map still relevant to that?

Thanks

 

[daddybadger]

Might wanna check how many digits are being sent from the carrier, I know on the NEC that I've installed I've had to change it to 8 digits and also have the auth user in the table too. It's in 22-something can't remember off top of my head and don't have my laptop at the moment but I'll check when I get a moment.

 

[belevedere]

Number of digits is in MB 22-09-01. The default is 4. I usually set it for 8 (max allowed).

 

[bigdave1980]

I've just had a look at a backup of the database and received digits is set to 6. I'm just connecting up live to the system to have a look at some of the other settings on that form, just in case.

Nope, I tried changing 22-09-03 from Extension Number Specify to DDI Translation Table but it made no difference.

 

[bigdave1980]

If I go unto 14-05, trunk groups, I can see that trunks 41 to 48 are all in trunk group 2 but, in the drop-down menu near the top right, I can see that it says for example "Trunk 041: ???" where I believe it should say SIP in place of ???. I've still got a feeling there's something gone wrong and the system doesn't know that they are SIP trunks. I tell it that they are SIP trunks and they appear on the Blades page for a short while, then they disappear. I don't get it.

 

[bigdave1980]

You know what? I've just tried another test DDI (there were previously no other numbers on the SIP that I could use but I've just seen that a bunch of them have been ported in) and it works. It works perfectly fine every time. The original test DDI does not work still, so there's got to be something wrong with that number. I don't know what's wrong with it, it's set up the same way as the other DDI's in the DDI routing table, but for some reason it doesn't work. As much as I'd like to know why it doesn't work, the important numbers that matter do work so I am leaving it all alone for now.

I only wish there had been other DDI's to test it with before.

Thanks everyone for your help, and sorry for wasting everyone's time. Hopefully it will stay working...

Dave

Edit - Maybe I'm speaking too soon, I will keep trying it and see if it still works Monday. It's possible that the calls are still routing over the ISDN if the numbers haven't finished porting over yet, although I see them on the SIP endpoint.

 

[daddybadger]

Ah glad that's sort of working, very weird though but that's NEC for you.

 

[bigdave1980]

Well, I thought it was working but it looks like the calls are still routing over the ISDN even though I now see the DDI's on the SIP provider's endpoint. So it's back to the drawing board unfortunately. I think I'm going to have to throw in the towel for now but I will maybe take another look over the weekend or on Monday. In the mean time if anybody else has any suggestions of things I can take a look at, please let me know.

Thanks,

Dave

 

[daddybadger]

Have you had confirmation that they have fully ported?

 

[bigdave1980]

No I haven't, but it wouldn't be myself that would get that confirmation, it would be the girls in the provisioning team. We're all done for the weekend now so I can't even check with them until Monday. I suspect they haven't ported fully. If I search for my test DDI on the ISDN30 provider's portal it says no installations found. If I search for it on the SIP endpoint it does find it. Usually I would take that to mean that it's ported but it clearly hasn't. I see that the cease date for the ISDN30 is 16th June so hopefully that'll give me a few days to get the SIP sorted.

 

[CoralTech]

Do you have enough resource licenses?

 

[bigdave1980]

Hi CoralTech, I was wondering about that as well when it initially didn't work but the licenses installed are as follows:

5103 VoIP Channel License x 16
5001 IP Trunk license x 12

I couldn't see any other licenses in Feature Activation that really relate to SIP or VOIP so I think these are the ones, but please let me know if there's anything obvious that I've missed. They do not have any VOIP phones on the system so all the IP/VOIP licenses etc are for the SIP. They've only got 8 SIP trunks on their endpoint although I have programmed the system for 10 and put 2 of them in a trunk group that's not used. I initially tried it with 8 programmed and that was just the same.

Edit - I've just had another look at the Feature Activation and the Blades page again, in order to provide the following information:

Feature Activation says 0300 System Port license is set to 277.
Blades page (Telephones section) says 281 ports of 1472 are in use, but they do not have any IP phones.
Blades page (Trunks section) says 40 ports of 400 are in use, but this info is taken at a time when the SIP trunks are not showing up. If I add them again, the page will show 50 ports in use (until they disappear again).

Does that mean it's under-licensed? I mean, looking at it logically I see that there are 281 extensions in use (or programmed) whilst there are only 277 port licenses which would suggest that there are not enough port licenses, however I think that the system comes with so many port licenses by default (not sure how many or if that's even correct). I'm a bit confused.

Thanks

 

[daddybadger]

The 0300 licence corrosponds to Required for each port TDM/IP station port, trunk port, etc., that connects to the system. This is regardless of whether the port is in use or not) SV9100 comes with 64 resources as standard.

What shows when you press FEATURE + 4 on the DT handset?

What have you got set in PGM 10-54 ?