ThinkTel SIP trunks on SV9100

[conxtel]

I am located in Canada and recently moved a customer from a Telco PRI to ThinkTel SIP trunks.

One issue they are having is when they call one of their suppliers and reach that company's auto-attendant and ACD queue, the call will disconnect. It is after the called side plays the "your call is important to us, please hold" message. The caller will hear a beep, and then a few seconds later, a second beep and then call disappears.

It only seems to happen to that ACD queue so far. I have called other companies and reach auto-attendants and the call stays up without an issue.

ThinkTel tech support sent this information:
"The INVITE received from the NEC-SV9100 , i can see 2 issues in the SDP headers.
1- (Minor) Connection Information (c): IN IP4 192.168.10.42 (This should be your public IP Address)
2- (Major) in your invite the DTMF RFC2833 (101 payload) is missing , how can you call to an auto-attendant , what DTMG type are you using ?"

Issue 1 - That is my IP address from 84-26. I cannot change it to the public IP
Issue 2 - I have never had to tweak any of the RFC2833 settings for other customers that are also using ThinkTel.

Anybody come across similar issues or have any ideas what to check?

 

[Shaun E]

For issue 1, you set the public IP address used for invites in 10-29:

- 10-29-21: NAT Router: Used
- 10-29-24: NAPT Router IP Address: Set to your public IP.

The DTMF payload number is set in 84-34. It's 110 by default and you might need to change it to 101 for that profile.

 

[conxtel]

Thank you. I made the changes and ThinkTel is seeing the correct IP and payload information now but calls are still being dropped.

They said when we reach the called side auto attendant, make our selection, the called system is sending a hold request and the 9100 is rejecting it. ThinkTel is checking settings on their side to see if any changes can be made.

 

[CoralTech]

It sounds like your payload is still wrong. Make sure you selected the correct SIP trunk profile.

 

[conxtel]

SIP trunks are set to Profile 1 and payload is set to 101.

 

[CoralTech]

Ok, but are they using 101? Also, some settings require a reboot. I've also seen 96 used as well.

 

[conxtel]

ThinkTel modified a setting on their side and it is working now.

 

[DoubleDriveLine]

Don't forget it could be a codec mismatch. We had 2 drug store chains here in the US that had this same issue. They used a 3rd party IVR to front end their calls. If you chose to speak with a pharmacist you transferred out of that system and into their call center. The IVR was not licensed for G.729 so it would connect the call at G.711 and the call center would try to negotiate the call codec at G.729 as first choice. The problem was to the NEC the call was established and it is not going to renegotiate the codec at that point. The call would normally drop at this point but sometimes it would stay connected. With a Wireshark capture I could actually see both sides of the audio stream but neither side could hear the other. For the one Drug Store chain I talked to there Telecom IT personal and they changed the codec order on the Call Center to be G.711 first. This solved the issue for them.

For the other Drug Store chain they told us to get stuffed the issue was on our side. The result is I told the customer to use the one drug store not the other.

A wireshark capture will go a long way to help you troubleshoot this issue.





There are 10 kinds of people in the World.

Those that understand Binary and those that don't.