asterisk users - May 2018 - When should a Progress or Ringing be used in a today's telephony ?

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 ?

2. Which SIP signal is required to stop call cancellation in the previous
case ?

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.

4. Is it a good practise to send a 180/183 when you don't get one ?

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 ?

Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20180516/1b690fe6/attachment.html>

On Wed, May 16, 2018 at 04:51:49PM +0200, Olivier wrote:
> 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 ?
> 
> 2. Which SIP signal is required to stop call cancellation in the previous
> case ?
See RFC 3261, 17.1.1. A (provisional) response to an INVITE is required
within a timelimit. After a provisional response a non-provisional
response is required. Defaults are on page 264 of the RFC (first to
last).
 
> 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.
With regard to PSTN calls the signalig is limited, but to a SIP device
you could signal usefull information, eg: unknown, temp. unavailable.
Why not give a usefull reason instead of Congestion
> 4. Is it a good practise to send a 180/183 when you don't get one ?
People will complain if there is no indication, so yes IMHO.
> 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 ?
An explanation could be packet loss. But there are no requirements for
1xx responses to an INVITE. Maybe they just don't care about feedback to
callers.

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>