Re: [asterisk-users] When should a Progress or Ringing be used in a today's telephony ?

[Gianluca Merlo]

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 

[asterisk-users] Running configure from subdirectory of source tree

[Gianluca Merlo]

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] Running configure from subdirectory of source tree

[Gianluca Merlo]

2014-03-05 20:08 GMT+01:00 Jason Parker jason.par...@schmoozecom.com:

 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
 
 
 


 --
 _
 -- 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

-- 
_
-- 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

[Gianluca Merlo]

Hello James,

Il giorno 26/lug/2013 15:50, James Bensley jwbens...@gmail.com 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

[Gianluca Merlo]

2013/3/14 Puzankin Grigoriy gpuzan...@gmail.com:
 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

[asterisk-users] TON always unknown in RDNIS (outgoing calls)

[Gianluca Merlo]

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

Re: [asterisk-users] TON always unknown in RDNIS (outgoing calls)

[Gianluca Merlo]

2012/10/24 Richard Mudgett rmudg...@digium.com:
 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