Building a server for all your needs.

Mist

Mist

Eeyore Enthusiast
<Gold Donor>
30,382
22,161
Frenzied Wombat said:
SBC is on the carrier side, we don't have one. However the carrier claims the 180/183 messages don't come from the SBC, but once it's passed through the tandem switch to say, Verizon or AT&T. However, they say what is supposed to happen is in the absence of 180/183 progress messages, when the switch sees the 200 message, it is supposed to set up two way audio anyways. Carrier says you can't artificially inject 180/183 messages at the SBC. Basically they are saying there is no RFC obligation to present 180/183, and it's an avaya bug where it is ignoring 200 progress messages.
Click to expand...
This is all a bunch of provider lies and bullshit. The calls work inside your network and don't work when going out to the PSTN.

What is the actual path between the provider and the conference phone? Provider SBC -> ? -> ? -> Endpoint.
 
Frenzied Wombat

Frenzied Wombat

Potato del Grande
14,730
31,802
My telephony guy says signalling comes from the switch and audio comes from the SBC. Avaya Session manager is thrown in there as well.

It really seems though that Avaya considers this a bug in their conference phones, either specifically the B179 or all their SIP conference phones. Though they won't tell us what exactly the problem is, they claim it is now with R&D (highest tier above development) as this is the first time they have seen this behavior. It's obviously a bug that is only surfacing either because of the specifics of our environment, or due to the way the carrier is handling the calls. TBH, Level 3 (now centurylink) has been garbage. We spent a month trying to track down a DTMF issue and in the end it was a problem with the carrier SBC.

For now my telephony guy has found an effective workaround, routing all the conference phones out our ISDN/FAX lines which are providing the proper messaging.
 
Mist

Mist

Eeyore Enthusiast
<Gold Donor>
30,382
22,161
That's why I was trying to pin down the specifics of the environment. What devices and version numbers for the SBC, session manager and CM have a whole lot to do with what's happening here.

Routing them out the legacy ISDN PRI you have for faxing just takes the provider's SIP trunk out of the equation, which is why I'd say this is entirely on the SIP provider since that fixes the issue.
 
  • 1Like
Reactions: 1 user
You must log in or register to reply here.