Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

SV9100 SIP and 486 BUSY Response

Status
Not open for further replies.

JBNB

IS-IT--Management
Jun 25, 2010
20
CA
Hello, we have a SV9100 system that has been switched over to SIP. Incoming and outgoing calls worked for a couple of days and then all of a sudden all incoming callers receive a busy response. Our VOIP provider is seeing a 486 BUSY response when our main number is called. Nothing was changed between the time where everything worked and when the busy response started happening. We can call our pilot number and the call goes through to the auto-attendant just fine. Currently our main number is camped on top of the pilot which is a temporary work around. Does anyone have any thoughts on where I can look to try and resolve the issue? Thanks!
 
Ok, a lot of terminology I don't understand here. What VM are you using? Normally you can't call the VM dept grp number and get an AA prompt. What do you mean camped on your pilot? Did you or your vendor set this up?
 
Thanks for responding. I'm a networking guy but I have no phone or VoIP experience so I'm sure that I'm going to mess up the terminology even more. Our phone contractor programmed the SV9100 and has reached out to NEC for assistance. Our SIP provider "camped" the number on the pilot. I'm not sure exactly what that means but it seems similar to forwarding the number to another line. If people call our main number it gets redirected to our pilot number. As for what VM, do you mean what voicemail system are we using? Inmail.
 
Sounds like a routing issue with DID numbers. I would need to look at the programming to see anything glaring. Most of the time it's a typo in the DID tables.
 
I would suggest it is either an issue with the diversion on your main business number, or within the DID programming as suggested by CoralTech in 22-11.

Do you know if the SIP is still currently registered? You should be able to ascertain this through PuTTy and turning on settings in the 9100

10-20-06 - set port, by default I use 8006
90-31 - Turn on DIM Access over ethernet

Open PuTTy, select Telnet, put in your system IP and Port 8006

Login by default should be SV9100, password 12345678 (Please Note, that when putty first loads, there is a ' in the login name, so I press enter to get another blank username field)

type ip info a

This will show you all the possible SIP Trunks, scroll to the top and it should show if your SIP is registered.

-----------------------------------
IP TRUNK REGISTRATION INFORMATION
-----------------------------------
H.323 TRUNK:
not REGISTERED to GK (SD)
SIP TRUNK:
[RegId0][UserId:******] REGISTERED to SIP Server(9/9 8:25)
[RegId1][UserId:] not REGISTERED to SIP Server(9/8 16:12)
[RegId2][UserId:] not REGISTERED to SIP Server(9/8 16:12)
[RegId3][UserId:] not REGISTERED to SIP Server(9/8 16:12)
[RegId4][UserId:] not REGISTERED to SIP Server(9/8 16:12)
[RegId5][UserId:] not REGISTERED to SIP Server(9/8 16:12)
[RegId6][UserId:] not REGISTERED to SIP Server(9/8 16:12)
[RegId7][UserId:] not REGISTERED to SIP Server(9/8 16:12)

This will tell you if at least your SIP is working and rule out one issue.

 
Thanks for the info. I will take a look when I am back in the office tomorrow.
 
It looks like SIP is registered. The UserID is showing the pilot number provided by our SIP provider (example 1221234567).

-----------------------------------
IP TRUNK REGISTRATION INFORMATION
-----------------------------------
H.323 TRUNK:
not REGISTERED to GK (SD)
SIP TRUNK:
[RegId0][UserId:12221234567] REGISTERED to SIP Server(9/9 9:6)
[RegId1][UserId:] not REGISTERED to SIP Server(9/7 20:11)
[RegId2][UserId:] not REGISTERED to SIP Server(9/7 20:11)
[RegId3][UserId:] not REGISTERED to SIP Server(9/7 20:11)


When SIP was first configured our main phone number (example 12224567890) was ported over to our SIP provider from our previous carrier (copper lines). Everything was working fine for a couple of days and then the busy response started. Here are our DID Translation Table settings (22-11)

01-Received Number - 4567 (which matches the last 4 digits of our pilot number)
02-Target 1 - 3999
03-DID Name - <blank>
04-Transfer Operation Mode - Busy/No Answer
05-Transfer Target 1 - 1
06-Transfer Target 2 - 0
07-Call Waiting - Unchecked
08-Max Number of Calls - 0
11-Fail over IRG - Checked
16-Private Call Refuse - Follow PRG14-01-27

Should the setting of 22-11-01 match the last four digits of our main business number (7890)?
 
If your numbers were ported you probably need to make it the new number.
 
In DID Table 2, do you have the dummy number you had on your SIP Carrier? the number your main business number is diverted to?
 
Hoping to hear back from NEC today.

CorelTech - Will try setting 22-11-01 as our business line once I get a chance to test with our service provider.

Daniel RO - Do you mean DID Translation Table Entry 2? Right now only entry 1 has a number set on it (our pilot number).
 
If you have your pilot number diverted to another number that is with your SIP Carrier, you would need to program in the what I call a dummy number that your SIP Carrier is using until porting happens.

eg. We use a SIP carrier, and port a customers main business phone number to them from whichever carrier they are with. In the process between application being submitted, and port happening (can be approx 8 weeks), we connect SIP Trunks to the system with a dummy number. In 22-11 we have the customers main business number programmed as an entry (table 1), and our dummy number programmed as an entry (table 2), and divert the customers main number to our Dummy number. That way when porting happens, we don't need to change any programming at all, and the lines just continue to work with minimal downtime.
 
Adding the the second entry in the DID table seems to have resolved the issue and the system is now routing incoming and outgoing calls correctly. Incoming callers are no longer getting a busy signal.

Thank you for your help!!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top