[asterisk-users] When should a Progress or Ringing be used in a today's telephony ?
Gianluca Merlo
gianluca.merlo at gmail.com
Wed May 16 16:12:59 CDT 2018
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 <oza.4h07 at gmail.com>:
> 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 call is progressing, but still has not reached the callee
(I think about the behaviour of some common IP phones, which do exactly
this to the user between the reception of 100 Trying and a proper progress
indication).
> 5. I observed I sometimes got a 100 Trying then a 183 session Progress
> when outcalling some (mobile) phones while simpy getting 100 Trying when
> some other (mobile) phone through the same carrier (most probably, end
> devices were not managed by the same (mobile) telephony provider).
> What explains such difference ?
>
I do not have experience with mobile networks per se, so I cannot give a
specific reason. My experience with carrier services and carrier grade PSTN
and VoIP interconnections is that progress handling can be very wildly
variable. If you are interested, my thoughts are
- If you are receiving only 100 Trying, and you provider is not
trustworthy, you may really be in a scenario where you have "pure" (no
inband) signalling all the way to the callee, with minimal interworking,
and the network is simply waiting to reach the callee terminal. In general,
100 Trying will be in any case probabily be supplied by the first hop you
are hitting, to stop retransmissions.
- Additional progress may come in the form of 180/183 with or without
SDP, and generally indicates that the callee terminal is really ringing or
at least has been contacted by the network. From my experience of PSTN
interworking
- 180 without SDP is generally associated with digital ALERTING/ACM
(especially with proper BCI) messages, and is a "pure" (not inband)
signalling typical of cases in which at least digital telephony is
available all the way to the callee.
- 183 or 180 with SDP is associated with digital PROGRESS/CPG
messages and is used to confirm that a media path is open, and to provide
inband progress information. It is not uncommon (Asterisk does it) to
provide 180 w/o SDP + 183 w/ SDP.
- One cannot assume that a pure 180 indication will arrive unchanged
to the caller, or that the caller terminal or access will be able to
provide the ringing tone on such indication (again, we are talking about
non digital networks). Most carrier equipment is not capable of
generating
tones to provide maximum compatibility, so if you are providing carrier
services and would like to signal to a caller that your callee user has
been alerted of the incoming call the safest way is to provide
180 with SDP
*and* inband ringing tone, or 180 without SDP + 183 with SDP and inband
ringing tone.
I think that mobile networks in particular are tricky, mostly because they
have a very rapid evolution and early adoption of modern standards but
still retain compatibility for a broad range of old devices. For example in
Italy fixed telephony is transitioning from SS7 and ISUP to pure SIP, but
still there are analog accesses for users, while mobile networks range from
early 2G to 4+G networks, where I assume you are very near to SIP all the
way.
> Best regards
>
>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at: https://community.asterisk.
> org/
>
> New to Asterisk? Start here:
> https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20180516/efe161b4/attachment.html>
More information about the asterisk-users
mailing list