E911 call failed without trying other codecs

[Evolute IT]

Huy guys,

The other day, one of my customer tried to call 911 using his VoIP system. It is configured since v15.5 SP3 so we haven't touched anything except upgrade to v16.

While it was working before, right now, calls to 911 don't work if G722 is the first codec in the list. My provider sent me this screenshot of the call capture, we see the INVITE with all my 4 codecs but since the 911 center here doesn't support G722, only PCMU, it didn't fallback and the call simply failed.

From what my provider said, 3CX should've retried with other codec priorities or something like that.

Can someone tell me if this is the expected behavior?

 

[cobaltit]

Unless I'm reading that wrong it looks like it's a provider issue, not 3CX. Without seeing the rest of the capture I'm guessing the problem is that your provider accepts the leg of the call using G.722 but then when they try to hand it off to the PSAP or whatever they call it up there in Canada they only do G.711. At that point your provider should renegotiate but isn't and then they are passing the rejection back to you. What does the SDP say in the next packets (100 Trying or 183 In-Progress)? Those tell me your provider accepted the call at that point.

 

[eddv123]

I would agree, the SDP body is where you need to look. The supported codecs are published during the SIP setup of the call; mentioned in the SDP part of the INVITE/200 OK exchange.

If the provider is not renegotiating then you need to find out what codecs are being offered/supported by them.

An audio stream cannot be established between two parties unless a mutually supported codec is found and used.

 

[Evolute IT]

Unless I'm reading that wrong it looks like it's a provider issue, not 3CX. Without seeing the rest of the capture I'm guessing the problem is that your provider accepts the leg of the call using G.722 but then when they try to hand it off to the PSAP or whatever they call it up there in Canada they only do G.711. At that point your provider should renegotiate but isn't and then they are passing the rejection back to you. What does the SDP say in the next packets (100 Trying or 183 In-Progress)? Those tell me your provider accepted the call at that point.

Can I DM you the full capture? I won't put it public since my IP is in there but maybe you can help me figure out what part didn't work.

Sadly, I don't have a capture from their E911 provider.

 

[eddv123]

Shame, you should use a provider like Twilio, they will let you capture on the provider platform as well, really helps in circumstances such as these.

 

[Evolute IT]

Shame, you should use a provider like Twilio, they will let you capture on the provider platform as well, really helps in circumstances such as these.

My provider provided me the capture I attached. I just don't think they capture on the other end from their system to the 911 provider (whatever it is called).

 

[eddv123]

PSAP: https://tools.ietf.org/html/rfc7090

Well a capture in some form is better than none, I have known providers where you have to rely on what they tell you is occurring on the platform - I much prefer having the option to do this myself.

 

[Evolute IT]

PSAP: https://tools.ietf.org/html/rfc7090

Well a capture in some form is better than none, I have known providers where you have to rely on what they tell you is occurring on the platform - I much prefer having the option to do this myself.

I told my provider to check their system since this does seem like a Provider issue and not a 3CX issue.

 

[leejor]

If your provider supports G722, and I assume it does as you've put it at the top of the Codec list, then I can't believe that you are the only (the first?) one having this issue. I should think that your provider has gone through this before, and that they may know more than they are letting on.