Hello Olivier,
I have some experience in the operation of a VoIP provider with PSTN
interconnections. I am not an expert on theories or references, but I can
at least provide some information from a practical standpoint. Most of what
I will say is obvious though. It may not be relevant outside of Italy, I
have no experience of other "big" telephone networks, and some of my
comments will for sure make some more knowledgeable people laugh for their
naivety and imprecision. I welcome corrections, I am interested in the
experience of others too.
2018-05-16 16:51 GMT+02:00 Olivier :
> Hello,
>
> Thinking back to my current practices, I would be very curious to share
> here about when should applications such as Congestion, Progress or Ringing
> be used in today's telephony.
>
> I would define today's telephony with:
> - SIP phones
> - Asterisk
> - a SIP trunk to an ITSP
> - fixed or mobile lines reachable through this ITSP
>
>
> 1. When Asterisk receives a SIP call coming from PSTN, is there a time
> frame within which Asterisk must reply something to keep caller from
> canceling the call ? Where does this limit come from ? From SIP RFC ? From
> local regulation bodies ?
>
In my experience, the "100 Trying" automatically released from Asterisk is
enough from stopping retransmissions or making a SIP caller assume your
Asterisk is down. Timeouts in this phase generally are of a couple of
seconds. This use is cited in RFC 3261. From this point on, especially if
you are working with PSTN, giving some kind of real "progress", which means
180 and/or 183. I may have seen some case of some switching equipment
exhibiting timeout behaviour if there is no progress (generally, again, in
some 5-ish seconds), but I think that the human factor here is most
relevant. Most humans (at least the ones I worked with) associate the
complete lack of progress for more than some seconds with a network issue,
and hang up.
> 2. Which SIP signal is required to stop call cancellation in the previous
> case ?
>
As I said, I think that 100 Trying as soon as possible is enough for
protocol, while from the standpoint of a VoIP service provider, minimizing
the "Post-Dial Delay" as much as possible is the best way to make callers
less likely to desist. This means that you should strive to provide a 180
and/or 183 as soon as possible.
>
> 3. When Asterisk receives a call, either from PSTN or from a SIP phone) it
> cannot process (unkown callee, whatever reason, ...), should you stop
> processing with Hangup or Congestion ?
> Hangup application allow for exit code customization, if I'm not mistaken,
> but Congestion exists for a reason.
>
I confess that I do not make use of the Congestion application. The correct
way to indicate inability to process a call depends on the reason why you
cannot process it, and Hangup provides the flexibility needed. I generally
refer to
- Mappings in
- https://wiki.asterisk.org/wiki/display/AST/Hangup+Cause+Mappings
- https://tools.ietf.org/html/rfc3398
- Response codes descriptions from RFC 3261 ยง 21
in deciding which hangup cause to provide to Hangup to ensure SIP and Q.850
compatibility. I enable Q.850 reason support in Asterisk for this kind of
interworking. Some examples may be:
- If Asterisk detected a transient problem, and an immediate retry may
work, Hangup(34) (SIP 503) is good. This is also what Asterisk replies on
graceful shutdown. I think that in this case using Congestion has the same
effect, maybe even better (I expect Congestion to affect the disposition in
CDRs but have not checked).
- If you have an internal error (catch some bug or unexpected situation
from the dialplan or your application), Hangup(38) (SIP 500) is generally
correct.
- The case of an unknown callee you cite is generally Hangup(1) (SIP
404).
And so on. I think you should check the aforementioned references if you
are in need of customizing your responses.
4. Is it a good practise to send a 180/183 when you don't get one ?
>
My opinion is that 180 Ringing indicates that the callee has been alerted
of an incoming call, so it should not be provided improperly. I find
sending a plain 183 with SDP (e.g. using the Progress application) mostly
harmless, and may help with convincing some switching equipment and SIP
Proxy/RTP Proxy combo to "open a media path" without necessarily giving the
caller a "fake" ringback. I generally think that a B2BUA should not
interfere with the progress or media except from when it is required by the
service it provides. This is again my experience in building and working
with media gateways and SIP/PSTN interconnections. From a more practical
approach, again, humans abhor silence, so providing an artificial progress
information when you expect your scenario to have a long PDD may prove
beneficial for your service. In some cases, you even may opt to provide a
"courtesy tone" of some kind with Playtones after Progress to signal the
caller that the
