How To Deal With Error Messages Passed As Early Media
Hello,
I’m trunking with an ITSP that, when treating an outbound to an unknown destination, either:
– send a SIP error code (I can’t be more explicit, at the moment),
– or cast a pre-recorded audio message using Early Media.
At the same time, I’m also trunking with Contact Center solution which doesn’t support Early Media.
Beside asking my ITSP to treat calls consistently or ask Contact Centerto support Early Media, is there a way to configure Asterisk to unify both above error treaments into a single one ?
How can I best deal with error messages passed as Early Media.
Best regards
6 thoughts on - How To Deal With Error Messages Passed As Early Media
Tell the ITSP to give you proper signaling, if they wont then get a new ITSP. I suspect if they can’t handle this correctly, there will be a lot more they’re doing wrong as well. Long term you’ll save yourself a whole lot of bother.
Steve
2016-02-03 15:59 GMT+01:00 Steve Howes:
Yes but I’m afraid that, in this industry, the rule is to pass anything received to the other party.
Steve
In that case I wish you the best of luck. You can’t process audio and turn it into a proper signal. If they don’t send a SIP/ISDN signal then you’re stuffed.
I still maintain the best way is to get the right thing sent to you in the first place – it’s a basic interop requirement that data is consistent (even if it’s not exactly the format what you want)
Steve
For calls that fail, even where early media is played, the call should terminate with a 4xx or 5xx SIP response which to a certain degree correlates to the nature of the actual failure. The SIP error code is delayed until the media playback completes, but should be no different whether or not early media is used (for the same actual failure).
Early media is simply an audio stream for human consumption to explain the failure. There should be no need to attempt to recognize it, unless your ITSP is not terminating the call correctly.
I recently ran some analysis of early media messages found in cellular networks by recording the calls and running it through CMU-Sphinx. There are only a few types of early media messages per network, to cover a raft of failures.
But I always got a SIP error code back as well, the early media I found tended to play for upto 20 secs then drop the call, then you get the error code. It might not be a very descriptive error but its still an error code, and the early media audio message is not always very distinct either. In the GSM networks the GSM failure code is more useful but still seems somewhat randomly assigned by the provider, even including the odd temporary failures.
You are not really worried about what the failure reason is, its the caller who needs to decide – did I misdial, is the number really disconnected, is their phone out of coverage etc, you just need to try your next available network, if the caller hasn’t already hung up after hearing the message
You could possibly examine the audio before you get an answer but then you might get caught by some other system or PBX playing early media before answer that isn’t actually a failure.
If your ITSP is not giving you an error code then you have an issue.
Cheers Duncan
2016-02-03 22:12 GMT+01:00 Duncan:
Yes I agree. In the one capture file I based my analysis on, it stroked me that Asterisk sent downstream a “BYE with Reason: Q.850;cause=16” without any message from upstream ITSP (the one sending RTP early media). I started to read RFC 3960 but I’ve finished it yet.
My next step is have a new test and understand what is happening here.
I observed that Error Message was 20-25s seconds long, in my testing, and was probably longer than that, if played in full length.
My feeling is that my downstream Call center setup should also accept Early Media, not just require SIP error code from upstream.