2 thoughts on - When Should A Progress Or Ringing Be Used In A Today’s Telephony ?

• 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).

  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

  People will complain if there is no indication, so yes IMHO.

  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 :

  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.

  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.

  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).

  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.