Re: [asterisk-users] When should a Progress or Ringing be used in a today's telephony ?
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
Re: [asterisk-users] Running configure from subdirectory of source tree
2014-03-05 20:08 GMT+01:00 Jason Parker : > That's not something that is likely to be supported. Any configure > script in the tree will be run via the top-level build process, as > needed. Hello Jason, I admit I naively have yet to consider whether the actual build could work or not, and assumed (for lack of knowledge) it could. By chance, is yours an assumption or you have personally experienced (or know by understanding its inner workings) that the top level make does not perform correctly if the sources lie elsewhere (in this case, in the parent directory)? Is there some reason you think you need to run the other > configure scripts yourself? > If your question is related to the origin of the need of configuring and building in a subdirectory, I am in need of building custom Debian packages for Asterisk, and my plan was to use a single source package to build several "monolithic" Asterisk binary packages, each with different configure options and patches to modify/add some functionalities (I currently compile and install them manually, and could use some Debian-magic-automation). Debhelper offers a "--builddirectory" option which allows to easily perform such task, and I already successfully used it on more simple software using the autotool build toolchain, but essentially this works as in my "manual" example, thus failing. Thanks in advance for your advice. On 03/05/2014 08:54 AM, Gianluca Merlo wrote: > > Hello everyone, > > > > I would like to seek your advice regarding a build (or rather > > "configure") problem I am running into. For reference, tests are all > > relative to a build from a 1.8.26.0 tarball, on Debian Wheezy. > > > > I would like to understand if it is possible, and if any of you have > > tried, to build Asterisk from a subdirectory of the source tree, i.e., > > from a clean source tree > > > > # mkdir my-build-directory > > # cd my-build-directory > > # ../configure > > # make > > > > I lack a proper amount of knowledge on the matter, but I think that this > > should be "legit" with a common autotools build toolchain. Tests suggest > > that (at least in my case) this is not working with > > > > configure: error: cannot find install-sh, install.sh, or shtool in > > `pwd` ".."/`pwd` > > > > > > Looking in the configure process in detail, the failure seem to follow > > the checks (/bin/sh -x output) > > > > + for ac_dir in '`pwd`' '"$srcdir"/`pwd`' > > + test -f > /home/gian/src/asterisk-1.8.26.0/my-build-directory/install-sh > > + test -f > /home/gian/src/asterisk-1.8.26.0/my-build-directory/install.sh > > + test -f /home/gian/src/asterisk-1.8.26.0/my-build-directory/shtool > > + for ac_dir in '`pwd`' '"$srcdir"/`pwd`' > > + test -f > > ..//home/gian/src/asterisk-1.8.26.0/my-build-directory/install-sh > > + test -f > > ..//home/gian/src/asterisk-1.8.26.0/my-build-directory/install.sh > > + test -f > ..//home/gian/src/asterisk-1.8.26.0/my-build-directory/shtool > > > > > > It looks to me that despite checking "`pwd`" leads to a correct > > behaviour, checking "../`pwd`" is not correct. I seem to understand that > > this behaviour was introduced in configure.ac <http://configure.ac> at > > r259848, by adding > > > > AC_CONFIG_AUX_DIR(`pwd`) > > > > > > The log for the commit reports > > > > > > > r259848 | qwell | 2010-04-28 22:32:14 +0200 (Wed, 28 Apr 2010) | 9 > lines > > > > Merged revisions 259847 via svnmerge from > > https://origsvn.digium.com/svn/asterisk/branches/1.4 > > > > > > r259847 | qwell | 2010-04-28 15:30:21 -0500 (Wed, 28 Apr 2010) | 1 > > line > > > > Add AC_CONFIG_AUX_DIR to configure script, so systems without > > install can use install-sh from our source dir. > > > > > > > > > > > > > > > Isn't the default behaviour for autoconf enough > > (http://www.gnu.org/software/automake/manual/html_node/Optional.html)? > > Can this be considered as a bug in Asterisk's the build system, > > preventing an otherwise working build scenario (i.e. configuring and > > building in a subdirectory of the source tree)? > > > > Thank you in advance for your help > > > > Gianluca > >
[asterisk-users] Running configure from subdirectory of source tree
Hello everyone, I would like to seek your advice regarding a build (or rather "configure") problem I am running into. For reference, tests are all relative to a build from a 1.8.26.0 tarball, on Debian Wheezy. I would like to understand if it is possible, and if any of you have tried, to build Asterisk from a subdirectory of the source tree, i.e., from a clean source tree # mkdir my-build-directory # cd my-build-directory # ../configure # make I lack a proper amount of knowledge on the matter, but I think that this should be "legit" with a common autotools build toolchain. Tests suggest that (at least in my case) this is not working with configure: error: cannot find install-sh, install.sh, or shtool in `pwd` > ".."/`pwd` > Looking in the configure process in detail, the failure seem to follow the checks (/bin/sh -x output) + for ac_dir in '`pwd`' '"$srcdir"/`pwd`' > + test -f /home/gian/src/asterisk-1.8.26.0/my-build-directory/install-sh > + test -f /home/gian/src/asterisk-1.8.26.0/my-build-directory/install.sh > + test -f /home/gian/src/asterisk-1.8.26.0/my-build-directory/shtool > + for ac_dir in '`pwd`' '"$srcdir"/`pwd`' > + test -f ..//home/gian/src/asterisk-1.8.26.0/my-build-directory/install-sh > + test -f ..//home/gian/src/asterisk-1.8.26.0/my-build-directory/install.sh > + test -f ..//home/gian/src/asterisk-1.8.26.0/my-build-directory/shtool It looks to me that despite checking "`pwd`" leads to a correct behaviour, checking "../`pwd`" is not correct. I seem to understand that this behaviour was introduced in configure.ac at r259848, by adding AC_CONFIG_AUX_DIR(`pwd`) > The log for the commit reports > r259848 | qwell | 2010-04-28 22:32:14 +0200 (Wed, 28 Apr 2010) | 9 lines > > Merged revisions 259847 via svnmerge from > https://origsvn.digium.com/svn/asterisk/branches/1.4 > > > r259847 | qwell | 2010-04-28 15:30:21 -0500 (Wed, 28 Apr 2010) | 1 line > > Add AC_CONFIG_AUX_DIR to configure script, so systems without install > can use install-sh from our source dir. > > > > Isn't the default behaviour for autoconf enough ( http://www.gnu.org/software/automake/manual/html_node/Optional.html)? Can this be considered as a bug in Asterisk's the build system, preventing an otherwise working build scenario (i.e. configuring and building in a subdirectory of the source tree)? Thank you in advance for your help Gianluca -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] RTP from pcap file
Hello James, Il giorno 26/lug/2013 15:50, "James Bensley" ha scritto: > > Howdy all, > > Does anyone know of a niffty CLI tool for Linux that can take a PCAP > file that was created on a SIP PBX for example, and then dump the > payload of the various RTP streams in there into seperate files so I > can listen to them? > > I can go this graphically with Wireshark, but I'd like to script it > for automation. > > Cheers, > James. I personally use rtpbreak http://dallachiesa.com/code/rtpbreak/doc/rtpbreak_en.html For similar tasks Gianluca -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI Called Party Number Info
2013/3/14 Puzankin Grigoriy : > Hi, > > I need to get type of called number (TON), which is displayed in pri debug > messages: > > Called Party Number (len=13) [ Ext: 1 TON: National Number (2) NPI: > ISDN/Telephony Numbering Plan (E.164/E.163) (1) 'xx' ] > > Does anyone know how to do it? > > According to documentation it is only possible for calling number. But I > need to make decision in dialplan upon the value of type of called number. > > BTW, I made a little research on source code and could not find anything > related to my question. Perhaps, it's not implemented. > > Best regards, > Grigoriy > > -- > С уважением, > Григорий Пузанкин > > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: > http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users Hello Grigoriy, i think that you can access the information you need by using the dialplan function CALLERID(num-plan). It should contain the lower 7 bits of the Q.931 type-of-number/numbering-plan-identification octet. Best regards Gianluca -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] TON always unknown in RDNIS (outgoing calls)
2012/10/24 Richard Mudgett : > The REDIRECTING(from-num-plan) has both type-of-number and numbering-plan > fields. The value is the lower 7 bits of the Q.931 > type-of-number/numbering-plan-identification octet. So for international > ton and ISDN numbering plan, you would set the value to 17. > > Richard > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > New to Asterisk? Join us for a live introductory webinar every Thurs: >http://www.asterisk.org/hello > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users Thank you Richard, your advice worked perfectly and for sure saved me and my poor skills some "digging". I truly appreciate it. Best regards Gianluca -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] TON always unknown in RDNIS (outgoing calls)
Hello, first of all, this is my first time asking for advice on this mailing list, so I apologize and thank in advance for your help. Also, besides having access to rather advanced equipment, maybe some of the terms I will use will be incorrect or ambiguous. I hope to be able to clarify any doubt you should have about it. I am currently in the process of upgrading a SIP/TDM gateway from Asterisk 1.4.23 to 1.8.17. The gateway is designed to terminate SIP calls via TDM through a switching equipment. Among the features for this gateway there is handling for redirected calls, i.e. populating the outgoing RDNIS with information from custom SIP headers. In the past, (Asterisk 1.4.23, DAHDI 2.6.1, libPRI 1.4.12) this was accomplished by setting CALLERID(RDNIS) and PRIREDIRECTREASON in the dialplan. Tracing on the switching equipment, I noticed that the redirecting party had: - TON as set in DAHDI's prilocaldialplan - NPI ISDN - Presentation indicator always "allowed" - Reason as set in PRIREDIRECTREASON - Redirecting Party Number as set in CALLERID(RDNIS) In the new setup (Asterisk 1.8.17, DAHDI 2.6.1, libPRI 1.4.12) I am instead using: - REDIRECTING(from-num) to set the redirecting party number - REDIRECTING(from-num-plan) to set the NPI (to numeric value 1 - ISDN), because by default it was set to 0 - unknown - REDIRECTING(from-num-pres) to set the Presentation Indicator - REDIRECTING(reason) to set the redirecting reason Everything seems fine, and using the new REDIRECTING function I have also gained control on the Presentation Indicator (which was previously fixed), but the RDNIS seems always to have TON unknown (instead of what specified in prilocaldialplan - international). Is there a specific way to manually set the TON as I did with the NPI, or is there some known issue with this mechanism? Thanks again in advance for your help. Gianluca -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users