Setup: asterisk 1.8 on CentoOS 5.5
Problem: if I place an outbound call to a disconnected landline number, phone will ring indefinitely or till specified timeout value.
If I call the same number from a regular landline or a cell phone, it will play a specific sound and then a per-recorded message “Number is not in service”.
This is a real life scenario when I was trying to reach someone for 3 days. The person already moved and got his phone disconnected. Co-incidentally, I called him from my cell only to find out that “number is not in service”
asterisk logs:
[Aug 26 13:48:28] VERBOSE[1164] netsock2.c: == Using SIP RTP TOS bits 184
[Aug 26 13:48:28] VERBOSE[1164] netsock2.c: == Using SIP RTP CoS mark 5
[Aug 26 13:48:28] VERBOSE[1164] app_dial.c: -- Called SIP/my_trunk/XXX9964941
[Aug 26 13:48:30] VERBOSE[1164] app_dial.c: -- SIP/my_trunk-00000008 is making progress passing it to Local/XXX9964941@from-internal-561c;2
[Aug 26 13:49:13] VERBOSE[1164] app_macro.c: == Spawn extension (macro-dialout-trunk, s, 20) exited non-zero on 'Local/XXX996494@from-internal-561c;2' in macro 'dialout-trunk'
From the logs, it looks like just waits to connect, but never connects. So why cell phone connects?
Is there a way to identify using maybe a dialplan or AGI script if the number is disconnected or not?
Unfortunately this depends in Your SIP-provider.
If the provider follows all the specs he should give You back a reason 404 or 480. Zhaz means the providfer should route the network-information accordingly over SIP so asterisk would be able to react (with CONGESTION).
Unfortunately a lot of providers operate just in that manner You describing here - no feedback, thus the call simply times out and You know nothing about the reason for this.
Unfortunately there’s nothing You can do except looking for a SIP-provider supporting all the RFCs completely …
I think this is the key here. Rather than giving proper SIP events, the provider has sent
183 Progress
and is then sending information as audio tones and messages.
There was a recent policy change on the handling of Progress by Asterisk, and now, unless you make Asterisk also send Progress upstream, using the Progress application, it won’t forward the in band progress indications. I suspect this is because the only way for a normal user to forward in band progress over a public network is to answer the call, will will start charging for the inbound leg.
Even if using Progress helps, Asterisk is not going to know the actual fate of the call, as that requires a human to listen to the tones and announcements.
Although I say the SIP provider has sent Progress, it may actually be the PSTN network. That’s the only way for a simple analogue network to signal anything but answer.
Thanks for the replies. It is a PSTN number, and indeed they are sending 180 SIP progress along with the early media audio.
I opened a ticket with my VoIP provider and had them debug on their side during the actual call.
Below their official response:
[quote]Please note that our value route is a mix of providers to maintain low cost and therefore there might be no standards. Even when our providers should return the proper sip codes, they might also play early media recordings before doing so, such as “number is not in service”. We pass along the SIP response or early media received by the provider.
What is happening is that our 1st value provider is randomly providing early media 180 SIP progress for this number, until it falls back to our backup carrier which return the proper early media audio with the invalid number error. We have seen that it may take up to two minutes for the first carrier to fall back to our backup carrier.[/quote]
As for ISUP Cause values and corresponding mapped SIP responses, they claiming they did not receive any so they cannot pass it me ?
Considering all of the above, I guess there is nothing could be done?
May be somebody could suggest a better provider that is known to send back ISUP Cause values or at least SIP values mapped to the ISUP Cause values?