I have a SV9100 that whenever ESRI calls me, my phone rings, I pick it up and the line disconnects. This happens every single time they call me. I can call them with no problems. It could be anyone from ESRI, tech support, my rep, it always disconnects. It does not happen any other time that I know of. The area code the calls come from is 909 in case that helps. The caller gets a busy signal.
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 SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
answering call disconnects caller
- Thread starter JasonIT
- Start date
DoubleDriveLine
Programmer
You are not giving enough information about the system to provide anything more than a guess.
Sounds like you are using SIP trunks and there is a codec mismatch when they call you.
There are 10 kinds of people in the World.
Those that understand Binary and those that don't.
Sounds like you are using SIP trunks and there is a codec mismatch when they call you.
There are 10 kinds of people in the World.
Those that understand Binary and those that don't.
- Thread starter
- #3
We are using a ISDN circuit provided by AT&T as a part of their IP Flex solution. So SIP on the AT&T side, ISDN port is used on the SV9100. It sounds like ESRI is using a SIP client of some sort based on the feedback from the sales staff I have been speaking with. The SV9100 is running 11.00.00. What else would you like to know?
DoubleDriveLine
Programmer
You need to get AT&T involved to have them watch a call as it comes in. AT&T requires G.711 or G.729 with only 20ms packets. But they don't enforce that requirement which leads to issues when one side plays by the rules and the other doesn't.
Example from a few years ago
Customer A has AT&T SIP trunks set for only G.711 or G.729 @ 20ms packets.
Customer B had AT&T SIP trunks using same codes but 30ms packets (don't ask me why).
Customer A could call Customer B and the NEC would allow the 30ms packets.
Customer B would call Customer A and the call would disconnect when it was answered.
We were able to watch this in Customer A SBC and then manipulate the packets so if 30ms was requested it passed it to the PBX as 20ms packets.
Theoretically it should have failed both ways and NEC didn't understand why it let the call establish @ 30ms when that was not in the codec list.
This can happen with AT&T because you are running on their SIP network with no hardware between you and the other customers.
There are 10 kinds of people in the World.
Those that understand Binary and those that don't.
Example from a few years ago
Customer A has AT&T SIP trunks set for only G.711 or G.729 @ 20ms packets.
Customer B had AT&T SIP trunks using same codes but 30ms packets (don't ask me why).
Customer A could call Customer B and the NEC would allow the 30ms packets.
Customer B would call Customer A and the call would disconnect when it was answered.
We were able to watch this in Customer A SBC and then manipulate the packets so if 30ms was requested it passed it to the PBX as 20ms packets.
Theoretically it should have failed both ways and NEC didn't understand why it let the call establish @ 30ms when that was not in the codec list.
This can happen with AT&T because you are running on their SIP network with no hardware between you and the other customers.
There are 10 kinds of people in the World.
Those that understand Binary and those that don't.
You are not reading his post correctly. He is receiving it via PRI not SIP. There are NO SIP issues on the PBX side.
With PRI there is very little you need to be concerned with on your end. Just go over what they are looking for..ascending, clocking etc... Phones need loop or CAP keys (unique CAP is you go that route) I seriously if you can make outbound you should be gold. Get the carrier on the line and get a trap done. Could be a simple setting on their side.
If this is coming from ONLY one location, you need to see if you are blocking the call at the telco side. A LOT of spam blockers do not like people spoofing their caller ID.
With PRI there is very little you need to be concerned with on your end. Just go over what they are looking for..ascending, clocking etc... Phones need loop or CAP keys (unique CAP is you go that route) I seriously if you can make outbound you should be gold. Get the carrier on the line and get a trap done. Could be a simple setting on their side.
If this is coming from ONLY one location, you need to see if you are blocking the call at the telco side. A LOT of spam blockers do not like people spoofing their caller ID.
DoubleDriveLine
Programmer
Sorry read the response again
This is SIP delivered PRI and the code mismatch would be between AT&T and ESRI SIP client.
I have seen this a number of times with AT&T.
There are 10 kinds of people in the World.
Those that understand Binary and those that don't.
JasonIT said:
This is SIP delivered PRI and the code mismatch would be between AT&T and ESRI SIP client.
I have seen this a number of times with AT&T.
There are 10 kinds of people in the World.
Those that understand Binary and those that don't.
- Thread starter
- #8
- Status
Similar threads
- Locked
- Question