<div dir="ltr"><div>Hello Olivier,<br><br></div>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.<br><div><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2018-05-16 16:51 GMT+02:00 Olivier <span dir="ltr"><<a href="mailto:oza.4h07@gmail.com" target="_blank">oza.4h07@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hello,<br><br></div>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.<br><br></div>I would define today's telephony with:<br></div>- SIP phones<br></div>- Asterisk<br></div>- a SIP trunk to an ITSP<br></div>- fixed or mobile lines reachable through this ITSP<br><br><br></div>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 ?<br></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>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.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div></div>2. Which SIP signal is required to stop call cancellation in the previous case ?<br></div></div></div></div></div></div></div></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><br></div>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 ?<br></div>Hangup application allow for exit code customization, if I'm not mistaken, but  Congestion exists for a reason.<br></div></div></div></div></div></blockquote><div><br></div><div>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<br><ul><li>Mappings in <br></li><ul><li><a href="https://wiki.asterisk.org/wiki/display/AST/Hangup+Cause+Mappings">https://wiki.asterisk.org/wiki/display/AST/Hangup+Cause+Mappings</a></li><li><a href="https://tools.ietf.org/html/rfc3398">https://tools.ietf.org/html/rfc3398</a></li></ul><li>Response codes descriptions from RFC 3261 § 21<br></li></ul><p>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:</p><ul><li>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).<br></li><li>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.</li><li>The case of an unknown callee you cite is generally Hangup(1) (SIP 404).</li></ul><p>And so on. I think you should check the aforementioned references if you are in need of customizing your responses.</p><p><br></p></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div></div>4. Is it a good practise to send a 180/183 when you don't get one ?<br></div></div></div></div></blockquote><div><br></div><div>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).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div></div>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).<br></div>What explains such difference ?<br></div></div></blockquote><div><br></div><div>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<br><ul><li>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.</li><li>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 <br></li><ul><li>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.</li><li>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.</li><li>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.</li></ul></ul><p>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.<br></p></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div>Best regards<br><div><div><div><div><div><div><div><div><div><br><br><div><div><div><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br>-- <br>
______________________________<wbr>______________________________<wbr>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
Check out the new Asterisk community forum at: <a href="https://community.asterisk.org/" rel="noreferrer" target="_blank">https://community.asterisk.<wbr>org/</a><br>
<br>
New to Asterisk? Start here:<br>
      <a href="https://wiki.asterisk.org/wiki/display/AST/Getting+Started" rel="noreferrer" target="_blank">https://wiki.asterisk.org/<wbr>wiki/display/AST/Getting+<wbr>Started</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-users" rel="noreferrer" target="_blank">http://lists.digium.com/<wbr>mailman/listinfo/asterisk-<wbr>users</a><br></blockquote></div><br></div></div></div></div></div></div></div></div>