Re: [asterisk-dev] Add SIP Header with PJSIP in C module

[Richard Mudgett]

With chan_sip you had to add those headers on the incoming channel.  With
PJSIP you cannot add them to the incoming channel
as you showed.  You MUST add those headers to the outgoing channel for the
outgoing channel to use the headers.

same = n,NoOp(This is the incoming channel which could be
PJSIP/200-)
same = n,Dial(PJSIP/101,10,b(my_predial))
same = n,Hangup()
; This pre-dial handler executes on the outgoing channel which would be
PJSIP/101-
same = n(my_predial),Set(PJSIP_HEADER(add,X-MyHeader)=valuetest)
same = n,Return()

Richard

https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+Application_Dial

On Wed, Oct 21, 2020 at 12:28 PM Benoit Duverger 
wrote:

> Thanks for your quick answer.
>
> I'm not sure to understand how Pre-Dial Handlers can help my module
> written in C. But if I decide to rewrite this module in asterisk language,
> that could help me. For the moment I hope to fix my C module.
>
> A big resume of what this part of my module do is:
> pbx_exec(chan, "SipAddHeader(X-MyHeader:valuetest)");
> pbx_exec(chan, "Dial(SIP/101@trunk-test,10)");
> That works in asterisk 1.8, 11 and probably in asterisk 16 if I use
> chan_sip but SipAddHeader is no longer a valid application in my asterisk
> because I don't load chan_sip.so, just all modules related to PJSIP.
>
> So with PJSIP, I try:
> pbx_builtin_setvar_helper(chan, "PJSIP_HEADER(add,X-MyHeader)",
> "valuetest");
> pbx_exec(chan, "Dial(PJSIP/101@trunk-test,10)");
>
> I didn't have any errors but my header is not added.
>
> Thanks
>
>
> Le mer. 21 oct. 2020 à 12:23, Richard Mudgett  a
> écrit :
>
>> You add headers in a similar way as before.  It is just a matter of
>> adding them to the right channel.
>> You must add them to the outgoing channel for PJSIP.  This can be
>> accomplished by using pre-dial handlers [1][2].
>>
>> Richard
>>
>> [1] https://wiki.asterisk.org/wiki/display/AST/Pre-Dial+Handlers
>> [2]
>> https://www.asterisk.org/dialplan-handler-routines-allow-customization/
>>
>> On Wed, Oct 21, 2020 at 10:49 AM Benoit Duverger 
>> wrote:
>>
>>> Hello,
>>>
>>> We have a module written in C which was developed initially for asterisk
>>> 1.4, modified a few years ago to run in asterisk 1.8 then 11. This module
>>> is used to verify user's limits, route calls etc...
>>> Actually, I try to adapt it to run in asterisk 16, I moved from chan_sip
>>> to PJSIP and I don't know how can I add SIP Headers into the channel. With
>>> chan_sip we used that:
>>> sprintf( cmd, "SipAddHeader(command:%s)", command );
>>> res = astcmd( chan, cmd );
>>> astcmd is a custom function wrapped onto pbx_exec().
>>>
>>> I tried to use pbx_builtin_setvar_helper(), with the function
>>> PJSIP_HEADER() but I didn't see any custom headers in SIP... and no errors,
>>> res = 0.
>>> res = pbx_builtin_setvar_helper(chan, "PJSIP_HEADER(add, X-test)",
>>> "test");
>>>
>>>
>>> How can I use PJSIP_HEADER in a C module ?, which libraries should I
>>> need to import ?
>>>
>>> Thanks
>>>
>>> --
>>>
>>> Benoit
>>> --
>>> _
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> asterisk-dev mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
>
> --
> *Benoit Duverger*
> *Administrateur Systèmes et Réseaux*
> Sysadmin
> T : 514- <(514)%20985-2570>*985-2570* #148
> www.atwtech.com
> 1050 de la Montagne, Suite 400
> Montréal (Québec) H3G 1Y8
> *Avis de confidentialité*
> Le contenu de ce message ainsi que du ou des fichiers qui y sont joints
> est strictement confidentiel et destiné exclusivement à son ou sa
> destinataire. Si vous n’êtes pas cette personne, nous attirons votre
> attention sur le fait qu’il est strictement interdit de copier, de faire
> suivre ou d’utiliser les informations contenues dans ce courriel. Si vous
> l’avez reçu par erreur, nous vous remercions de nous le faire savoir et de
> détruire toute copie de ce message.
>
> *Confidentiality 

Re: [asterisk-dev] Add SIP Header with PJSIP in C module

[Richard Mudgett]

You add headers in a similar way as before.  It is just a matter of adding
them to the right channel.
You must add them to the outgoing channel for PJSIP.  This can be
accomplished by using pre-dial handlers [1][2].

Richard

[1] https://wiki.asterisk.org/wiki/display/AST/Pre-Dial+Handlers
[2] https://www.asterisk.org/dialplan-handler-routines-allow-customization/

On Wed, Oct 21, 2020 at 10:49 AM Benoit Duverger 
wrote:

> Hello,
>
> We have a module written in C which was developed initially for asterisk
> 1.4, modified a few years ago to run in asterisk 1.8 then 11. This module
> is used to verify user's limits, route calls etc...
> Actually, I try to adapt it to run in asterisk 16, I moved from chan_sip
> to PJSIP and I don't know how can I add SIP Headers into the channel. With
> chan_sip we used that:
> sprintf( cmd, "SipAddHeader(command:%s)", command );
> res = astcmd( chan, cmd );
> astcmd is a custom function wrapped onto pbx_exec().
>
> I tried to use pbx_builtin_setvar_helper(), with the function
> PJSIP_HEADER() but I didn't see any custom headers in SIP... and no errors,
> res = 0.
> res = pbx_builtin_setvar_helper(chan, "PJSIP_HEADER(add, X-test)", "test");
>
>
> How can I use PJSIP_HEADER in a C module ?, which libraries should I need
> to import ?
>
> Thanks
>
> --
>
> Benoit
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] AMD

[Richard Mudgett]

On Thu, Jan 30, 2020 at 5:19 PM Kevin Harwell  wrote:

> On Thu, Jan 30, 2020 at 2:58 PM i...@magnussolution.com <
> i...@magnussolution.com> wrote:
>
>> in my country when I dial to a mobile and I not answer the call, the call
>> going to the voicemail, but the audio is executed before the 200OK, on 183
>> early media.
>>
>> so, I need to execute the AMD when I receive the 183, not the 200 OK.
>>
>
> Unfortunately I am unaware of any easy solution.
>
> Something to be aware of if you are not. From what I understand app_dial
> is reading the frames from the channel. Any solution that attempts to also
> read frames from the same channel at the same time is going to run into
> problems. So for instance, you can't execute app_dial and app_amd at the
> same time.
>
> If you wish to inject some kind of audio listening, and detection
> algorithms while dialing you'll have to do that within the confines of the
> dial application. Basically, while app_dial is waiting for the other side
> to answer it's processing frames. When an audio frame is received then that
> is where you'll want to do your detection. Also once answered you'll need
> to continue processing incoming audio frames. Maybe you are already doing
> all of this?
>
> If that's the case then if a hangup occurs app_dial will automatically
> handle what you need since it will detect the hangup and stop reading
> frames, which in turn means audio will not get passed down into your
> detection checks anymore. There is no loop to break out of since the dial
> application is handing that for you (reading of frames, etc.).
>

Frame hooks or audio hooks might help here.  Off hand, I don't know if they
are active at this time but they might make it easier to implement in
another module.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Asterisk 16.x / pjsip TLS] Memory leak with core reload

[Richard Mudgett]

On Thu, Oct 3, 2019 at 3:58 PM Michael Maier  wrote:

> On 03.10.19 at 15:52 Michael Maier wrote:
> > On 02.10.19 at 22:45 Sean Bright wrote:
> >> On 10/2/2019 4:02 PM, Michael Maier wrote:
> >>> I found one more problem regarding the configuration options, provided
> by FreePBX, which should be supported by asterisk.
> >>> I'm referring to the possibility, to add additional options not
> supported by FreePBX using special config files like
> >>> pjsip.registration_custom_post.conf or pjsip.aor_custom_post.conf and
> pjsip.endpoint_custom_post.conf or pjsip.transports_custom_post.conf.
> >>> The last two files are working pretty fine as expected, but the first
> two just don't work.
> >>>
> >>> I'm configuring in pjsip.registration_custom_post.conf for example:
> >>>
> >>> [extName](+)
> >>> key=value
> >>>
> >>> Asterisk reads it (asterisk complains if it doesn't know the key), but
> asterisk doesn't apply the provided value for a known key - it's always the
> default value. That's
> >>> strange, too.
> >>
> >> Please file an issue[1] with a configuration that exhibits this.
> >
> > https://issues.asterisk.org/jira/browse/ASTERISK-28563
>
> Thanks to all clarifying the correct way to configure it with FreePBX:
>
> [extName](+type=registration)
> key=value
>
> eg.
>
> This really works as expected!
>
> I'm now wondering if I missed some documentation about this feature,
> because I searched the whole web and only found others having the same
> problem but never a solution!
>
> I'm sorry for the noise!
>

Actually, you caused the documentation [1] of the functionality to be
improved.  I don't think it
was actually documented anywhere except in the code and the issue that
added the functionality.

Richard

[1] https://wiki.asterisk.org/wiki/display/AST/Adding+to+an+existing+section
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Controlling the flow of connected line info after attended transfer of stasis-controlled channels

[Richard Mudgett]

On Tue, Oct 30, 2018 at 3:26 PM Stephen Davies 
wrote:

>
>
> On Tue, 30 Oct 2018 at 22:20, Stephen Davies 
> wrote:
>
>
>> Could you comment on why the Dial with ,,I doesn't block the connected
>> line update propagating from the called side of the dial back to the
>> calling side.  That is what it should do and that's how the code seems to
>> work.  My impression is that the processing of the REFER seems to
>> propagated the connected line update all the way back through to the
>> original channel despite this flag.
>>
>>
> Ah - my apologies, I see its actually documented:
>
> The option blocks all redirecting updates since they should only happen
>>> before a call is answered. The option only blocks the connected line update
>>> from the initial answer. Connected line updates resulting from call
>>> transfers happen after the application has completed. Better control of
>>> connected line and redirecting information is obtained using the
>>> interception macros.
>>
>>
> So its intended to work the way it works.
>
> So its then important to understand how to use the interception macros or
> some equivalent in the context of ARI.
>

The interception routines should work regardless of the channels being in
ARI or not.  You set the interception channel variables to the dialplan
routine.  The routine will execute when a connected line update passes
through.
https://wiki.asterisk.org/wiki/display/AST/Party+ID+Interception+Macros+and+Routines

You setup the CONNECTED_LINE_SEND_SUB and CONNECTED_LINE_SEND_SUB_ARGS
channel variables as if you were going to call the Gosub application:
same = n,Gosub(${CONNECTED_LINE_SEND_SUB}(${CONNECTED_LINE_SEND_SUB_ARGS})
Which is effectively what Asterisk does to call the interception routine.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Astricon is coming up October 9-11!  Signup is available at: 
https://www.asterisk.org/community/astricon-user-conference

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Controlling the flow of connected line info after attended transfer of stasis-controlled channels

[Richard Mudgett]

On Tue, Oct 30, 2018 at 2:02 PM Stephen Davies 
wrote:

> Hi,
>
> I'm looking to see if I've missed something - if not I think there is an
> ARI limitation worth thinking about.
>
> app_dial offers a flag "I" which is supposed to block propagation of
> connected line updates through the dial bridge.  Is there anything like
> this that I can do when setting up and managing a bridge with ARI?
>
> My problem is like so:  I have an incoming call from an "external" source
> to a DDI.  I want to send that source a Remote-Party-Id containing the DDI
> dialled an a name like "ABC Corp".  And I don't want that to change even
> with subsequent transfers etc.
>
> I've got this working for the initial incoming call.  My problem comes
> when the dialled phone does a transfer - specifically I've need testing
> with attended transfer.
>
> (An attended transfer starts with the transferer initiating an "enquiry
> call".  So two bridges.  On the REFER Asterisk does an attended transfer
> with type "link" and inserts a Local channel pair between the two bridges,
> replacing the two channels to the transferring phone.
>
> At this point Asterisk sends the original caller a connected line update
> saying that "you are now talking to 201 Abu".  And tells the target phone
> "you are now talking to the external caller".
>
> Which is true, no doubt, but in this case I want to block the connected
> line update being sent to the original caller.
>
> Is there any way in the ARI API?  I can't find it.
>
> In related news, I tried to "isolate" my external caller by passing the
> incoming call through a Local channel with the I option on the dial.  To
> create a point where the connected line update with be blocked.  My
> reasoning is then that the Attended transfer can do what it wants to the
> channels in the bridge, but the flag in the dial will isolate the original
> calling channel  My ARI app can directly tinker with the channel if I do
> want to adjust the connected line info - but its 100% under my control.
>
> So I made my dialplan do this:
>
> [Oct 30 17:51:21] VERBOSE[20289][C-0015] pbx.c: Executing
> [2710900@from-drachtio:1] Goto("PJSIP/drachtio-sip1-0045",
> "to-stasis-ariapp,2710900,1") in new stack
> [Oct 30 17:51:21] VERBOSE[20289][C-0015] pbx_builtins.c: Goto
> (to-stasis-ariapp,2710900,1)
> [Oct 30 17:51:21] VERBOSE[20289][C-0015] pbx.c: Executing
> [2710900@to-stasis-ariapp:1] Set("PJSIP/drachtio-sip1-0045",
> "app=ariapp") in new stack
> [Oct 30 17:51:21] VERBOSE[20289][C-0015] pbx.c: Executing
> [2710900@to-stasis-ariapp:2] ExecIf("PJSIP/drachtio-sip1-0045",
> "0?Set(app=ariapp)") in new stack
> [Oct 30 17:51:21] VERBOSE[20289][C-0015] pbx.c: Executing
> [2710900@to-stasis-ariapp:3] Set("PJSIP/drachtio-sip1-0045",
> "direction=inbound") in new stack
> [Oct 30 17:51:21] VERBOSE[20289][C-0015] pbx.c: Executing
> [2710900@to-stasis-ariapp:4] GotoIf("PJSIP/drachtio-sip1-0045",
> "1?to-stasis-ariapp-via-local,2710900,1") in new stack
> [Oct 30 17:51:21] VERBOSE[20289][C-0015] pbx_builtins.c: Goto
> (to-stasis-ariapp-via-local,2710900,1)
> [Oct 30 17:51:21] VERBOSE[20289][C-0015] pbx.c: Executing
> [2710900@to-stasis-ariapp-via-local:1]
> NoOp("PJSIP/drachtio-sip1-0045", "Routing inbound call "0878XX"
> <0878XX> -> 2710900 via Local channel to block connected line
> updates") in new stack
> [Oct 30 17:51:21] VERBOSE[20289][C-0015] pbx.c: Executing
> [2710900@to-stasis-ariapp-via-local:2]
> Dial("PJSIP/drachtio-sip1-0045",
> "Local/2710900@to-stasis-ariapp-inbound/n,,I") in new stack
> [Oct 30 17:51:21] VERBOSE[20289][C-0015] app_dial.c: Called
> Local/2710900@to-stasis-ariapp-inbound/n
> [Oct 30 17:51:21] VERBOSE[20291][C-0015] pbx.c: Executing
> [2710900@to-stasis-ariapp-inbound:1]
> NoOp("Local/2710900@to-stasis-ariapp-inbound-0006;2", "Routing
> inbound call "0878XX" <0878XX> -> 2710900 other side of local
> channel") in new stack
> [Oct 30 17:51:21] VERBOSE[20291][C-0015] pbx.c: Executing
> [2710900@to-stasis-ariapp-inbound:2]
> Stasis("Local/2710900@to-stasis-ariapp-inbound-0006;2",
> "ariapp,"0878XX <0878XX>,2710900,inbound") in new stack
>
> So what's interesting about this is that is does prevent connected line
> updates during the initial setup of the call:
>
> [Oct 30 17:51:24] VERBOSE[20289][C-0015] app_dial.c: Connected line
> update to PJSIP/drachtio-sip1-0045 prevented.
>
> However the attended transfer still results in a connected-line update
> being sent put to the calling channel through the dial into the Local
> channel despite the I flag.
>
> My Asterisk is "Asterisk GIT-master-9189c26M" - which is a master branch
> from shortly before 16 was released.
>
> Thanks for any pointers.
>

Look at
https://gerrit.asterisk.org/#/c/asterisk/+/10286/
which has been recently committed to the current branches and

Re: [asterisk-dev] Codec negotiation when incoming re-INVITE has no SDP (ASTERISK-28036)

[Richard Mudgett]

On Sun, Sep 9, 2018 at 8:23 PM, Daniel Harper  wrote:

> It has been recommended that I bring this up in order to get some
> feedback on ways to move forward regarding this feature "When
> recieving an re-Invite without SDP asterisk can re-offer all available
> codecs supported"
>
> See https://issues.asterisk.org/jira/browse/ASTERISK-28036
>
> I have had a look at the source for res_pjsip_session.c and
> res_pjsip_sdp_rtp.c but I am not sure I have the skillset or knowledge
> to be able to make a patch myself.
>
> I found this in regards to the feature being added to pjsipua
> https://trac.pjsip.org/repos/ticket/1892


For v15+ it looks easier to get the desired behavior.

Looks like in v15+ the res_pjsip_sessions.c:create_local_sdp() function
can be modified to use the configured stream format capabilities when
there is no session->pending_media_state->topology or the topology is empty.

/* We've encountered a situation where we have been told to create a local
SDP but noone has given us any indication
 * of what kind of stream topology they would like. We try to not alter the
current state of the SDP negotiation
 * by using what is currently negotiated. If this is unavailable we fall
back to what is configured on the endpoint.
 */

If there is an active_media_state->topology then we could use that topology
and set the pending_media_state->topology
stream formats to the configured endpoint media formats based on stream
type.

When the session->pending_media_state->topology formats are setup then the
outgoing deferred offer should be correct.

For v13 getting the desired behavior looks to be more difficult to know
when to use the configured
codecs rather than the previously negotiated codecs.

In v13 the same function could also be modified.  Unfortunately, I'm not
seeing a way to know when
to copy the session->endpoint->media.codecs configured capabilities to the
session->req_caps.  If
we knew when to do that the outgoing deferred offer should be correct.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Astricon is coming up October 9-11!  Signup is available at: 
https://www.asterisk.org/community/astricon-user-conference

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Deadlock between transaction and transport

[Richard Mudgett]

On Thu, Jul 12, 2018 at 5:01 PM, Salahuddin Ahmed  wrote:

> Hello,
>
> Recently I have experienced a deadlock situation in Asterisk Version
> 13.20.0. According to our gdb analysis there have 3 suspicious thread(3, 11
> and 44). Thread 44 push a task to taskpool, thread 11 execute that task and
> the thread 3 is a timer event. In thread 11 during a response going to
> transmit a group lock has been acquired. and this thread was locked on this
> point. In Thread 3 while retransmission timer triggered same group lock
> again acquired and try to retransmit response. In this situation asterisk
> was blocked.
>
> Let me explain according to GDB log,
>
> Thread-03:
> #4  0x7f00ba6d9db0 in tsx_send_msg (tsx=0x7eff8bdd4568,
> tdata=0x7eff892ae668) at ../src/pjsip/sip_transaction.c:2122
>
> Thread-11:
> #6  0x7f00ba6dc4ac in pjsip_tsx_send_msg (tsx=tsx@entry=0x7eff8bdd4568,
> tdata=tdata@entry=0x7eff892ae668) at ../src/pjsip/sip_transaction.c:1783
> (gdb) p tsx->transport_flag
> $2 = 1(TSX_HAS_PENDING_TRANSPORT)
>
> Here Thread-03 is execute first and try to retransmit a message before
> acquire a tsx group lock in Thread-11, because in thread 3
> tsx->transport_flag |= TSX_HAS_PENDING_TRANSPORT has been set, Now if we
> read this flag from thread 11 in frame 04 then we have found this flag was
> set by someone before acquiring tsx group lock. That means during this
> acquiring lock in Thread3, Thread 11 trying to send data on transport. So
> this might be the case of deadlock, somehow timer thread 3 execute before
> thread-11.
>
> Here I enclose Thread-3 and Thread-11 gdb backtrace.
>
> Could anyone please help me on this?
>
>
> Thread-11:
> #0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/
> linux/x86_64/lowlevellock.S:135
> #1  0x7f00f62bf494 in _L_lock_952 () from /lib/x86_64-linux-gnu/
> libpthread.so.0
> #2  0x7f00f62bf2f6 in __GI___pthread_mutex_lock (mutex=0x7eff41197c58)
> at ../nptl/pthread_mutex_lock.c:114
> #3  0x7f00b97e49a5 in pj_mutex_lock (mutex=0x7eff41197c58) at
> ../src/pj/os_core_unix.c:1265
> #4  0x7f00b97eace1 in grp_lock_acquire (p=0x7eff41197b48) at
> ../src/pj/lock.c:290
> #5  0x7f00b97ead22 in pj_grp_lock_acquire (grp_lock=)
> at ../src/pj/lock.c:478
> #6  0x7f00ba6dc4ac in pjsip_tsx_send_msg (tsx=tsx@entry=0x7eff8bdd4568,
> tdata=tdata@entry=0x7eff892ae668) at ../src/pjsip/sip_transaction.c:1783
> #7  0x7f00ba6de952 in pjsip_dlg_send_response (dlg=,
> tsx=0x7eff8bdd4568, tdata=tdata@entry=0x7eff892ae668) at
> ../src/pjsip/sip_dialog.c:1531
> #8  0x7f00bab1c09a in pjsip_inv_send_msg (inv=0x7eff88bdf9b8,
> tdata=tdata@entry=0x7eff892ae668) at ../src/pjsip-ua/sip_inv.c:3231
> #9  0x7f0092874b4c in ast_sip_session_send_response
> (session=session@entry=0x7eff89367700, tdata=0x7eff892ae668) at
> res_pjsip_session.c:983
> #10 0x7f002a431841 in answer (data=0x7eff89367700) at chan_pjsip.c:591
> #11 0x7f0094b7a490 in sync_task (data=0x7efdbcf8b810) at
> res_pjsip.c:4268
> #12 0x005d52ce in ast_taskprocessor_execute (tps=tps@entry=0x267f9b0)
> at taskprocessor.c:971
> #13 0x005dcc80 in execute_tasks (data=0x267f9b0) at
> threadpool.c:1322
> #14 0x005d52ce in ast_taskprocessor_execute (tps=0x23e0580) at
> taskprocessor.c:971
> #15 0x005dd558 in threadpool_execute (pool=) at
> threadpool.c:351
> #16 worker_active (worker=) at threadpool.c:1105
> #17 worker_start (arg=0x7f0080001680) at threadpool.c:1024
> #18 0x005e6dfa in dummy_start (data=) at
> utils.c:1238
> #19 0x7f00f62bd064 in start_thread (arg=0x7eff67c9b700) at
> pthread_create.c:309
> #20 0x7f00f55a562d in clone () at ../sysdeps/unix/sysv/linux/
> x86_64/clone.S:111
>
>
> Thread-3:
> #0  sanitize_tdata (tdata=) at res_pjsip/pjsip_message_
> filter.c:211
> #1  filter_on_tx_message (tdata=0x7eff892ae668) at res_pjsip/pjsip_message_
> filter.c:233
> #2  0x7f00ba6c5b0e in endpt_on_tx_msg (endpt=,
> tdata=0x7eff892ae668) at ../src/pjsip/sip_endpoint.c:1088
> #3  0x7f00ba6cc5c0 in pjsip_transport_send (tr=0x2677718,
> tdata=tdata@entry=0x7eff892ae668, addr=addr@entry=0x7eff8bdd4644,
> addr_len=16, token=token@entry=0x7eff8bdd4568,
> cb=cb@entry=0x7f00ba6d91b0 ) at
> ../src/pjsip/sip_transport.c:833
> #4  0x7f00ba6d9db0 in tsx_send_msg (tsx=0x7eff8bdd4568,
> tdata=0x7eff892ae668) at ../src/pjsip/sip_transaction.c:2122
> #5  0x7f00ba6da8da in tsx_on_state_proceeding_uas (tsx=0x7eff8bdd4568,
> event=) at ../src/pjsip/sip_transaction.c:2882
> #6  0x7f00ba6d9b86 in tsx_timer_callback (theap=,
> entry=0x7eff8bdd46e8) at ../src/pjsip/sip_transaction.c:1189
> #7  0x7f00b97f6757 in pj_timer_heap_poll (ht=0x23e53a0,
> next_delay=next_delay@entry=0x7f0090649e50) at ../src/pj/timer.c:644
> #8  0x7f00ba6c65c4 in pjsip_endpt_handle_events2 (endpt=0x23e50b8,
> max_timeout=max_timeout@entry=0x7f0090649ea0, p_count=p_count@entry=0x0)
> at ../src/pjsip/sip_endpoint.c:715
> #9  0x7f00ba6c66d7 in pjsip_endpt_handle_events 

Re: [asterisk-dev] Regarding Unique Id In Logs

[Richard Mudgett]

On Tue, Jul 3, 2018 at 3:49 AM, Balraj Singh 
wrote:

> Thank you for your suggestion, We initially considered only using Call-id
> as unique id to grep the logs. But there were several reason for us not to:
> 1) This Call-Identifier variable gets reset after we shut down asterisk
> and starts again from C-0001.
> 2) We're using CDR and unique-id by default as it is saved in CDR table
> and so we can take unique id from cdr to grep the logs.
> 3) We needed unique-id to be in every log line e.g. executing Dialplan
> applications, sip debug logs, rtp streaming logs, etc. So to achieve this
> customisation, we had to modify logger.c file to easily grep the logs
> related to a call using that id, so that we can trace / debug it if some
> error occurs.
>
> Hence, we had to re-implement this functionality to suffice our needs. So,
> please kindly can you re-verify our approach to this.
>
> On Tue, Jul 3, 2018 at 2:32 AM Richard Mudgett 
> wrote:
>
>> You are trying to reimplement callid[1] which has been in Asterisk since
>> v11.  Callid
>> is accessible from dialplan using CHANNEL(callid)[2].  Accessibility from
>> the
>> dialplan has been in Asterisk 13 since 13.15.0 and in Asterisk 15 since
>> it was first
>> released. The callid is created when the incoming channel goes into
>> dialplan not
>> when it is bridged.
>>
>> As to the approach.  You do know that Asterisk is multi-threaded and can
>> handle
>> more than one call at a time?  Using a simple global variable sets the
>> uniqueid
>> for ALL log messages regardless of whether that message has anything to
>> do with
>> the channel of that uniqueid.
>>
>
Nothing has changed.  It is not a good approach.  Your code assumes that
there is one
and only one call happening at a time.  You have to associate the uniqueid
with EVERY
log message when the log message is posted just like callid does.  This was
why the callid
patch was so large.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Regarding Unique Id In Logs

[Richard Mudgett]

You are trying to reimplement callid[1] which has been in Asterisk since
v11.  Callid
is accessible from dialplan using CHANNEL(callid)[2].  Accessibility from
the
dialplan has been in Asterisk 13 since 13.15.0 and in Asterisk 15 since it
was first
released. The callid is created when the incoming channel goes into
dialplan not
when it is bridged.

As to the approach.  You do know that Asterisk is multi-threaded and can
handle
more than one call at a time?  Using a simple global variable sets the
uniqueid
for ALL log messages regardless of whether that message has anything to do
with
the channel of that uniqueid.

You really should use callid rather than attempt to re-implement this
wheel.  The
callid functionality was a large change to the codebase when it was added
in v11.

Richard

[1] https://wiki.asterisk.org/wiki/display/AST/Call+Identifier+Logging
[2] https://wiki.asterisk.org/wiki/display/AST/Asterisk+15+Function_CHANNEL

On Mon, Jul 2, 2018 at 2:57 PM, Balraj Singh 
wrote:

> Asterisk version : 15.4.1 ( current )
>
> Ok so I added in :
> cdr.h :
>
> extern volatile char* getUniqueId(void);
>
> cdr.c :
>
> //save unique id in this variable
> //this is a global variable
> volatile char *UNIQUEID;
>
> //function to get unique id
> volatile char *getUniqueId() {
> return UNIQUEID;
> }
>
> //start saving unique id from channel
>
> static struct cdr_object *cdr_object_alloc(struct ast_channel_snapshot
> *chan) {
> 
> UNIQUEID = chan->uniqueid;
> 
> }
>
> static struct cdr_object *cdr_object_create_and_append(struct cdr_object
> *cdr) {
> 
> if (!UNIQUEID || (UNIQUEID[0] != '\0')) {
> UNIQUEID = cdr_last->uniqueid;
> }
> 
> }
>
> static struct ast_cdr *cdr_object_create_public_records(struct cdr_object
> *cdr) {
> 
> ast_copy_string(UNIQUEID, party_a->uniqueid, sizeof(party_a->uniqueid));
> 
> }
>
> static void handle_channel_cache_message(void *data, struct
> stasis_subscription *sub, struct stasis_message *message) {
> 
>   UNIQUEID = new_snapshot ? new_snapshot->uniqueid : old_snapshot->
> uniqueid;
> 
> } //end saving unique id
>
> logger.c :
>
> //include cdr header file
> #include "asterisk/cdr.h"
>
> static int format_log_default(struct logchannel *chan, struct logmsg *msg,
> char *buf, size_t size) { char call_identifier_str[13];
>
> //Get unique id from cdr here volatile char *UNIQUEID = getUniqueId(); if
> (msg->callid) { snprintf(call_identifier_str, sizeof(call_identifier_str),
> "[C-%08x]", msg->callid); } else { call_identifier_str[0] = '\0'; } switch
> (chan->type) { case LOGTYPE_SYSLOG:
>
> //Print unique id along with other log content
> snprintf(buf, size, "%s[%d][%s]: %s:%d in %s: %s", levels[msg->level],
> msg->lwp, UNIQUEID, msg->file, msg->line, msg->function, msg->message);
> term_strip(buf, buf, size); break; case LOGTYPE_FILE:
>
> //Print unique id along with other log content
>
> snprintf(buf, size, "[%s] %s[%d][%s] %s: %s",
> msg->date, msg->level_name, msg->lwp, UNIQUEID, msg->file, msg->message);
> term_strip(buf, buf, size); break; case LOGTYPE_CONSOLE: { char
> linestr[32]; /* * Verbose messages are interpreted by console channels in
> their own * special way */ if (msg->level == __LOG_VERBOSE) { return
> logger_add_verbose_magic(msg, buf, size); } /* Turn the numeric line number
> into a string for colorization */ snprintf(linestr, sizeof(linestr), "%d",
> msg->line); snprintf(buf, size, "[%s] " COLORIZE_FMT "[%d][%s]: "
> COLORIZE_FMT ":" COLORIZE_FMT " " COLORIZE_FMT ": %s", msg->date,
> COLORIZE(colors[msg->level], 0, msg->level_name), msg->lwp,
>
> //add unique id here too UNIQUEID,
> COLORIZE(COLOR_BRWHITE, 0, msg->file), COLORIZE(COLOR_BRWHITE, 0,
> linestr), COLORIZE(COLOR_BRWHITE, 0, msg->function), msg->message); }
> break; } return 0; }
>
> void __ast_verbose(const char *file, int line, const char *func, int
> level, const char *fmt, ...) {
> ast_callid callid;
> va_list ap;
>
> callid = ast_read_threadstorage_callid();
>
> va_start(ap, fmt);
>
> //get the unique id
> const char *UNIQUEID = getUniqueId();
> //check if unique id is null or empty and print debug statement accordingly
> if (UNIQUEID) {
> if (UNIQUEID[0] != '\0') {
> printf("[%s]", UNIQUEID);
> } else {
> printf("UNIQUEID IS EMPTY ");
> }
> }
>
> __ast_verbose_ap(file, line, func, level, callid, fmt, ap);
> va_end(ap);
> }
>
>
>
> Thank you.
>
>
>
> On Mon, Jul 2, 2018 at 7:33 PM Tech Support 
> wrote:
>
>> Hello;
>>
>> What version of Asterisk are you using? Do you want to post your
>> modifications to the two files?
>>
>> Thanks;
>>
>> John V.
>>
>>
>>
>> *From:* asterisk-dev [mailto:asterisk-dev-boun...@lists.digium.com] *On
>> Behalf Of *Balraj Singh
>> *Sent:* Monday, July 02, 2018 03:07 AM
>> *To:* asterisk-dev@lists.digium.com
>> *Cc:* Mani Kanta Gadde 
>> *Subject:* [asterisk-dev] Regarding Unique Id In Logs
>>
>>
>>
>> Hi,
>>
>> Problem Statement : How to print $(UNIQUEID) 

Re: [asterisk-dev] Unused channel tech ast_kill_tech ?

[Richard Mudgett]

On Tue, Jun 19, 2018 at 8:42 AM, Jean Aunis  wrote:

> Hello,
>
> Digging through Asterisk's code, I stumbled upon a strange channel
> technology called "ast_kill_tech" (take a look at channel.c / channel.h).
> There is a note stating it is used by Zombie channels, but actually it does
> not seem to be used at all, the technology is not even registered.
>
> Am I missing something obvious, or could this piece of code be safely
> removed ?
>
It is no longer needed.  It was used in v11 for the DTMF attended transfer
when some code was
conditionaled in but is no longer needed since then.  There is a big
comment block in the v11
main/features.c file describing what it used to fix.  Since v12 that issue
no longer exists.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] The "Busy" App.... isn't.

[Richard Mudgett]

On Wed, Apr 4, 2018 at 6:04 PM, Steve Murphy  wrote:

>
>
> On Wed, Apr 4, 2018 at 3:20 PM, Matt Fredrickson 
> wrote:
>
>> On Mon, Apr 2, 2018 at 9:40 PM, Steve Murphy  wrote:
>> > Someone complained about errant behavior of the Busy and Hangup apps...
>> > and I see some strangenesses that might make them credible.
>> >
>> ​
>> >
>> > I cut off the rest of the debug, but the call lasts the full 15  seconds
>> > after busy() is called, and then hangs up. It's interesting to see what
>> the
>> > trunk provider does on top of all this.
>> >
>> > So, my question is: Did I do the best thing? It seems to work, but I
>> have no
>> > idea if I'm creating bugs galore in other usages.
>>
>> There is an assumption (for asterisk C level applications, like
>> Busy()) when using ast_read that if it ever returns NULL that the
>> underlying channel has been hung up and the application should quickly
>> exit.  Busy() is honoring that assumption.  It looks like in
>> sip_indicate() of chan_sip.c, when a AST_CONTROL_BUSY is queued on a
>> SIP channel, it sets the soft hangup flag on the channel.  That's why
>> you're seeing this behavior.  The timeout from Busy() is invalidated
>> if the underlying channel wants to be hung up.
>>
>> I would be highly concerned about breaking that assumption, as you are
>> doing in your proposed patch.  Is there a particular reason you want
>> to keep the call up for 15 seconds before releasing the channel?
>>
>
> ​I was tempted so say:​
>
> ​Mainly for the sake of that "Busy Here" SIP message I'd like to see go
> back to the
> trunk provider. With my patch, it goes out. Without it, nada.
>
> But... incoming calls can come from either of two IP's, and "sip set debug
> ip xx"
> can only monitor one. So, what I thought was happening may not be!
>
> But, really if the Busy app takes an arg, but never honors it... why
> does it take the
> argument at all?
>

The argument is used when the channel is already answered.  The channel
will then send
the busy tone inband for the specified number of seconds and hangup.  The
behavior also
depends upon the channel driver.

exten = _X.,1,NoOp()
same = n,Answer()
same = n,Busy(15)
same = n,Hangup()


Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] ast_monitor_start has no effect.... sometimes

[Richard Mudgett]

On Fri, Mar 23, 2018 at 3:00 PM, Steve Murphy  wrote:

> Hello--
>
> I guess I have a weird situation, in that we use a separate process to
> turn on call recording for a channel. It gets bridge join events via AMI
> and send a StartMonitor action via AMI back to asterisk.
>
> The trouble is, that depending on the machine, the phase of the moon, and
> who knows what else, the request takes longer cometimes, and the
> ast_monitor_start has no effect.
>
> On a good day, the channels are both Locally RTP bridged, and the
> native_rtp technology is started, the res_monitor start comes in and then
> "switching from native_rtp to simple_bridge gets done, I see both channels
> put in a dummy bridge, the native_rtp is stopped, the
> ast_channel_make_compatible_helper chooses ulaw,  and the simple_bridge
> technology is started.
>  I see 3 more messages about "Bridge x is already using the new
> technology (simple_bridge), and I see __ast_read() copying packets into the
> recording files.
>
> On a bad day, I see the channels are both Locally RTP bridged, and the
> native_rtp technology is started. I see the "Bridge x is already using
> the new technology (native_rtp) twice, then the __ast_monitor_start is run,
> and that's it. The packets are forwarded without any __ast_read() calls,
> and no packets are copied to the recording files. (They are in WAV format,
> with only the 60-byte header in the files)
>
> Is there something I need to do to get the bridge into simple_bridge tech
> when we start the monitor?
>

This is a bug with res_monitor.  Please file an issue.

The ast_monitor_start() function needs to check if the channel is in a
bridge after it has set the monitor
structure on the channel and set the unbridged flag to have the bridging
system reevaluate the bridge
technology.

In res_monitor.c:ast_monitor_start():

  ast_channel_monitor_set(chan, monitor);
  ast_monitor_set_state(chan, AST_MONITOR_RUNNING);
+
+ if (ast_channel_is_bridged(chan)) {
+ ast_channel_set_unbridged_nolock(chan, 1);
+ }
+
  /* so we know this call has been monitored in case we need to bill for it
or something */
  pbx_builtin_setvar_helper(chan, "__MONITORED","true");

MixMonitor does not have this problem.  When MinMonitor attaches its
audiohook
existing code that I've added above for Monitor causes the bridge to
reevaluate.

I think a better place is in channel_internal_api.c instead as it will
happen for starting, stopping,
and masquarading channels with monitor:

  void ast_channel_monitor_set(struct ast_channel *chan, struct
ast_channel_monitor *value)
  {
  chan->monitor = value;
+ if (ast_channel_internal_bridge(chan)) {
+ast_channel_set_unbridged_nolock(chan, 1);
+ }
  }


Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] timeval.tv_sec is time_t. How to print/scan?

[Richard Mudgett]

On Sat, Feb 17, 2018 at 5:58 AM, Alexander Traud 
wrote:

> While compiling Asterisk on OpenBSD, I get a lot of warnings about the
> usage of data-type time_t, when used in combination with printf/scanf,
> for example in the file res_http_media_cache.c:
>
> struct timeval actual_expires = ast_tvnow(); // gettimeofday(, NULL);
> snprintf(time_buf, sizeof(time_buf), "%30lu", actual_expires.tv_sec);
>
> On the Internet, there are a lot of suggestions, like
> . Which approach does the Asterisk
> team prefer? Or should I create a new issue report with all findings so
> that somebody else can look into each of those?
>

As that link shows there is no good way to do it.  You just have to settle
for
a portable enough way.  Nor is there an "official" Asterisk way.  You
probably
could search the Asterisk code and find an example of all those
suggestions.
Usually, I have just cast the value to match an appropriate printf format
specifier
to head off nuisance compiler messages.  However, even with the casts I
just
saw on another related stackoverflow page some compilers are stupid enough
to
still complain.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Problems with the ASTERISK-27206 patch.

[Richard Mudgett]

On Wed, Jan 3, 2018 at 5:08 AM, Joshua Colp <jc...@digium.com> wrote:

> On Wed, Jan 3, 2018, at 12:03 AM, Richard Mudgett wrote:
> > On Tue, Jan 2, 2018 at 5:41 PM, Joshua Colp <jc...@digium.com> wrote:
> >
> > > On Tue, Jan 2, 2018, at 7:14 PM, Richard Mudgett wrote:
> > > > The patch for https://issues.asterisk.org/jira/browse/ASTERISK-27206
> > > which
> > > > is committed in 7385d1e017e562afe64431606e857e704f86a16d causes a
> > > > configuration regression by requiring the endpoint and identifier
> method
> > > > to agree to match the endpoint.  Doing so is redundant for methods
> that
> > > > explicitly specify which endpoints they match.  The redundancy allows
> > > > configuration errors that cannot be caught when the configuration is
> > > > loaded.
> > >
> > > Can you clarify what the precise regression you are referring to is?
> Even
> > > after reading this email I'm still unclear.
> > >
> >
> > The regression is the new requirement for the endpoint identify_by option
> > to list ip in order for
> > the type=identify method to be accepted by the endpoint.  This new
> > requirement is unnecessary
> > as the type=identify section must specify an endpoint name to know which
> > endpoint it recognizes.
> >
> > More specifically, the change to
> > res/res_pjsip_endpoint_identifier_ip.c:ip_identify() enforces this
> > new requirement.
> >
> > I should have used the term complexity instead of redundancy.
> >
> > The new requirement adds configuration complexity because the endpoint
> > identify_by option and
> > the type=identify method must agree to match the endpoint.  The added
> > complexity doesn't add any
> > value, can needlessly break existing installations regardless of the note
> > in CHANGES saying it will,
> > makes match by ip configuration more error prone, and the error is not
> > recognizable on configuration
> > load.
> >
> > In addition, as I pointed out, I think the entire ASTERISK-27206 patch
> was
> > unnecessary.  Before
> > the patch, setting the identify_by option to an empty string would
> disable
> > the username
> > identification method from matching the endpoint.
>
> I disagree that those are a regression. Those are certainly valid findings
> and comments, but I don't see a specific regression based on what you've
> said. If you are trying to state that the regression is "we now require ip
> to be listed in identify_by in order to match using the IP endpoint
> identifier" then that was the purpose of the patch itself and is not a
> regression. I also don't think that the option to set it to an empty string
> would have been user friendly, that's more of a side effect of how it was
> coded. Having a specific option for IP only based matching is explicit.
>

I accept that defining the identify_by option to list the methods the
endpoint should be identified by is easy to document and conceptually
simple.  To comply with that definition, for now, we can just add the "ip"
value, the "header" value, and any other widget name down the road as
needed.  Later we need to re-implement it to support dynamically added
widget names.  I do not accept the unnecessary requirement that the
type=identify method must be listed in the identify_by value when the user
must explicitly specify the endpoint name for the type=identify method to
even work.  The "ip" value in identify_by should just be documentation in
this case.  Adding a needless source of configuration error by requiring
the "ip" value to be listed does not help the user experience at all.  That
requirement is the regression.

The ASTERISK-27206 reporter's problem was to somehow stop the username
identification method from recognizing the endpoint.  Setting the
identify_by value to something that does not include "username" is all that
is necessary.  Adding the requirement that the type=identify method be
listed in the identify_by value to accept a match from the type=identify
method goes too far.  It goes into the negative user experience realm.

>
>
> Having a non-explicit option like you mentioned previously for identify_by
> becomes a free for all on the other endpoint identifiers. If we encounter a
> scenario where two "other" endpoint identifiers could match but only want
> to match one then boom - we're back to the same scenario. You've just
> enforced that two endpoint identifiers that are configurable in some way
> can never match the same request even if for some reason they did if they
> fall under the "other" option. If the answer

Re: [asterisk-dev] Problems with the ASTERISK-27206 patch.

[Richard Mudgett]

On Tue, Jan 2, 2018 at 5:41 PM, Joshua Colp <jc...@digium.com> wrote:

> On Tue, Jan 2, 2018, at 7:14 PM, Richard Mudgett wrote:
> > The patch for https://issues.asterisk.org/jira/browse/ASTERISK-27206
> which
> > is committed in 7385d1e017e562afe64431606e857e704f86a16d causes a
> > configuration regression by requiring the endpoint and identifier method
> > to agree to match the endpoint.  Doing so is redundant for methods that
> > explicitly specify which endpoints they match.  The redundancy allows
> > configuration errors that cannot be caught when the configuration is
> > loaded.
>
> Can you clarify what the precise regression you are referring to is? Even
> after reading this email I'm still unclear.
>

The regression is the new requirement for the endpoint identify_by option
to list ip in order for
the type=identify method to be accepted by the endpoint.  This new
requirement is unnecessary
as the type=identify section must specify an endpoint name to know which
endpoint it recognizes.

More specifically, the change to
res/res_pjsip_endpoint_identifier_ip.c:ip_identify() enforces this
new requirement.

I should have used the term complexity instead of redundancy.

The new requirement adds configuration complexity because the endpoint
identify_by option and
the type=identify method must agree to match the endpoint.  The added
complexity doesn't add any
value, can needlessly break existing installations regardless of the note
in CHANGES saying it will,
makes match by ip configuration more error prone, and the error is not
recognizable on configuration
load.

In addition, as I pointed out, I think the entire ASTERISK-27206 patch was
unnecessary.  Before
the patch, setting the identify_by option to an empty string would disable
the username
identification method from matching the endpoint.


>
> >
> > Relevant endpoint 101 configuration values:
> >
> > [global]
> > ; The order by which endpoint identifier methods are given priority.
> > ; The endpoint_identifier_order default is
> > ;endpoint_identifier_order=ip,username,anonymous
> >
> > [101]
> > type=endpoint
> > ; The identify_by default is
> > ;identify_by=username
> >
> > [identify_me]
> > type=identify
> > endpoint=101
> > ; Match by some IP address
> > match=127.0.0.1/24
> >
> > Before the patch, the 101 endpoint above would identify by either the
> > username endpoint identifier method or the
> > res_pjsip_endpoint_identifier_ip endpoint identifier method's
> > [identify_me] section.
> >
> > After the patch, the 101 endpoint is still matched by either method.
> > However, the identify_by default had to change to "username,ip" and the
> > option meaning had to change slightly do it.  I think this is wrong.  If
> > you went to the trouble to create an [identify_me] section which must
> > explicitly specify the endpoint it matches then the endpoint should not
> > need to also specify in the identify_by value that it is identified by
> the
> > res_pjsip_endpoint_identifier_ip method.  Doing so is redundant and will
> > cause unnecessary configuration errors.
>
> I think removing the redundant requirement is a nice improvement for the
> future, but that comes at a cost to do it in a way that is user friendly
> and automatic.
>
> > The goal of ASTERISK-27206 is to prevent the endpoint from being
> > identified by the username identification method so it could only be
> > identified by the res_pjsip_endpoint_identifier_ip method.  The key
> > difference between the two methods is the username identification method
> > has no other configuration than the endpoint's identify_by value
> available
> > to specify to which endpoint the method applies.
> >
> > I think the previous and current identify_by documentation is a bit
> > misleading in any case.  The identify_by option historically specified
> > which identification methods that have no other configuration
> requirements
> > can match the endpoint.  i.e., The username and auth_username
> > identification methods.  To satisfy ASTERISK-27206, what is needed for
> the
> > identify_by option is a value to prevent methods that have no other
> > configuration requirements from matching the endpoint.
>
> The identify_by option was originally an option which listed the endpoint
> identifiers that an endpoint could be identified by. That was its original
> goal. It later evolved slightly with the addition of auth_username to also
> influence how. The addition of "ip" goes back to its original goal. Over
> all the option has muddied meaning.
>

Listing how an endpoint is to be identified may have be

[asterisk-dev] Problems with the ASTERISK-27206 patch.

[Richard Mudgett]

The patch for https://issues.asterisk.org/jira/browse/ASTERISK-27206 which
is committed in 7385d1e017e562afe64431606e857e704f86a16d causes a
configuration regression by requiring the endpoint and identifier method
to agree to match the endpoint.  Doing so is redundant for methods that
explicitly specify which endpoints they match.  The redundancy allows
configuration errors that cannot be caught when the configuration is
loaded.

Relevant endpoint 101 configuration values:

[global]
; The order by which endpoint identifier methods are given priority.
; The endpoint_identifier_order default is
;endpoint_identifier_order=ip,username,anonymous

[101]
type=endpoint
; The identify_by default is
;identify_by=username

[identify_me]
type=identify
endpoint=101
; Match by some IP address
match=127.0.0.1/24

Before the patch, the 101 endpoint above would identify by either the
username endpoint identifier method or the
res_pjsip_endpoint_identifier_ip endpoint identifier method's
[identify_me] section.

After the patch, the 101 endpoint is still matched by either method.
However, the identify_by default had to change to "username,ip" and the
option meaning had to change slightly do it.  I think this is wrong.  If
you went to the trouble to create an [identify_me] section which must
explicitly specify the endpoint it matches then the endpoint should not
need to also specify in the identify_by value that it is identified by the
res_pjsip_endpoint_identifier_ip method.  Doing so is redundant and will
cause unnecessary configuration errors.

The goal of ASTERISK-27206 is to prevent the endpoint from being
identified by the username identification method so it could only be
identified by the res_pjsip_endpoint_identifier_ip method.  The key
difference between the two methods is the username identification method
has no other configuration than the endpoint's identify_by value available
to specify to which endpoint the method applies.

I think the previous and current identify_by documentation is a bit
misleading in any case.  The identify_by option historically specified
which identification methods that have no other configuration requirements
can match the endpoint.  i.e., The username and auth_username
identification methods.  To satisfy ASTERISK-27206, what is needed for the
identify_by option is a value to prevent methods that have no other
configuration requirements from matching the endpoint.

Proposed candidates for the new identify_by value are: "", "none", and
"other".  The "" or "none" value to indicate that none of the methods
without configuration will match.  The "other" value to indicate that the
endpoint is matched by only other matching mechanisms with their own
configuration.

Looking at the some some more, I think the empty value "" is already
allowable in the pjsip.conf file so the entire patch for ASTERISK-27206
would not be needed.  You could have configured identify_by to an empty
value and it would have satisfied the issue.  However, I think database
backends would have an issue with an empty value since the column is
declared as an enum while the code works with it as a string of comma
separated enum values.

Fortunately, the first ASTERISK-27206 patch hasn't come out in a release
yet.  However, it is currently in the 13.19.0-rc1 version.  As a result,
we may have to keep the "ip" value that the first ASTERISK-27206 patch
added to indicate_by as an alias and fix the database column definition.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 13.17.1 Crash on ConfBridge - NetGen ATA

[Richard Mudgett]

On Tue, Dec 19, 2017 at 1:45 PM, Bryant Zimmerman 
wrote:

> We are having an issue with asterisk 13.17.1 dumping when a call from a
> NetGen Smart ATA drops into a confbridge
> The call props up and then things just go wrong. I have talked with the
> support guys at NetGen and they have requested I work start with the
> asterisk dev group so we can figure out what is causing this issue and why
> asterisk is dumping. They are willing to fix anything from their end but we
> have not been able to figure out what in their rtp stream is triggering
> this.  Their ATA's seem to work out side of the confbridge without issues
> so far. Any ideas are appreciated. The asterisk dump is by far my biggest
> concern.
>
> Below is the first part of the dump Backtrack. I have attached a copy of
> the complete Backtrack. I need to know what more would be needed to get to
> the bottom of this issue. As it stands now the NetGen Smart ATA will cause
> asterisk 13 to crash if placed into a confbridge.  http://www.
> netgencommunications.com/
> The support guy said we could contact them at
> supp...@netgencommunications.com
>
>-- Executing [s@Core_ConfBridge_Basic:11] 
> ConfBridge("PJSIP/6162480909.351-",
> "6162480909.~Promo~GA1,,,sample_user_menu") in new stack
>> 0x7f3ff800b4c0 -- Probation passed - setting RTP source address
> to 192.168.209.194:10020
> -- Channel CBAnn/6162480909.~Promo~GA1-;2 joined 'softmix'
> base-bridge <4a00cdad-91cb-4924-8abe-8dc9cad08f10>
> --  Playing 'conf-onlyperson.ulaw'
> (language 'en')
> UBNTU-ROSSI-GUEST*CLI> *** Error in `/usr/sbin/asterisk': malloc(): memory
> corruption: 0x7f3fac00c220 ***
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f402147b7e5]
> /lib/x86_64-linux-gnu/libc.so.6(+0x8213e)[0x7f402148613e]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7f4021488184]
> /usr/sbin/asterisk(ast_json_malloc+0xa)[0x52a23a]
> /usr/lib/x86_64-linux-gnu/libjansson.so.4(json_object+0xb)[0x7f40227ab7bb]
> /usr/lib/x86_64-linux-gnu/libjansson.so.4(+0x6505)[0x7f40227aa505]
> /usr/lib/x86_64-linux-gnu/libjansson.so.4(json_vpack_ex+
> 0x99)[0x7f40227aaa09]
> /usr/sbin/asterisk(ast_json_vpack+0x34)[0x52b6a4]
> /usr/sbin/asterisk(ast_json_pack+0xa1)[0x52b7c1]
> /usr/lib/asterisk/modules/res_rtp_asterisk.so(+0x10df3)[0x7f3f90994df3]
> /usr/lib/asterisk/modules/res_rtp_asterisk.so(+0x11a99)[0x7f3f90995a99]
> /usr/lib/asterisk/modules/res_rtp_asterisk.so(+0x13bcb)[0x7f3f90997bcb]
> /usr/sbin/asterisk(ast_rtp_instance_read+0x36)[0x588076]
> /usr/lib/asterisk/modules/chan_pjsip.so(+0x8cd7)[0x7f3f7c57ccd7]
> /usr/sbin/asterisk[0x4bc042]
> /usr/sbin/asterisk[0x50f3f1]
> /usr/sbin/asterisk(ast_stream_and_wait+0x56)[0x511bbe]
> /usr/lib/asterisk/modules/app_confbridge.so(+0xb716)[0x7f3f915d7716]
> /usr/lib/asterisk/modules/app_confbridge.so(+0xd5f6)[0x7f3f915d95f6]
> /usr/sbin/asterisk(pbx_exec+0xbd)[0x579155]
> /usr/sbin/asterisk[0x56e0c3]
> /usr/sbin/asterisk(ast_spawn_extension+0x18)[0x56feb8]
> /usr/lib/asterisk/modules/app_macro.so(+0x2c02)[0x7f3f6f8a6c02]
> /usr/sbin/asterisk(pbx_exec+0xbd)[0x579155]
> /usr/sbin/asterisk[0x56e0c3]
> /usr/sbin/asterisk[0x5703d1]
> /usr/sbin/asterisk[0x57190b]
> /usr/sbin/asterisk[0x5e45fd]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7f4021f436ba]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f402150b3dd]
>

Your backtrace has no symbols.  However it looks like this security issue
https://issues.asterisk.org/jira/browse/ASTERISK-27429 dealing with RTCP
that was
just released on November 30 in v13.18.4.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] bridge_builtin_features.c playback to both channels in bridge

[Richard Mudgett]

On Mon, Nov 20, 2017 at 7:03 AM, Steve Davies  wrote:

> Hi,
>
> Perhaps the answer to this will be pointing me at some documentation -
> That is fine, but I've failed to find it so far, so forgive me if the
> following is a dumb question.
>
> With Asterisk-11 I added a built-in feature which allowed a very
> customised version of stopping call recording on a bridge, playing back
> different messages to each channel, and so forth based on some channel
> variables, and depending whether the feature was enabled per channel.
>
> I want to port this to Asterisk-15, but am struggling to understand the
> new bridge playback methods. I variously see 
> ast_bridge_channel_queue_playfile(),
> ast_bridge_channel_write_playfile(), or even one followed by the other.
>
> What I'd like to do is queue playback message(s) to both halves of a
> bridge simultaneously so that the bridge will resume once all messages on
> both channels are complete.
>
> An a first read-through, I was fairly convinced that I would be able to
> just call ast_bridge_channel_queue_playfile() as many times as needed on
> both the bridge, and peer channels, and magic would happen, until I saw the
> code in bridges/bridge_builtin_features.c: start_automixmonitor(), after
> which I became most confused :)
>
> Help please?
>

Reaching across the bridge is not allowed.  A channel in a bridge is not
supposed to know
who it is exchanging frames with because the channel could be exchanging
frames with zero
or more other channels at any given time.  Over time, the participant
channels in the bridge
could change.  Channels could be added, removed, or swapped with other
channels in the bridge.

ast_bridge_channel_queue_playfile() - This function queues the playfile
onto the channel itself
for the channel to play the file.

ast_bridge_channel_write_playfile() - This function puts the playfile
request into the bridge for
the other channels in the bridge to play the file.  The bridge handles
distributing the request to
all other channels in the bridge according to the bridge technology.

More information can be found here [1].

Richard

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Bridging+Project
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Where is pjsip_evsub_set_uas_timeout?

[Richard Mudgett]

On Mon, Nov 6, 2017 at 6:00 AM, Alexander Traud 
wrote:

> > An earlier approach was to add support for setting pjproject's timer
> > (via a pjproject patch) and while that patch is still included here,
> > we don't use that call at the moment."
>
> OK, and what do we do with this code now?
> I am not used to leverage a version-controlled source code as pastebin or
> to keep dead code. Remove it? If not, it should at least work – configure
> is not able to find/match that feature at the moment. Remove or repair?
>

That patch was submitted upstream and committed to the pjproject.  However,
the function
name got changed slightly from pjsip_evsub_set_uas_timeout() to
pjsip_evsub_uas_set_timeout() when Teluu merged it into pjproject.
Asterisk never had a
commit that actually used the function so it does not matter.  Asterisk's
bundled pjproject
is currently 2.7.1 on the released branches and does not include the broken
patch anymore.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] ASTERISK-27147 - prune_on_boot - ps_contacts - Sanity Check

[Richard Mudgett]

On Tue, Aug 15, 2017 at 4:50 AM, Ross Beer  wrote:

> Hi Richard,
>
>
> Can I run something past you regarding the 'prue_on_boot' logic, please?
>
>
> If multiple asterisk servers are using the ps_contacts database table,
> does the removal logic check the 'reg_server' before removing the contact
> on boot?
>
>
> I am concerned that valid contacts on other asterisk instances may be
> removed incorrectly.
>
No it currently only checks if the prune_on_boot flag is set before
deleting the contact.  I'll make it also check the reg_server for a match
before deleting the contact if the prune_on_boot flag is set.

Thanks for pointing that out.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Feature discussion: extract REFER headers into dialplan.

[Richard Mudgett]

On Thu, Jul 27, 2017 at 10:31 PM, Kirill Katsnelson 
wrote:

> There were users asking for this feature for as long as I have been using
> Asterisk, albeit the requests are infrequent. Basically, when the
> transferrer initiates transfer with a SIP REFER message, we want access to
> some interesting (normally additional) headers in this message from the
> dialplan.
>
> I currently have an implementation that extracts headers into the parent
> channel's dialplan hash with the fixed name TRANSFER_DATA. Header name
> becomes the key, value the data under this key. Duplicate header names not
> supported (later in the message wins its spot in the hash). This part looks
> good to me. I am dismissing any need to support duplicates, as probably
> there is about 0 users in the world who would want that.
>
> I want to submit a patch for this feature. What I do not know, is the best
> way to specify which headers the user wants in the hash. In my current
> code, the parent channel than wants the data sets a variable
> TRANSFER_SIPHEADER_PREFIX to the prefix matching the interesting header
> names. In my case the prefix is "X-" for all "extended" headers. I imagine
> other users may want to set that to a specific name (e. g.
> "X-Altitude-Data", see https://community.asterisk.org
> /t/how-to-send-variable-information-via-sip-header/70178/7). If not set,
> no headers are put in the hash (unchanged behavior).
>
> I am not sure if this is a good approach. I would appreciate suggestions
> to make the interface as good as it should be. Basically, what I am
> undecided on is:
>
> 1. Is variable a good way to specify the headers? I cannot find a place to
> document it. Options here: a setting in sip.conf (inflexible); a function
> that sets the variable (better, self-documenting).
>

The variable approach that you have implemented in the gerrit review (
https://gerrit.asterisk.org/#/c/6118/ ) is a good way and certainly the
easier way.  You are able to build on existing functionality rather than
having to create a lot of support infrastructure if you tried to go the
dialplan function route.  Another thought arguing in favor of channel
variables is that the channel being blind transferred by the REFER is not
necessarily a SIP channel.

As to documentation, you would need to add a section in sip.conf.sample to
describe the functionality as it is currently chan_sip specific.  If you
add support for the functionality in chan_pjsip/res_pjsip then it would
need documentation in the pjsip.conf.sample file.


>
> 2. Is prefix a good way to specify the pattern? Options: regex (more
> flexible but computationally expensive); wildcards (but we have no
> functions to readily support them).
>

Again I think the prefix approach is good enough.  Using a regex is
somewhat overkill and you would have to build more support infrastructure.
However, I think that an empty prefix string value to match all headers has
a subtle problem.  It can conceivably get confused with the variable not
existing and you cannot disable the feature once it is enabled on the
channel.  I suggest using an asterisk '*' as the match any header value
instead so an empty or non-existing variable can mean the feature is
disabled.


>
> Somewhat related to the question 2, another thing I want to add as we are
> at it is function SIP_HEADERS([pattern]) to complement SIP_HEADER(), that
> would return an array of header names matching the pattern from the
> incoming INVITE. Whether the function itself a matter of additional
> discussion or not, I want the syntax of the pattern be same in both places,
> so this is a related part.
>

The SIP_HEADERS function is very useful to find out what headers were
included in the INVITE.  To extend the concept to other areas,
PJSIP_HEADERS and MESSAGE_DATA_HEADERS functions would be just as useful
for the same reason and get core support.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Updating call limits

[Richard Mudgett]

On Fri, Jun 16, 2017 at 9:29 AM, Kaloyan Kovachev <kkovac...@varna.net>
wrote:

> Thank You for the answer!
> The caller's channel is enough for me, so it
> Just one more question when i walk trough the heap should i remove and
> re-add the ast_bridge_hook_timer(s) or it is enough to update their values
> in place:
>
> ast_heap_wrlock(features->interval_hooks);
> for (idx = ast_heap_size(features->interval_hooks); idx; --idx) {
> struct ast_bridge_hook hook;
>
> hook = ast_heap_peek(hooks, idx);
> if ( hook->type == AST_BRIDGE_HOOK_TYPE_TIMER ) {
> // bridge_features_limits_copy -> remove -> modify ->
> re-add
> // or update in place ?
> }
> }
> ast_heap_unlock(features->interval_hooks);


It is a priority heap of next to expire timers.  Simply changing a hook's
timeout isn't enough.
You will have to remove it and re-add it to the heap.  Otherwise you are
likely to corrupt the
heap.

Richard


>
>
>
> На 2017-06-14 01:01, Richard Mudgett написа:
>
> On Mon, Jun 12, 2017 at 8:10 AM, Kaloyan Kovachev <kkovac...@varna.net>
>> wrote:
>>
>> Hi,
>>> I need to update the call limit of an active call, but the old method of
>>> updating "struct ast_bridge_config" is not working anymore.
>>> The fields 'timelimit', 'play_warning' and 'warning_freq' are used just
>>> to populate the new interval hook and 'nexteventts' is completely unused
>>> (and probably should be removed in trunk).
>>>
>>> What is the right way to update the call limit (and related warning
>>> time) - modify duration and warning inside ast_bridge_features_limits?
>>> And the second question is how to get access to the relevant
>>> structures/data are there any builtin functions to access them?
>>>
>>
>> The new method wasn't designed for dynamic changes to the limit times.
>> Since
>> there was no way for a user to dynamically change them before, it was not
>> a
>> requirement that the new method be able to do so either.  The old way
>> simply
>> checked each limit timer for every frame that passed through a straight
>> forward
>> two party bridge loop.  The new way is more complicated because of the new
>> bridging architecture.  The new bridging architecture does not allow
>> direct
>> access to other channels in the bridge.  A bridge can change from a
>> simple two
>> party bridge to a multi-party bridge at any time because each channel has
>> its
>> own caretaker thread and can be moved easily from bridge to bridge.
>>
>> You cannot simply modify the duration, warning, and frequency values in
>> the
>> ast_bridge_features_limits structure dynamically as you mention either.
>> Those
>> values are only used to construct up to three interval hooks by
>> bridge_builtin_interval_features.c:bridge_builtin_set_limits().  It is
>> those interval
>> hooks that actually control the timing.  The interval hooks are put into
>> a priority
>> heap where the next to expire hook timer is at the top of the heap.  The
>> bridge
>> channel thread then waits for either the next interval hook timer to
>> expire or a
>> frame to arrive.  The other change with the new way is that each channel
>> gets
>> its own interval timers with limits set depending upon if it is the chan
>> or peer
>> channel in the initial two party bridge.  Each channel then acts
>> independently
>> on its own interval timers. There is currently no API call to allow
>> access-to or changing-of the interval hook
>> timers once they are set.  It won't be easy to gain access to the
>> necessary
>> interval hook structures on both channels either.  You can get close to
>> locating
>> the needed interval hooks by following this chain: with an ast_channel
>> pointer use
>> ast_channel_internal_bridge_channel() to get the associated
>> ast_bridge_channel
>> pointer.  With the ast_bridge_channel pointer dereference the features
>> member
>> which you then have access to the interval_hooks member.  The
>> interval_hooks
>> heap is a heap of struct ast_bridge_hook_timer pointers.  However, the
>> interval_hooks heap is not searchable for specific hooks and following
>> the chain
>> may be hazardous because of all the links that need to be followed.  You
>> will
>> definitely need to hold the channel lock to get the ast_bridge_channel
>> pointer.
>> Also the locking order to keep in mind is: ast_bridge locks
>> ast_bridge_channel
>> locks ast_channel.  Locking against this order requires deadlock
>> avoidance.
>>
>> Richard
>>
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Updating call limits

[Richard Mudgett]

On Mon, Jun 12, 2017 at 8:10 AM, Kaloyan Kovachev 
wrote:

> Hi,
>  I need to update the call limit of an active call, but the old method of
> updating "struct ast_bridge_config" is not working anymore.
>  The fields 'timelimit', 'play_warning' and 'warning_freq' are used just
> to populate the new interval hook and 'nexteventts' is completely unused
> (and probably should be removed in trunk).
>
>  What is the right way to update the call limit (and related warning time)
> - modify duration and warning inside ast_bridge_features_limits?
>  And the second question is how to get access to the relevant
> structures/data are there any builtin functions to access them?
>

The new method wasn't designed for dynamic changes to the limit times.
Since
there was no way for a user to dynamically change them before, it was not a
requirement that the new method be able to do so either.  The old way simply
checked each limit timer for every frame that passed through a straight
forward
two party bridge loop.  The new way is more complicated because of the new
bridging architecture.  The new bridging architecture does not allow direct
access to other channels in the bridge.  A bridge can change from a simple
two
party bridge to a multi-party bridge at any time because each channel has
its
own caretaker thread and can be moved easily from bridge to bridge.

You cannot simply modify the duration, warning, and frequency values in the
ast_bridge_features_limits structure dynamically as you mention either.
Those
values are only used to construct up to three interval hooks by
bridge_builtin_interval_features.c:bridge_builtin_set_limits().  It is
those interval
hooks that actually control the timing.  The interval hooks are put into a
priority
heap where the next to expire hook timer is at the top of the heap.  The
bridge
channel thread then waits for either the next interval hook timer to expire
or a
frame to arrive.  The other change with the new way is that each channel
gets
its own interval timers with limits set depending upon if it is the chan or
peer
channel in the initial two party bridge.  Each channel then acts
independently
on its own interval timers.

There is currently no API call to allow access-to or changing-of the
interval hook
timers once they are set.  It won't be easy to gain access to the necessary
interval hook structures on both channels either.  You can get close to
locating
the needed interval hooks by following this chain: with an ast_channel
pointer use
ast_channel_internal_bridge_channel() to get the associated
ast_bridge_channel
pointer.  With the ast_bridge_channel pointer dereference the features
member
which you then have access to the interval_hooks member.  The interval_hooks
heap is a heap of struct ast_bridge_hook_timer pointers.  However, the
interval_hooks heap is not searchable for specific hooks and following the
chain
may be hazardous because of all the links that need to be followed.  You
will
definitely need to hold the channel lock to get the ast_bridge_channel
pointer.
Also the locking order to keep in mind is: ast_bridge locks
ast_bridge_channel
locks ast_channel.  Locking against this order requires deadlock avoidance.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] New feature for chan_pjsip : res_pjsip_session : Using DNID variable to change to uri number part

[Richard Mudgett]

On Thu, May 18, 2017 at 12:39 AM, Yasin CANER 
wrote:

> Hello,
> After chan_pjsip is added in asterisk  channels and asterisk
> improvement  goes to chan_sip to chan_pjsip , i tried to move my network to
> chan_pjsip. one feature has chan_sip but not chan_pjsip that i use   ,
> exclamation mark in Dial to change to uri number part.
> So i added a function to solve this problem or missing feature in
> res_pjsip_session.
> Why did i use the DNID in Callerid. in wiki asterisk it has a
> explanation that dialed party number. so it suits me and has a
> variable/struct in asterisk channel, it makes easy to use. In addition it
> is kinda changin Callerid number part.
>
> if i cant add this feature or solve this problem , i cant update my
> network , soon or later , i have to change my asterisk to another because i
> know that chan_sip gonna stop to improve in a day.
>
>
> Why i need it. Because some FXS devices like Dinstar waits Request Uri
> number and To uri number must be same. if not , it declines or drop the
> calls.
>
> How does it work that in here with .jpeg
> https://issues.asterisk.org/jira/browse/ASTERISK-26957
>
> i tried to so many way to solve this issue with Matt Jordan and others.
> here;
>  https://community.asterisk.org/t/way-to-get-toheader-name-
> or-number/68717/6
>  https://community.asterisk.org/t/asterisk-13-pjsip-manipula
> te-to-header-on-dial/67550
>
> my commit
> https://gerrit.asterisk.org/#/c/5545/


The Dialed Number IDentifier (DNID) is defined as an incoming value which
represents the dialed number to reach the server.  Making it do something
different for outgoing channels overloads its meaning and is likely to
break something.

I think the dialplan function PJSIP_HEADER could be extended to work on
outgoing channels to read/construct the To header string from the channel
dialog remote information and also set/modify the To header in a limited
manner to get what you need.  The To header would be an exception to the
normal header processing done by the dialplan function.

Its use in dialplan would be something like below:

; --
exten = _X.,1,NoOp()
same = n,Dial(PJSIP/endpoint,,b(pre_dial,1))
same = n,Hangup()

exten = pre_dial,1,NoOp()
;
; PJSIP_HEADER extended to read the To header out of the
session->inv_session
; dialog for outgoing channels because it otherwise isn't available.
;
same = n,Set(TO_HEADER_VALUE=${PJSIP_HEADER(read,to)})
;
; PJSIP_HEADER extended to set limited fields of a To header into the
; session->inv_session dialog for outgoing channels because it otherwise
; isn't available to modify.
; To: "test-name" 
;
same = n,Set(PJSIP_HEADER(update,to)=${TO_HEADER_VALUE})
same = n,Return()
; --

Only the read and update actions would support doing anything with the To
header in an outgoing channel situation.  The read and update actions must
first check if the To header is in the list of headers to guard against
trying to manipulate the To header on an incoming channel.  I'm fairly
sure that an incoming channel has the To header stored in its list of
headers automatically.

Helpful functions that could make the patch easier to implement.

pjsip_uri_print() - Use this C function to create the To header string for
the read.

pjsip_parse_hdr() - Use this C function to parse the set To header.  You
then need to update the session->inv_session dialog with new data that is
allowable to be changed.  Allowing unrestricted modification of the To
header is not a good thing as it would defeat what has already been done
and may interfere or get overwritten with what may still be done.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] pjsip: 180 Ringing contains wrong info in Remote-Party-ID

[Richard Mudgett]

On Mon, May 15, 2017 at 4:57 PM, Steve Murphy  wrote:

> Hmmm, according to your refs, none really apply to this situation.
>




>
>  the callerid of the target phone is set in the pjsip channel driver
> config, not in my dialplan (the same as chan_sip):
>
> And, my dialplan doesn't care about the callerid info for the phone you
> are dialing... in chan_sip, I get it via the 180 Ringing, but in pjsip, I
> am given useless information instead. I don't need it to change the sip
> exchanges to a re-invite, either. The phone is able to pick it up from the
> 180 Ringing just fine.
>
> Here is the config for the endpoints, a little cut down:
>
> [t12]   ; Yealink T49G mac=00:15:65:...
> type=endpoint
> auth=t12
> transport=transport-udp
> aors=t12
> 
> callerid="Steve" <101>
>
> [t13]   ; Yealink T48G mac=00:15:65:...
> type=endpoint
> auth=t13
> transport=transport-udp
> aors=t13
> 
> callerid="s2 test" <102>
>
> Since the config holds the callerids for each endpoint, I don't have any
> code to do lookups to get the callerid of the target. chan_sip has been
> fine providing it to the phone via the 180 Ringing...
>
> Right now, I'm running the exact same dialplan for chan_sip and pjsip. Are
> you telling me that I have to change the dialplan for pjsip? Can you give
> me a solid example of what I'd need to do in the dialplan to get the same
> effect?  As a matter of fact, I run the two channel drivers on two
> different ports, and I have phones on pjsip, and phones on chan_sip at the
> same time...
>

There is something in your setup setting the wrong information.  My test
setup does
send the correct information for the 180 Ringing message.  I am not running
the two
SIP channel drivers at the same time.

For a simple dialplan you should only need to do a dial when
PJSIP/t12 calls 102:

exten = 102,1,NoO()
same = n,Dial(PJSIP/t13)
same = n,Hangup()

You don't need to specify the transport in the endpoint config as the
transport can
be determined from the defined transports.

There should be a send_rpid=yes somewhere in the endpoint config.

Are you dialing between chan_sip and chan_pjsip channels for your testing?

You could expand upon the basic dial by adding an interception routine [1]
that
just shows you the values of CALERID(all) and CONNECTEDLINE(all) when the
routine
runs.

Richard

[1]
https://wiki.asterisk.org/wiki/display/AST/Party+ID+Interception+Macros+and+Routines
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] pjsip: 180 Ringing contains wrong info in Remote-Party-ID

[Richard Mudgett]

On Mon, May 15, 2017 at 10:45 AM, Steve Murphy  wrote:

> Hello--
>
> I've got complaints that the phones are presenting the wrong info when
> making an outgoing call... instead of displaying the called party info,
> it's displaying the caller's info, which is highly uninteresting. I've been
> looking at the behavior with Yealink phones, but I'm told that ALL phones
> have the problem, and comparing with the sip channel driver.
>
> I'm working with asterisk (and pjsip) at version 13.15.0, so this is
> pretty much current behavior.
>
> I traced it down to the 180 Ringing message sent to the phone from
> Asterisk, in the course of making an outgoing call from the Yealink, in
> this case, to another extension on the same phone system.
>
> In the old chan_sip world, I see this:
>
> [May 13 13:10:58] <--- Transmitting (NAT) to 67.215.23.186:28762 --->
> [May 13 13:10:58] SIP/2.0 180 Ringing
> [May 13 13:10:58] Via: SIP/2.0/UDP 192.168.134.126:5060;branch=
> z9hG4bK1785363097;received=67.291.23.186;rport=28762
> [May 13 13:10:58] From: "Steve Murphy"  >;tag=2559859725
> [May 13 13:10:58] To: ;tag=as0a66b2c7
> [May 13 13:10:58] Call-ID: 0_762068959@192.168.134.126
> [May 13 13:10:58] CSeq: 2 INVITE
> [May 13 13:10:58] Server: nexVortex Inc Hosted 3.0 PBX
> [May 13 13:10:58] Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
> SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
> [May 13 13:10:58] Supported: replaces, timer
> [May 13 13:10:58] Contact: 
> [May 13 13:10:58] Remote-Party-ID: "Shifting Sands" <
> sip:767@190.190.190.190>;party=called;privacy=off;screen=no
> [May 13 13:10:58] Content-Length: 0
> [May 13 13:10:58]
>
> Note, that Asterisk serves up callerid info from the target extension in
> this header, providing not only the number of the target extension, but the
> callerid NAME info, also, which is pretty nice!
>
> ​But, in the PJSIP world, I see this instead (on a different test system):
>
> [May 13 08:21:59] <--- Transmitting SIP response (597 bytes) to UDP:
> 192.168.134.102:5060 --->
> [May 13 08:21:59] SIP/2.0 180 Ringing
> [May 13 08:21:59] Via: SIP/2.0/UDP 192.168.134.102:5060;rport=
> 5060;received=192.168.134.102;branch=z9hG4bK1705376406
> [May 13 08:21:59] Call-ID: 0_1685072057@192.168.134.102
> [May 13 08:21:59] From: "Steve" ;tag=3119644064
> [May 13 08:21:59] To: ;tag=
> c7988cae-0380-49b4-84e6-0a03b656ab85
> [May 13 08:21:59] CSeq: 2 INVITE
> [May 13 08:21:59] Server: nexVortex SoupedUp Asterisk Hybrid
> [May 13 08:21:59] Contact: 
> [May 13 08:21:59] Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK,
> BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
> [May 13 08:21:59] Remote-Party-ID: "Steve" ;
> privacy=off;screen=no
> [May 13 08:21:59] Content-Length:  0
>
>
> ​In this instance, it just looks like the rpid is a copy of the "From:"
> header. This isn't so interesting, as I already know my own name and
> extension number!
>
> I traced this down to the add_rpid_header() func in the
> res/res_pjsip_caller_id module... but I suspect that the connected line
> updates play a role here, and I'm too much a nube to know where the "right"
> information is.
>
> ​Am I hallucinating? Got a bad config? Or is there a bug here?
>

There isn't much to determine why the wrong party information [1] is being
used here.
I do think this is a configuration or dialplan issue and not a bug.  Maybe
you are using
CALLERID when you should be using CONNECTEDLINE on the PJSIP channel?

This could be a configuration issue caused by the difference between how
chan_sip
and chan_pjsip do things.  Since chan_sip predates pre-dial handlers you
had to setup
information in inheritable channel variables and the SipAddHeader
application before
dialing the destination so the outgoing channel gets created with expected
information.
For PJSIP channels you need to use pre-dial handlers [2] to setup
information on the
actual outgoing channel before the call gets placed.

Richard

[1]
https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information
[2] https://wiki.asterisk.org/wiki/display/AST/Pre-Dial+Handlers
[3]
http://blogs.asterisk.org/2017/03/29/dialplan-handler-routines-allow-customization/
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk Memory Debugger (MALLOC_DEBUG) and DONT_OPTIMIZE

[Richard Mudgett]

On Mon, May 8, 2017 at 11:11 AM, bala murugan  wrote:

> Thanks a lot Richard for the response and explanation
>
> with allocations i was able to determine where the leak would be by going
> through the code(atleast 5 files) .
>
> But i was looking for an easier way to see which piece of the code is
> leaking memory to help identify the problem
>
> there are multiple CLI commands - with no detailed info on what it is and
> how to use to spot where the leak is
>
> Is there any doc as such with example .
>

No, other than this wiki page.
https://wiki.asterisk.org/wiki/display/AST/MALLOC_DEBUG+Compiler+Flag

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk Memory Debugger (MALLOC_DEBUG) and DONT_OPTIMIZE

[Richard Mudgett]

On Fri, May 5, 2017 at 11:55 AM, bala murugan  wrote:

> Hi ,
>
> Can someone please help me understand what to look for in the
> /var/log/asterisk/mmlog to check where the leak is , since on Exit it
> throws me millions of line under Exiting with the following memory not
> freed.
>
> need some knowledge on reading this file so that i can pinpoint where the
> leak is .
>

If you exit Asterisk using "core stop now" then Asterisk does the absolute
minimum cleanup
before exiting so you will see a lot of unreleased memory.  You need to use
"core stop gracefully"
for Asterisk to clean up as much as it can before exiting.

MALLOC_DEBUG does many things for you:
* It keeps track of each block of memory that is allocated until it is
pushed out of a fixed size
freed memory holding queue.  It remembers where a block of memory was
allocated and how
large it is.
* It checks for memory writes above and below the block of memory when the
code frees memory.
If it sees the guard pattern has changed it complains of high and/or low
fence violations respectively.
* It fills the memory block with the 0xdeaddead pattern when the code frees
memory.  The memory
is then placed into a holding queue for awhile.
* It complains of memory corruption when a memory block is pushed out of
the holding queue and
the fill pattern has changed.
* If you get a crash because of a pointer trying to access the 0xdeaddead
(0xdeaddeaddeaddead)
fill pattern address then you know someone was using a freed block of
memory.  The pattern was
specifically chosen to cause a crash and be obvious for this reason.
* It gives you live allocation reports using "memory show summary".  You
can then watch
memory leaks consuming more and more memory.
* It gives you an unfreed allocation list on Asterisk shutdown when
requested.

Memory leaks are shown by a lot of allocations from an allocation location
that are never released.
The larger the leak the more allocations that are never released.  You
should be able to narrow it
down by noting which allocations don't seem to be freed because the number
of the allocations
from a location keeps increasing.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] astDB "restart"

[Richard Mudgett]

On Mon, Apr 10, 2017 at 9:18 AM, Gabriel Ortiz Lour 
wrote:

> Hi,
>   We are experiencing problems with leaks on our system and we think is
> astDB related.
>   I'm still using 1.8, migrating to 13, but for now i'd like to do
> something like an astDB "restart". Close the database and open again...
>
>   I'd like just a pointer to where start:
>   Where should I look on the source for astDB init/shutdown?
>

Look in main/db.c.  IIRC we switched from Berkley DB to sqlite3 for the
astDB
backend because of issues like memory leaks.

You could also simply do a CLI "core restart now" in the middle of the
night.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] AST_MODULE_LOAD_FAILURE vs AST_MODULE_LOAD_DECLINE

[Richard Mudgett]

On Wed, Apr 5, 2017 at 3:43 PM, George Joseph  wrote:

> Over the years I've been frustrated at times where Asterisk fails to start
> for absolutely no (apparent) reason.  No error message, no trap, nothing.
> It just ends.  Every case of this I've tracked down has been the result of
> a module returning AST_MODULE_LOAD_FAILURE when it encounters a problem
> but not bothering to print an error first.   If you don't know
> already, AST_MODULE_LOAD_FAILURE tells asterisk to *stop loading and exit*.
> What the module should have done was actually print an error and
> return AST_MODULE_LOAD_DECLINE which just tells asterisk that the module
> couldn't load.
>
> So now I'm doing an audit of module return codes to see which call FAILURE
> vs DECLINE and found the modules below all call FAILURE.
>
> The big question is...  Exactly which modules are so critical to asterisk
> that asterisk should exit if the module couldn't load?  Surely not all 103
> modules listed below.  If we can agree on the ones that really *should*
> call FAILURE, I'll update those with error messages, then change the rest
> to DECLINE and add error messages as needed.
>
> Reply with the list intact.  Don't add, remove, split or re-order the
> lines.  Just stick an "F " before the modules you think should remain
> failure.
>
> Modules returning FAILURE:
>
> ./addons/app_mysql.c
> ./addons/cdr_mysql.c
> ./addons/chan_mobile.c
> ./apps/app_adsiprog.c
> ./apps/app_agent_pool.c
> ./apps/app_alarmreceiver.c
> ./apps/app_amd.c
> ./apps/app_authenticate.c
> ./apps/app_cdr.c
> ./apps/app_confbridge.c
> ./apps/app_festival.c
> ./apps/app_followme.c
> ./apps/app_forkcdr.c
> ./apps/app_meetme.c
> ./apps/app_queue.c
> ./apps/app_skel.c
> ./apps/app_voicemail.c
> ./cdr/cdr_custom.c
> ./cel/cel_custom.c
> ./cel/cel_odbc.c
> ./channels/chan_alsa.c
> ./channels/chan_console.c
> ./channels/chan_dahdi.c
> ./channels/chan_iax2.c
> ./channels/chan_mgcp.c
> ./channels/chan_misdn.c
> ./channels/chan_motif.c
> ./channels/chan_nbs.c
> ./channels/chan_oss.c
> ./channels/chan_phone.c
> ./channels/chan_pjsip.c
> ./channels/chan_sip.c
> ./channels/chan_skinny.c
> ./channels/chan_unistim.c
> ./channels/chan_vpb.cc
> ./codecs/codec_a_mu.c
> ./codecs/codec_adpcm.c
> ./codecs/codec_alaw.c
> ./codecs/codec_g722.c
> ./codecs/codec_g726.c
> ./codecs/codec_gsm.c
> ./codecs/codec_ilbc.c
> ./codecs/codec_lpc10.c
> ./codecs/codec_resample.c
> ./codecs/codec_ulaw.c
> ./formats/format_g723.c
> ./formats/format_g726.c
> ./formats/format_g729.c
> ./formats/format_gsm.c
> ./formats/format_h263.c
> ./formats/format_h264.c
> ./formats/format_ilbc.c
> ./formats/format_jpeg.c
> ./formats/format_ogg_vorbis.c
> ./formats/format_pcm.c
> ./formats/format_sln.c
> ./formats/format_vox.c
> ./formats/format_wav.c
> ./formats/format_wav_gsm.c
> ./funcs/func_cdr.c
> F ./main/loader.c
> ./pbx/pbx_dundi.c
> F ./pbx/pbx_loopback.c
> F ./pbx/pbx_realtime.c
> F ./pbx/pbx_spool.c
> ./res/res_pjsip/config_transport.c
> ./res/res_ari.c
> ./res/res_ari_events.c
> ./res/res_ari_model.c
> ./res/res_calendar.c
> ./res/res_chan_stats.c
> ./res/res_clialiases.c
> ./res/res_config_ldap.c
> ./res/res_config_sqlite.c
> ./res/res_config_sqlite3.c
> ./res/res_curl.c
> ./res/res_endpoint_stats.c
> ./res/res_fax.c
> ./res/res_hep_rtcp.c
> ./res/res_http_websocket.c
> ./res/res_musiconhold.c
> ./res/res_odbc.c
> ./res/res_phoneprov.c
> ./res/res_pjsip_nat.c
> ./res/res_pjsip_one_touch_record_info.c
> ./res/res_pjsip_outbound_publish.c
> ./res/res_pjsip_outbound_registration.c
> ./res/res_pjsip_sdp_rtp.c
> ./res/res_pjsip_send_to_voicemail.c
> ./res/res_pjsip_t38.c
> ./res/res_smdi.c
> ./res/res_snmp.c
> ./res/res_stasis.c
> ./res/res_stasis_device_state.c
> ./res/res_stasis_playback.c
> ./res/res_stasis_recording.c
> ./res/res_stasis_test.c
> ./res/res_statsd.c
> ./res/res_timing_kqueue.c
> ./res/res_xmpp.c
> ./res/res_pjsip_pubsub.c
> ./tests/test_bucket.c
> ./tests/test_channel_feature_hooks.c
>
> --
> George Joseph
> Digium, Inc. | Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: www.digium.com & www.asterisk.org
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Line length restrictions in code changes

[Richard Mudgett]

On Thu, Mar 16, 2017 at 2:54 PM, Matthew Jordan  wrote:

> Warning: bike shedding.
>
> On several code reviews, comments have been left along with a -1 on
> the review - indicating that it is not acceptable for merging - due to
> line length restrictions. While this is technically correct per our
> coding guidelines, it doesn't always result in the most readable code.
>
> Personally, I find this:
>
> if (a_good_variable_name->another_good_name &&
> do_something_to_it(a_good_variable_name->another_good_name)) {
> // Do things
> }
>
> To be preferable to:
>
> if (a_good_variable_name->another_good_name
> && do_something_to_it(a_good_variable_name->another_good_name)) {
> // Do things
> }
>
> This is typically because the indentation of the second part of the
> boolean test lines up with the code that is to be executed if both
> conditions is true, which is more visually jarring than just reading
> the first line.
>
> I'll grant this is probably a personal preference, but we have
> certainly opted for the former over the latter in many places in the
> code.
>

It is done both ways in the code.

My preference is the opposite for a couple reasons:
1) Seeing && at the beginning of a line you then know that it is part of a
line
continuation because && is a binary operator and needs something to its
left.
2) On long lines you can miss seeing that there even is an operator on the
end of the line.  The line end may even be off the edge of the window.
Either
way you would not know how to interpret the expression unless you knew
what the operator is.  You are then forced to scroll the window to find out.


>
> While I know that we aren't all sitting around with dual screens, we
> also aren't living in 1979 with dumb terminals. The line length
> restriction of 90 columns seems reasonable until you end up with long
> function names, which - since we live in a land of void * - is
> generally something that we should encourage. I'd like to say that
> some common sense about when to apply the line length rule and when
> not to would "work for us", but that doesn't appear to be the case.
>
> Questions than:
> (1) Should there even be a line length rule?
>

Yes.  We live in the age of variable sized and multi-overlapping windows.
In a way this is worse than the 1979's fixed sized display because we
try to cram more on the screen.


> (2) If there is a line length, what is a reasonable length given some
> of our function names? (Looking at things like
> ast_sip_get_mwi_disable_initial_unsolicited)
>

The 90 line length is a good compromise.  You can look at side by side
differences and not have to scroll horizontally except when the line length
is too long.


> (3) Should we simply advocate for readability, with examples of what
> is readable and what is not?
>

There are ways to deal with the long identifier lengths creating very long
lines.  One of the simpler is to avoid putting assignments in conditional
test expressions.  There are better readability line breaks available in a
stand alone assignment than there are when you cram the assignment
into an if test expression.  Another is not to excessively indent parameters
to functions like python PEP8 encourages.  Function parameters tend
to get quite long themselves.  Horizontal line space is at a premium
compared to vertical space.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Regression: dash a not a character any more?

[Richard Mudgett]

On Tue, Jan 17, 2017 at 3:40 PM, Kirill Katsnelson <k...@smartaction.com>
wrote:

> On 170117 1232, Richard Mudgett wrote:
>
>> On Tue, Jan 17, 2017 at 2:03 PM, Kirill Katsnelson <k...@smartaction.com>
>> wrote:
>>
>> A change from 1.8 to 13 broke us in some other aspect, and I am trying to
>>> figure out whether this is a bug or things work as expected. In short,
>>> the
>>> '-' character is converted to nothing in extension "numbers"
>>>
>>> Here's a snippet that demonstrates the problem:
>>>
>>> extension.ael:
>>>
>>> context test {
>>>   foobar =>  Hangup();
>>>   foo-bar => Play(foo-bar);
>>> }
>>>
>>> *CLI> ael reload
>>> [2017-01-17 11:45:47.688] WARNING[57864]: pbx.c:6987 add_priority: Unable
>>> to register extension 'foo-bar' priority 1 in 'test', already in use by
>>> aliased extension 'foobar'
>>> *CLI> dialplan show test
>>> [ Context 'test' created by 'pbx_ael' ]
>>>   'foobar' =>   1. Hangup()
>>>  [pbx_ael]
>>>
>>> -= 1 extension (1 priority) in 1 context. =-
>>>
>>> "dialplan debug" shows the '-' is not in the trie trace at all.
>>>
>>> In 1.8, ael reloads completes without a warning, and
>>>
>>> *CLI> dialplan show test
>>> [ Context 'test' created by 'pbx_ael' ]
>>>   'foo-bar' =>  1. Play(foo-bar)
>>> [pbx_ael]
>>>   'foobar' =>   1. Hangup()
>>>  [pbx_ael]
>>>
>>> -= 2 extensions (2 priorities) in 1 context. =-
>>>
>>> Was the change intentional? Will you accept a patch that reintroduces the
>>> old behavior (with an option perhaps?). The '-' is so deeply embedded
>>> into
>>> all our Asterisk infrastructure (autogenerated files, AMI controllers
>>> etc.)
>>> that it is not realistic at this point to attempt to change the separator
>>> character.
>>>
>>>
>> The '-' dash has always been eye-candy and means nothing when matching
>> extensions.
>> Otherwise you would not be able to dial something like 18005551212 if you
>> had this as an exten:
>>
>> exten = 1-800-555-1212,1,NoOp()
>> same = n,Playback(tt-weasels)
>> same = n,Hangup()
>>
>> Inconsistencies in the treatment of '-' were intentionally removed so
>> extensions will always match.
>>
>
> Thanks, interesting. It worked for us somehow, but possibly for a wrong
> reason then!
>
> I see where the change is coming from: https://github.com/asterisk/as
> terisk/commit/7f0bfe536fdf3856dfbaf7303f5af28dad88e78e; ASTERISK-19205
> really highlights a lot of past inconsistencies. So it's a good thing it
> was fixed, only a bad thing is that broke our code...
>
> Is it documented anywhere what characters are considered legal in an
> extension name, and what are reserved? Perhaps we should bite the bullet
> and replace the separating symbol with something else; wondering what
> characters would be safe then.


I don't think there is an explicit list of what characters are reserved.

You could use '_' underbar instead of '-' dash except as the first
character where
it indicates the extension is a pattern [1].  It depends upon if your
extensions
normally are numeric or alpha-numeric.

exten = foo_bar,1,NoOp()
exten = bar_none,1,NoOp()

Beware of alpha-numeric extension names in a pattern:

exten =_bar_none,1,NoOp()

The above extension does not match what you may think because
of the two n's in the extension.  The 'n' represents a character set
of '2' through '9'.  See [1].  If you really want the n's in the extension
you have to do this:

exten = _bar_[n]o[n]e,1,NoOp()

Richard

[1] https://wiki.asterisk.org/wiki/display/AST/Pattern+Matching
[2]
https://wiki.asterisk.org/wiki/display/AST/Contexts%2C+Extensions%2C+and+Priorities
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Regression: dash a not a character any more?

[Richard Mudgett]

On Tue, Jan 17, 2017 at 2:03 PM, Kirill Katsnelson 
wrote:

> A change from 1.8 to 13 broke us in some other aspect, and I am trying to
> figure out whether this is a bug or things work as expected. In short, the
> '-' character is converted to nothing in extension "numbers"
>
> Here's a snippet that demonstrates the problem:
>
> extension.ael:
>
> context test {
>   foobar =>  Hangup();
>   foo-bar => Play(foo-bar);
> }
>
> *CLI> ael reload
> [2017-01-17 11:45:47.688] WARNING[57864]: pbx.c:6987 add_priority: Unable
> to register extension 'foo-bar' priority 1 in 'test', already in use by
> aliased extension 'foobar'
> *CLI> dialplan show test
> [ Context 'test' created by 'pbx_ael' ]
>   'foobar' =>   1. Hangup()   [pbx_ael]
>
> -= 1 extension (1 priority) in 1 context. =-
>
> "dialplan debug" shows the '-' is not in the trie trace at all.
>
> In 1.8, ael reloads completes without a warning, and
>
> *CLI> dialplan show test
> [ Context 'test' created by 'pbx_ael' ]
>   'foo-bar' =>  1. Play(foo-bar)  [pbx_ael]
>   'foobar' =>   1. Hangup()   [pbx_ael]
>
> -= 2 extensions (2 priorities) in 1 context. =-
>
> Was the change intentional? Will you accept a patch that reintroduces the
> old behavior (with an option perhaps?). The '-' is so deeply embedded into
> all our Asterisk infrastructure (autogenerated files, AMI controllers etc.)
> that it is not realistic at this point to attempt to change the separator
> character.
>

The '-' dash has always been eye-candy and means nothing when matching
extensions.
Otherwise you would not be able to dial something like 18005551212 if you
had this as an exten:

exten = 1-800-555-1212,1,NoOp()
same = n,Playback(tt-weasels)
same = n,Hangup()

Inconsistencies in the treatment of '-' were intentionally removed so
extensions will always match.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Local channel variable propagation: expired hack or a bug?

[Richard Mudgett]

On Wed, Jan 4, 2017 at 1:45 PM, Kirill Katsnelson <k...@smartaction.com>
wrote:

> On 170103 2114, Richard Mudgett wrote:
>
>> On Tue, Jan 3, 2017 at 9:38 PM, Kirill Katsnelson <k...@smartaction.com>
>> wrote:
>>
>> With Asterisk 1.8 we were relying on the behavior of Originate with Local
>>> channels as mentioned in https://issues.asterisk.org/ji
>>> ra/browse/ASTERISK-17239. This no longer works in Asterisk 13.
>>>
>>> You were definitely depending upon an implementation detail and some luck
>> on when the optimization would happen.  Asterisk versions before v12 used
>> masquerades to implement local channel optimizations.  The channel
>> executing dialplan before the wait turns into a different channel after
>> the
>> wait because of the masquerade.  The wait simply made the local channel
>> optimization more likely to happen during the wait because the
>> optimization
>> could happen any time during the exchange of media frames.  Asterisk v12+
>> no longer optimizes local channels this way.  Instead it moves a channel
>> from one bridge to another.  (See discussion on
>> https://issues.asterisk.org/jira/browse/ASTERISK-26681)
>>
>
> Richard, thanks for the explanation and notes. I pretty much suspected
> that I was relying on undefined behavior.
>
> I am thinking of using the IMPORT() function to get channel variables from
> the second "half" of the Local channel. That works, but I have to rely on
> knowing the naming scheme of the channels: drop the last character, which
> is the '1' after the ';', and then add a '2').
>
>   P = "${CHANNEL(name):0:-1}2";  // Local/Sample@test-local-0007;2
>   Q = "${IMPORT(${P},QUUX)}";
>
> But this also a bit hackish. Is this naming scheme not going to change so
> I can rely on it? Can you maybe think of a more canonical/kosher/reliable
> approach?


I don't think it will change anymore.  It looks like the local channel name
scheme has changed some over the years but the last character has been a 1
or a 2 to differentiate the two paired channels.  Local channels by their
nature have to be created in pairs so if the scheme does change I doubt it
will be difficult to adjust anyway.  In fact as recently as v11, Asterisk
itself did a similar local channel name manipulation to get the paired
channel in the DTMF features code.

v1.4 = Local/exten@context-random,1 and ,2  (random is a 4 digit randomly
generated hex number)

v1.6.0 = Local/exten@context-random;1 and ;2 (comma changed to semicolon I
suspect because the application parameter delimiter changed from the pipe
to the comma)

v1.8 = Local/exten@context-sequence;1 and ;2 (sequence is a 8 digit
incrementing hex number counting each local channel pair created.  Changed
to a sequence number because it was possible for random to create duplicate
active channel names)

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Local channel variable propagation: expired hack or a bug?

[Richard Mudgett]

On Tue, Jan 3, 2017 at 9:38 PM, Kirill Katsnelson 
wrote:

> With Asterisk 1.8 we were relying on the behavior of Originate with Local
> channels as mentioned in https://issues.asterisk.org/ji
> ra/browse/ASTERISK-17239. This no longer works in Asterisk 13.
>
> Specifically, when a call is originated (e. g. via AMI) between "channel"
> Local/x@local-side and "extension" y@remote-side, the local-side runs on
> the Local/xxx;1 channel, and sets some variables in the dialplan. The old,
> 1.8 behavior, was to propagate the variables to the Local/xxx;2 channel
> when it gets it's turn to execute dialplan (y@remote-side in the
> example), after an infinitesimal Wait(), as the ticket explains.
>
> This does not happen anymore in Asterisk 13. In fact, no variables are set
> on the remote-side, Local/xxx;2 channel; none of BRIDGEPEER,
> DIALEDPEERNUMBER, SIPCALLID from the ticket flow are set.
>
> Local channel optimization does not occur in this example, as there is
> only one bridge (and the LocalBridge between the Local channels)
>
> So my question is, did we use an undocumented hack, and therefore must
> find a different solution, or the current implementation has a bug that
> should be fixed? I honestly cannot remember where I got the idea initially,
> and whether or not it was documented.
>

You were definitely depending upon an implementation detail and some luck
on when the optimization would happen.  Asterisk versions before v12 used
masquerades to implement local channel optimizations.  The channel
executing dialplan before the wait turns into a different channel after the
wait because of the masquerade.  The wait simply made the local channel
optimization more likely to happen during the wait because the optimization
could happen any time during the exchange of media frames.  Asterisk v12+
no longer optimizes local channels this way.  Instead it moves a channel
from one bridge to another.  (See discussion on
https://issues.asterisk.org/jira/browse/ASTERISK-26681)

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Subscription behavior when an incoming registration goes away?

[Richard Mudgett]

On Thu, Dec 22, 2016 at 10:14 AM, Matthew Jordan  wrote:

>
>
> On Thu, Dec 22, 2016 at 9:32 AM, George Joseph  wrote:
>
>> When an incoming registration goes away, either because it expires or it
>> was explicitly expired, what should we do with subscriptions the contact
>> may have?  Right now we do nothing which means that activity for those
>> subscriptions will trigger NOTIFYs which will time out and retry until
>> timer_b expires.  Only then will they be deleted.
>>
>> Should we:
>>
>>- Leave the behavior as is?
>>- Automatically remove the subscriptions for a contact that has been
>>deleted?
>>- Create a global option to control auto deletion?
>>- Create an aor option to control auto deletion?
>>
>> Opinions?
>>
>>
> If an AoR only has dynamic contacts, and those dynamic contacts are no
> longer valid (or the AoR no longer has any contacts), then at the very
> least I would think we wouldn't want to send the NOTIFY requests until the
> AoR has valid contacts. There's certainly no reason to use memory/CPU
> cycles on something that will never succeed.
>
> You may or may not want to actually remove the underlying subscription. I
> could see a scenario in which a phone's REGISTER request goes "missing",
> and so the registration drops - maybe for just a short period of time. When
> the new REGISTER request does succeed, the phone may or may not send a new
> SUBSCRIBE request (which may have a very different timer). If we
> auto-deleted the underlying subscription, we could have a situation where
> the phone is re-registered but no longer receives state updates.
>
> I'll grant the above scenario is pretty unlikely, but it is plausible.
>

I was originally thinking to dump the subscriptions.  But Matt's reasoning
makes plain that we
should only just skip sending the NOTIFY's when we have no AOR available.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Cannot set CallerId on outgoing call

[Richard Mudgett]

On Fri, Dec 9, 2016 at 8:54 AM,  wrote:

> Hi All,
>
> I have a scenario where an incoming external call comes into Asterisk and
> into my Stasis application, I there check my database to find the
> destination so I can route the call there. I follow the recommended
> procedure:
> 1. Create bridge
> 2. Create channel for outbound call
> 3. Add incoming channel to bridge
> 4. Add outbound channel to bridge
> 5. Dial() destination.
>
> I have Asterisk 14.1 and I use Ari4Java. I try to set some channel
> variables before the Dial(), both "SIPFROMUSER" and "CALLERID(num)". These
> values I can see when the call proceeds and I receive Dial events. So it
> seems Ari4java is doing the right thing. But no matter what, the second
> outbound call gets the callerId of the inbound call.
>
> Has anyone been able to do what I am attempting. It seems like a very
> normal feature, should be possible.
>

You need to understand the relationship between caller-id and
connected-line.
See the link [1] for further information.

Richard

[1]
https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information#ManipulatingPartyIDInformation-PartyIDpropagation
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project

[Richard Mudgett]

On Wed, Nov 30, 2016 at 8:04 AM, Joshua Colp  wrote:

> On Fri, Nov 25, 2016, at 10:20 AM, Dennis Guse wrote:
> > Hey guys,
> >
> > we continued working on our largest changeset: https://gerrit.
> > asterisk.org/#/c/3524/
> > Besides the copyright of HRTFs (still under investigation from our side),
> > the only issue on our side is the introduced `settings_lock` (defined in
> > bridge.h:254).
> > This lock is used in addition to the bridge-lock in bridge_softmix:1093.
> >
> > The issue the settings_lock solves is that during bridge startup
> > (actually
> > `softmix_mixing_thread()`) we need to know the configuration parameters
> > (is
> > binaural active or not?).
> > Since the startup of the mixing thread and parsing the configuration is
> > asynchronous (at least our understanding: we saw race conditions), we use
> > the 2nd lock to wait until configuration information is available before
> > really starting the mixing thread.
> > We could avoid introducing the settings_lock by repeatedly checking in
> > the
> > mixing loop.
> > However, this doesn't sound like a good idea...
> > Thus, a bridge now has two locks (ast_bridge_lock and the settings_lock),
> > which is some overengineering.
> >
> > Is there a better solution to addressing this issue?
>
> Without changing things such that settings and attributes could be
> passed in during the bridge creation or making bridge creation a two
> stage process (both of which are larger changes than I'd like to see) I
> don't see a way to do this during bridge creation. Is it possible to
> check in the bridge loop to see that binaural has been enabled but not
> set up and set it up? This should not impact the mixing loop a large
> amount during normal operation and overcomes the problem that the
> settings_lock has right now. It would also allow API control to toggle
> binaural on/off at a bridge level.
>

The new settings lock is not necessary.  You can simply defer the binarual
initialization to when the first channel enters the bridge.  The confbridge
bridge
is created and the binarual active option is set before any channels could
possibly enter the bridge.  The softmix_mixing_thread() will either not have
started yet or be waiting for the first channel to join.

If the first channel has joined before the softmix_mixing_thread() has
started
then you initialize the binarual data as you do currently.

If the softmix_mixing_thread() is waiting for the first channel to join
then it
is in the ast_cond_wait() because bridge->num_active is zero.

You just need to protect against initializing more than once.  The
protection
can be done completely inside the bridge_softmix technology using the
technology's private data to remember it.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] AGI:async

[Richard Mudgett]

On Fri, Nov 25, 2016 at 10:14 AM, Salvatore Franco 
wrote:

> Hi,
> It means that the call still waiting something but never enter in Queue
> (as if async is not really async).
> So I think the dialplan never calls the next step.
>

You seem to misunderstand what AGI actually is.  AGI _is_ dialplan.  What
you can do in dialplan
is what you can do in AGI.  The call will stay in your AGI until you tell
it continue in normal dialplan
or the call hangs up.  AGI simply allows you to write your dialplan in a
scripting language more
familiar to you.  Depending upon your scripting language, AGI also allows
you better access to
things outside of Asterisk such as querying databases.  Async AGI is a very
specialized flavor of
the three AGI modes available as it merges AGI into AMI.  However it is
still AGI.

Your earlier emails in this chain indicate that app_queue does not do what
you seem to want from
an automatic call distribution system.  In that case you can modify
app_queue, write your own
app_queue in C, or you can use ARI.  ARI is available in the currently
supported Asterisk v13 and
later versions.  ARI gives you access to the building blocks normally
available to dialplan applications
so you can write your own applications such as queue and voicemail.

Richard

[1] https://wiki.asterisk.org/wiki/display/AST/Interfaces
[2] https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=29395573
(ARI interface page)
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Queue Gate Concept

[Richard Mudgett]

On Fri, Oct 21, 2016 at 6:09 PM, Troy Bowman  wrote:

> Where I work, we're running a call center on Asterisk, using app_queue.
>
> For a long while, we were using multiple queues for each speciality (or
> "skill"), placing agents in several queues, and using the "announce"
> queue.conf configuration option to whisper to the agent the role they
> should perform for the incoming call, and reporting statistics for each
> queue.  For example, Sales needs to be able to answer the call differently
> for different products, and we need to report on how many calls we are
> receiving for each product, how they are handled, and what type of support
> calls we're getting, and so on.
>
> We had what I thought were issues with n! (O^n) mutex locking
> possibilities as multiple queues had more and more calls queued up, and as
> those multiple queues had to check all of the agent states over and over.
> At the time, we also had the issue that if the queue priority is the same,
> there was a race condition and multiple calls would be fed to the same
> agent at the same time.  This has since been fixed (commit c345e53), but
> the issue of balancing incoming call priority for multiple queues remains.
> And with queue priorities, one queue would have to empty entirely before
> the other queue would start to empty.
>
> The idea came from our operations leadership that another phone system
> they used in the past had the concept of multiple "gates" to the same
> queue.  Gates could provide these advantages:
>
> - Keep each team (support, sales, etc) in their own single queue.  Simple!
> - Reduce the n! (O^n) possibilities to just n (O*n) for queue
> distribution, and mutex locking cpu load.
> - Aggregate an entire teams' statistics, but keep the ability to break
> statistics out by gate, too.
> - Keep all incoming calls from multiple gates prioritized by their age in
> the single queue.
>
> The point of a gate is to be able to dynamically define an entry name to
> the queue in the dialplan, depending on menu options or DIDs that whatever
> route the caller took to arrive at the queue.  The queue "announceoverride"
> parameter, which is played to the agent as they answer the call, is the
> perfect opportunity to double as a definition of a gate name.  We would
> just need reporting for the different announceoverrides in the queue log.
>
> I modified app_queue.c, and we've been running with my changes for about 6
> months.  So far, so good.  Here is a summary of the changes I made:
>
> To me, the name "announce" in the queues.conf and "announceoverride"
> app_queue argument is ambiguous.  While those names should reflect what is
> whispered to the agent when they accept a queue call, there are many other
> "announce" queue configuration parameters that reflect what is played to
> the caller while they are waiting in the queue.  I renamed "announce" to
> "gate_whisper" and "announceoverride" to "override_gate_whisper."
>
> The big piece of the puzzle was reporting gate statistics.  I did not want
> to change the schema of the queue_log, but I wanted to be able to tell if a
> queue_log entry went through a special gate.  So I added another
> queues.conf option, "log_gate_in_queuename", which if true would append the
> gate name (defined by the whisper/announce) after the queue name, delimited
> by a forward slash for easy parsing.  Appending the gate name would be
> skipped if the gate name is undefined or if the gate name is the the same
> name as the queue name.
>
> My reason for posting this is to ask if this is something you all want
> upstream.  I know many people run multiple queues simply for reporting
> statistics like I was, when we only really need one queue for each team of
> agents.  Of course, reporting packages out there would still need to take
> advantage of the queue gate in the queuename field of the queue_log, if
> they want to turn it on.
>

This sounds like a good idea.  Reducing the number of queues an agent is a
member of
certainly simplifies the lock contention involved since each caller thread
competes for
available agents.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] app_queue.c PAUSALL/UNPAUSEALL reason

[Richard Mudgett]

On Fri, Oct 21, 2016 at 5:46 PM, Troy Bowman  wrote:

>
> I always need to apply this patch before putting Asterisk into Production.
>
> The pauses for specific queues get the reason logged properly, but the
> pausealls don't.  I rely on pausalls and their reasons for reporting,
> though I'm trying to get away from it by keeping agents in single queues.
>
> Can we get this in the pipeline somewhere?  Do I have to submit a patch
> this tiny through gerrit?
>
> diff a/apps/app_queue.c b/apps/app_queue.c
> --- a/apps/app_queue.c
> +++ b/apps/app_queue.c
> @@ -7289,7 +7228,7 @@ static int set_member_paused(const char *queuename,
> const char *interface, const
>  * but since this affects all
> queues, we cannot.
>  */
> ast_queue_log("NONE", "NONE",
> mem->membername,
> -   (paused ? "PAUSEALL" :
> "UNPAUSEALL"), "%s", "");
> +   (paused ? "PAUSEALL" :
> "UNPAUSEALL"), "%s", S_OR(reason, ""));
> }
>
> set_queue_member_pause(q, mem, reason,
> paused);
>
>
All patches have to go through gerrit whether you submit it or someone else
does.
However, if you wait for someone else it may take awhile.

Richard

https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process
https://wiki.asterisk.org/wiki/display/AST/Code+Review
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Questions about Message/ast_msg_queue

[Richard Mudgett]

On Mon, Sep 19, 2016 at 4:40 AM, Jean Aunis  wrote:

> Hello,
>
> I am currently using a lot of SIP MESSAGEs, which rely on the
> Message/ast_msg_queue channel in Asterisk. Unless I misunderstood
> something, this channel is acting as a kind of "singleton" : there is only
> one instance of this channel, which processes one message after the other.
> This behaviour makes it more difficult to handle large amounts of messages,
> especially if the dialplan handling the messages takes a long time to
> execute.
>
> So my questions are the following :
>
> 1- what is the reason for this "singleton" behaviour ? Why not creating
> one channel for each SIP message ?
>
> 2- is it technically possible (and even desirable) to change this
> behaviour ?
>

Creating one channel per message would work for individual messages.  It
doesn't
work if your messages have a sequence to them.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] BRIDGEPEER on multi-party conferences: Thoughts?

[Richard Mudgett]

On Tue, Aug 9, 2016 at 6:01 PM, Mark Michelson 
wrote:

> Hi folks,
>
> I've been looking into a Digium customer issue where ConfBridge audio has
> been dropping out. The main issue there had to do with DNS, and there is
> currently a review [1] up to fix that.
>
> A secondary issue, though, is that there would be brief audio cutouts when
> participants joined and left the conference. Looking into it, I believe the
> problem is that when a participant enters or leaves the bridge, the
> BRIDGEPEER channel variable is updated for every remaining participant in
> the bridge. The basic algorithm is like this:
>
> * Lock the bridge
> * Iterate through the channels in the bridge (a maximum of 11 of them)
> * Lock the channel
> * Append the channel to an array of channel names
> * Unlock the channel
> * Iterate through the channels in the bridge again (no upper limit this
> time)
> * Lock the channel
> * Set the BRIDGEPEER channel variable using the names in the generated
> array from before (comma-separated)
> * Unlock the channel
> * Unlock the bridge
>
> In addition, this same process occurs every time an announcement is played
> into a bridge, such as join/leave beeps. Playing an announcement involves
> pushing an announcer channel into the bridge and then removing the
> announcer channel when the playback completes.
>
> My question to the list is this: do you find value in having the
> participants in a multi-party bridge packaged into the BRIDGEPEER channel
> variable? I know that for two-party bridges, there are probably lots of
> scripts and dialplans out there that rely on that variable to be set; my
> question specifically is for bridges with more than two parties.
>
> My thoughts on the matter are that since bridges are query-able now
> directly, getting the list of participants from the bridge makes more sense
> than trying to get the participants based on a single channel in that
> bridge. In addition, the code places a hard limit on the number of channel
> names it will actually put in the BRIDGEPEER variable. The code currently
> has a #define that makes it so that only the first 11 channels in the
> bridge will have their names in BRIDGEPEER. Because of the hard-coded
> maximum, if you have more than 11 channels in the bridge, you can't get the
> full list of participants using BRIDGEPEER.
>

Relying on BRIDGEPEER for only two party bridges will break down when you
consider that
ad-hock multi-party bridges are now allowed.  A bridge may start out being
two party but wind up
with multiple participants due to the DTMF transfer feature allowing
ad-hock multi-party bridges.

The upper limit of 11 is bowing to reality that BRIDGEPEER is not a good
way to get participants
for larger multi-party bridges.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Channel Issue with 13.10 and app_queue

[Richard Mudgett]

On Thu, Aug 4, 2016 at 11:12 AM, Ryan Rittgarn 
wrote:

> Hi Everyone, long time reader, first time poster in this particular
> thread. I'm one of the holdouts still using chan_sip for day to day uses as
> I have too many applications and implementations that rely on it. That
> being said I think I have found a bug, but am not sure the best way to go
> about isolating it to specific code changes, but I'd love to help any way I
> can.
>
> We recently (today) just upgraded a test box from 13.4 to 13.10. We
> process inbound calls through app_queue and then use one of our apps that
> issues a redirect via AMI to direct the channel to a parking extension, or
> more specifically an extension in dialplan that calls the Park()
> application. Up until now our behavior was such that when an agent of the
> queue parked the call, the agent's channel would be destroyed upon parking
> (as expected) and the caller's channel would show bridged with app_park in
> core show channels. Now as part of our application also keeps tabs on who
> is on the phone via AMI events, we noticed that when a call comes in
> through the queue, the original agent's channel stays up until caller is
> done with the call and hangs up. We use the queues for our triage people,
> and then pass through to support staff via picking up parked calls, so some
> of these calls can be lengthy. Upon further investigation doing core show
> channels I show that the original agent's channel still shows up, but I
> cannot issue the channel request hangup command without error. It tab
> completes and everything to the full channel, but when I hit enter, I get a
> 'not found' message.
>

That agent channel hanging around sounds like a channel ref leak or
something still has
a reference to the channel that they won't let go until the call the agent
channel was
involved with hangs up.  (You actually confirm this in your description.)
I expect that the
lingering channel has already been hung up since you got a channel not
found when you
tried to hang it up.  The channel is still visible in the stasis channel
cache because a
reference to the channel still exists but the channel is actually hung up.

I suspect that it is app_queue that has the lingering channel reference for
its queue_log.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Development of asterisk 1.4.23 Can we please get some development?

[Richard Mudgett]

On Fri, Jul 15, 2016 at 5:50 PM, Loren Tedford 
wrote:

> Some how you all wound up in my spam folder gotta love it i have been very
> busy had a big mistake on my end never chown -Rf apache:apache /var/ lol..
> oops i guess we all make a mistake every now and then..
>
> Anyway back to topic I have tried just baby steps I have not tried 1.8 to
> be exact because it is way to far away for our stuff to work i think..
>

The last version of v1.4 was v1.4.44 which is quite a few revisions after
v1.4.23.

app_rtp was removed just before v1.8 was released.  Before it was removed
there were
some changes made to it when other parts of the system changed.  Those
changes
were made as an untested best effort and mostly just to keep it compiling.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk Load Performance

[Richard Mudgett]

On Tue, Jul 5, 2016 at 4:03 PM, Jonathan Rose <
jonathan.r...@motorolasolutions.com> wrote:

>
> On Tue, Jul 5, 2016 at 3:43 PM, Michael Petruzzello <
> michael.petruzze...@civi.com> wrote:
>
>> On Wed, Jun 29 at 11:14:04 AM, Richard Mudgett> <https://urldefense.proofpoint.com/v2/url?u=http-3A__digium.com=CwMFaQ=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=RzNw4lQyfY2yXT49Ylv_v1goTGLiuwUxFtihFJb5GAs=P78xn7-C1l6ETO4vrsRQlsDcWLZFaEJEG71kAzrXHOU=>>
>> wrote:
>> > Each softmix bridge has only one thread performing all of the media
>> mixing
>> > for the bridge.  To
>> > get better mixing performance for such a large conference, you will
>> need to
>> > create several
>> > softmix bridges in a hierarchy with the bridges linked by local
>> channels.
>>
>> A bridge is only able to handle around 2000-2500 channels, so I created
>> 15 bridges with 14 channels bridging the bridges together.
>>
>> When doing this an error I see a lot is WARNING[98920]: channel.c:1101
>> __ast_queue_frame: Exceptionally long voice queue length queuing to
>> Local/**@default-;2, which then turns into WARNING[47525]:
>> pjproject:0 :  sip_transactio .Unable to register INVITE transaction
>> (key exists) and ERROR[47525]: res_pjsip.c:2777 ast_sip_create_dialog_uas:
>> Could not create dialog with endpoint sippeer. Object already exists
>> (PJ_EEXISTS). Finally the following repeats over and over again, [Jun 30
>> 12:22:21] ERROR[84189][C-0958]: netsock2.c:305 ast_sockaddr_resolve:
>> getaddrinfo("domain.name
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__domain.name=CwMFaQ=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=RzNw4lQyfY2yXT49Ylv_v1goTGLiuwUxFtihFJb5GAs=0TFQxSqdacQKRz5CbZtpR8WMsE1K1ZdgwZDCoWQPAnU=>",
>> "(null)", ...): Temporary failure in name resolution
>> [Jun 30 12:22:21] WARNING[84189][C-0958]: acl.c:800 resolve_first:
>> Unable to lookup 'domain.name
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__domain.name=CwMFaQ=q3cDpHe1hF8lXU5EFjNM_A=50uagQBTpQAKCx3KjAwJcMd6ygCPToAyDAxH5npANtf7nLmyZ65ofHGUgyJr9BW8=RzNw4lQyfY2yXT49Ylv_v1goTGLiuwUxFtihFJb5GAs=0TFQxSqdacQKRz5CbZtpR8WMsE1K1ZdgwZDCoWQPAnU=>
>> '.
>>
>
The exceptionally long voice queue length messages can be a symptom of
thread
starvation as the Local channels frame queue has developed an excessive
backlog.

The forthcoming v13.10.0 release should indirectly take care of the EEXISTS
messages
as part of the https://issues.asterisk.org/jira/browse/ASTERISK-26088 fix.
Working on
that issue I saw the EEXISTS messages for REGISTER and SUBSCRIBE message
processing.  The issue was a result of the original message and
retransmissions getting
backlogged in the serializer/taskprocessor and responses sent using another
serializer.

Looks like your system's DNS resolver has gotten overwhelmed.


>
>> The last error just keeps on repeating and calls can no longer join (only
>> around 3,500 make it on before this starts to occur). Calling in manually I
>> receive an "all circuits are busy" message.
>>
>> I'm going to try halving the number of bridges, but is there anything
>> else I can do to improve performance? This seems to be the last hurdle to
>> use one server for 10,000 callers.
>>
>
> If you don't need all of your participants actually to be speaking at a
> time (and I hope not with that kind of volume), you could use holding
> bridges for the vast majority of the partipants. Link the bridges using a
> local channel with the Hold bridge side being set to use the 'announcer'
> bridge role and the hold bridge will effectively just be voiceless
> conference participants. If you want, you can listen for DTMF events to
> move the participants back and forth between the different bridges.
>

Wow.  Thanks Jonathan.  I hadn't thought of doing it that way.  That should
really drop the mixing load.
Probably should allow only ulaw or alaw (pick one) for all participants to
minimize translation costs.
One additional thing I should add is that those linking Local channel
bridges should just allow the
chosen alaw/ulaw to reduce translation to each participant in the holding
bridge.  The forthcoming
v13.10.0 adds the ability to specify formats when ARI originates a channel
(Local in this case) and
an originator channel is not available.  (See CHANGES file)

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk Load Performance

[Richard Mudgett]

On Wed, Jun 29, 2016 at 9:55 AM, Michael Petruzzello <
michael.petruzze...@civi.com> wrote:

> It is very interesting how threading issues on both a stasis application
> and Asterisk escalate each other. Using 15 websockets in one stasis
> application and removing all thread locking from the application have made
> the ARI messages flow smoothly. Right now I am using about 900 threads to
> process messages from Asterisk and Asterisk has at least 320 in stasis,
> though that can increase to infinity.
>
> I have also disabled the channel_varset from stasis because it becomes
> really unwieldy. When having thousands of callers in a bridge, every time a
> channel is added to a bridge or removed, every channel receives a channel
> var set message because of the BridgePeer variable.
>
> As of now, I have two remaining problems:
>
> 1. At around having 5,000 channels in a bridge (whether majority are muted
> or not), the audio breaks down. Anyone talking can only be heard in 3
> second bursts approximately every 5-10 seconds. At 10,000 channels only
> static can be heard in these 3 second bursts.
>
> Is there anything I can optimize so that Asterisk can handle all these
> channels in a bridge?
>

Each softmix bridge has only one thread performing all of the media mixing
for the bridge.  To
get better mixing performance for such a large conference, you will need to
create several
softmix bridges in a hierarchy with the bridges linked by local channels.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] ASTERISK-26145 - Task Process Issues possibly caused by HEP

[Richard Mudgett]

On Tue, Jun 28, 2016 at 10:20 AM, Ross Beer  wrote:

> Hi,
>
>
> I agree that the conversation about HEP default settings doesn't warrant a
> lengthy discussion, however, the fact that the 'task processor' causes
> asterisk to stop processing packets is a serious issue. This is happening
> multiple times a day on several boxes.
>
>
> I'm trying to identify what is causing over 1500 tasks to back-up in the 
> 'subm:rtp_topic-00de'
> scheduler. This is proving difficult as you only see counts and not actual
> waiting tasks.
>

The res_hep_rtcp.so module is what creates the subm:rtp_topic stasis
message bus subscription.  Since you have indicated that you are not using
that feature you should not load the module.

The taskprocessors that begin with 'subm:' (m for mailbox) or 'subp:' (p
for thread pool) are stasis message bus subscriptions.  The 'subm:'
taskprocessors have a single dedicated thread to process the taskprocessor
tasks.  The 'subp:' taskprocessors do not have a dedicated thread.  Those
taskprocessors get executed by an available thread from the stasis thread
pool.  The stasis thread pool is configured by the stasis.conf file.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk Load Performance

[Richard Mudgett]

On Tue, Jun 21, 2016 at 11:12 AM, Michael Petruzzello <
michael.petruzze...@civi.com> wrote:

> >On Fri, Jun 17, 2016 at 1:37 PM, Richard Mudgett <rmudg...@digium.com>
> wrote:
> >>
> >>
> >> On Fri, Jun 17, 2016 at 12:36 PM, Michael Petruzzello
> >> <michael.petruzze...@civi.com> wrote:
> >>>
> >>> Hello,
> >>>
> >>> I am currently working on determining bottlenecks in Asterisk and a
> Stasis
> >>> App. I'm currently trying to handle 83.3 calls/second. For the most
> part,
> >>> Asterisk and the Stasis APP handle that well, but there is a 60+ second
> >>> delay in response time.
> >>>
> >>> On the Asterisk side, I am seeing the following warnings. [Jun 17
> >>> 12:00:16] WARNING[23561]: taskprocessor.c:803 taskprocessor_push: The
> >>> 'subm:cdr_engine-0003' task processor queue reached 500 scheduled
> tasks.
> >>> [Jun 17 12:00:18] WARNING[25477][C-0068]: taskprocessor.c:803
> >>> taskprocessor_push: The 'subm:devService-test-0038' task processor
> queue
> >>> reached 500 scheduled tasks.
> >>> [Jun 17 12:00:21] WARNING[26298][C-00a3]: taskprocessor.c:803
> >>> taskprocessor_push: The 'subp:PJSIP/sippeer-0022' task processor
> queue
> >>> reached 500 scheduled tasks.
> >>> [Jun 17 12:00:23] WARNING[27339][C-010d]: taskprocessor.c:803
> >>> taskprocessor_push: The 'subm:ast_channel_topic_all-cached-0032'
> task
> >>> processor queue reached 500 scheduled tasks.
> >>> [Jun 17 12:01:32] WARNING[31697][C-03b2]: taskprocessor.c:803
> >>> taskprocessor_push: The 'subm:ast_channel_topic_all-0036' task
> processor
> >>> queue reached 500 scheduled tasks.
> >>> [Jun 17 12:05:55] WARNING[23280]: taskprocessor.c:803
> taskprocessor_push:
> >>> The 'SIP' task processor queue reached 500 scheduled tasks.
> >>>
> >>> I have not seen a configuration setting on Asterisk to prevent these
> >>> warnings from occurring (I'm trying to avoid modifying Asterisk source
> code
> >>> if possible). Looking at the task processors, I see the queue to the
> stasis
> >>> app bottlenecks:
> >>> subm:devService-test-00384560990  0
> >>> 1041689. It does clear up relatively quickly. The CDR engine also
> bottle
> >>> necks (extremely badly), but I don't use that. Nothing else comes
> close to
> >>> having a large queue.
> >>>
> >>> The stasis app itself is extremely streamlined and is very capable of
> >>> handling a large number of messages at a time. The app runs with the
> JVM so
> >>> I am also researching into that as well as the netty library I am
> using for
> >>> the websocket connections.
> >>>
> >>> Any insight into Asterisk's side of the equation and how it scales on
> 40
> >>> vCPUs would be greatly appreciated.
> >>
> >>
> >> There are no options to disable those taskprocessor queue size warnings.
> >> They are a
> >> symptom of the system being severely stressed.  If the stress continues
> it
> >> is possible
> >> that the system could consume all memory in those taskprocessor queues.
> >>
> >> Recent changes to the Asterisk v13 branch were made to help throttle
> back
> >> incoming
> >> SIP requests on PJSIP when the taskprocessors become backlogged like
> you are
> >> seeing.
> >> These changes will be in the forthcoming v13.10.0 release.  If you
> want, you
> >> can test with
> >> the current v13 branch to see how these changes affect your stress
> testing.
> >>
> >> If you don't need CDR's then you really need to disable them as they
> consume
> >> a lot of
> >> processing time and the CDR taskprocessor queue backlog can take
> minutes to
> >> clear.
> >>
> >
> >To echo what Richard said, because Asterisk is now sharing state
> >across the Stasis message bus, turning off subscribers to that bus
> >will help performance. Some easy ones to disable, if you aren't using
> >them, are CDRs, CEL, and AMI. Those all do a reasonable amount of
> >processing, and you can get some noticeable improvement by disabling
> >them.
> >
> >Once you get past that, you can start fiddling with some of the lower
> >level options. To start, you can throttle things back further by
> >disabling certain i

Re: [asterisk-dev] Asterisk Load Performance

[Richard Mudgett]

On Fri, Jun 17, 2016 at 12:36 PM, Michael Petruzzello <
michael.petruzze...@civi.com> wrote:

> Hello,
>
> I am currently working on determining bottlenecks in Asterisk and a Stasis
> App. I'm currently trying to handle 83.3 calls/second. For the most part,
> Asterisk and the Stasis APP handle that well, but there is a 60+ second
> delay in response time.
>
> On the Asterisk side, I am seeing the following warnings. [Jun 17
> 12:00:16] WARNING[23561]: taskprocessor.c:803 taskprocessor_push: The
> 'subm:cdr_engine-0003' task processor queue reached 500 scheduled tasks.
> [Jun 17 12:00:18] WARNING[25477][C-0068]: taskprocessor.c:803
> taskprocessor_push: The 'subm:devService-test-0038' task processor
> queue reached 500 scheduled tasks.
> [Jun 17 12:00:21] WARNING[26298][C-00a3]: taskprocessor.c:803
> taskprocessor_push: The 'subp:PJSIP/sippeer-0022' task processor queue
> reached 500 scheduled tasks.
> [Jun 17 12:00:23] WARNING[27339][C-010d]: taskprocessor.c:803
> taskprocessor_push: The 'subm:ast_channel_topic_all-cached-0032' task
> processor queue reached 500 scheduled tasks.
> [Jun 17 12:01:32] WARNING[31697][C-03b2]: taskprocessor.c:803
> taskprocessor_push: The 'subm:ast_channel_topic_all-0036' task
> processor queue reached 500 scheduled tasks.
> [Jun 17 12:05:55] WARNING[23280]: taskprocessor.c:803 taskprocessor_push:
> The 'SIP' task processor queue reached 500 scheduled tasks.
>
> I have not seen a configuration setting on Asterisk to prevent these
> warnings from occurring (I'm trying to avoid modifying Asterisk source code
> if possible). Looking at the task processors, I see the queue to the stasis
> app bottlenecks:
> subm:devService-test-00384560990  0
> 1041689. It does clear up relatively quickly. The CDR engine also bottle
> necks (extremely badly), but I don't use that. Nothing else comes close to
> having a large queue.
>
> The stasis app itself is extremely streamlined and is very capable of
> handling a large number of messages at a time. The app runs with the JVM so
> I am also researching into that as well as the netty library I am using for
> the websocket connections.
>
> Any insight into Asterisk's side of the equation and how it scales on 40
> vCPUs would be greatly appreciated.
>

There are no options to disable those taskprocessor queue size warnings.
They are a
symptom of the system being severely stressed.  If the stress continues it
is possible
that the system could consume all memory in those taskprocessor queues.

Recent changes to the Asterisk v13 branch were made to help throttle back
incoming
SIP requests on PJSIP when the taskprocessors become backlogged like you
are seeing.
These changes will be in the forthcoming v13.10.0 release.  If you want,
you can test with
the current v13 branch to see how these changes affect your stress testing.

If you don't need CDR's then you really need to disable them as they
consume a lot of
processing time and the CDR taskprocessor queue backlog can take minutes to
clear.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Config reading and scanf with large numbers

[Richard Mudgett]

On Wed, Jun 1, 2016 at 5:25 AM, snuffy  wrote:

> Hello All,
>
> I noticed a bug report ASTERISK-25972,
>

The referenced issue has nothing to do with what you are talking about.


>
> Looking through the code we do the following:
>
> sscanf(string,"%30d",_int);
>
> Now issue is an integer can't hold a number of 30 digits in length, 32bit
> ints are safe with 9, and 64bit with 19.
>
> If we set a value of %9d, if there are any more digits after the first 9
> they will be lost but we know the value will be inside the range of an
> integer.
>
> For single value scans, like reading from config files we could 'mitigate'
> by checking the strlen of the value we intend to read before running scanf,
> if return is >9, emit a warning stating their value will be truncated and
> read only the first 9 characters into the integer.
>
> If we use just %d, followed by %n we can see how many characters have been
> consumed, if we determine that it would be too large, emit a warning
> stating that the value is most likely incorrect.
>
>
> Am I barking up the wrong tree? thoughts?
>

The reason Asterisk uses sscanf format specifiers like "%30d" is because of
the AST-2009-005 security issue
where a bug in libc allowed an attacker to crash Asterisk by supplying a
ridiculously long string of digits in a
SIP message and blow the stack.

As far as reading config files with excessively long integers, garbage in
gives garbage out.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Add .gitignore (libss7[master])

[Richard Mudgett]

Richard Mudgett has uploaded a new change for review.

  https://gerrit.asterisk.org/2421

Change subject: Add .gitignore
..

Add .gitignore

Change-Id: I068e59b57102551e3ef7c10eb5774ac071a7c5b6
---
A .gitignore
1 file changed, 11 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/libss7 refs/changes/21/2421/1

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..ad4dc18
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,11 @@
+*.o
+*.o.d
+*.lo
+*.so
+*.a
+libss7.so.*
+parser_debug
+ss7linktest
+ss7test
+version.c
+

-- 
To view, visit https://gerrit.asterisk.org/2421
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I068e59b57102551e3ef7c10eb5774ac071a7c5b6
Gerrit-PatchSet: 1
Gerrit-Project: libss7
Gerrit-Branch: master
Gerrit-Owner: Richard Mudgett <rmudg...@digium.com>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Add .gitignore (libpri[1.4])

[Richard Mudgett]

Richard Mudgett has uploaded a new change for review.

  https://gerrit.asterisk.org/2423

Change subject: Add .gitignore
..

Add .gitignore

Change-Id: I11ac3b47a9d5d0a0c1ea4559280b75ef5d866d62
---
A .gitignore
1 file changed, 12 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/libpri refs/changes/23/2423/1

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..78b897b
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,12 @@
+*.o
+*.o.d
+*.lo
+*.so
+*.a
+libpri.so.*
+pridump
+pritest
+rosetest
+testprilib
+version.c
+

-- 
To view, visit https://gerrit.asterisk.org/2423
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I11ac3b47a9d5d0a0c1ea4559280b75ef5d866d62
Gerrit-PatchSet: 1
Gerrit-Project: libpri
Gerrit-Branch: 1.4
Gerrit-Owner: Richard Mudgett <rmudg...@digium.com>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] q931.c: Substitute PROGRESS for DISCONNECT with progress ind... (libpri[1.4])

[Richard Mudgett]

Richard Mudgett has uploaded a new change for review.

  https://gerrit.asterisk.org/2425

Change subject: q931.c: Substitute PROGRESS for DISCONNECT with progress 
indicator #8
..

q931.c: Substitute PROGRESS for DISCONNECT with progress indicator #8

When the pri_set_inbanddisconnect() option is enabled and the call has not
been answered when a DISCONNECT with progress indicator #8 (Inband audio
present) is received, then report the event as a PROGRESS with progress
indicator #8 (Inband audio present) instead.  Substituting a PROGRESS
event allows the upper layer to open the media path if it isn't already
open so the user can hear the inband audio message.

PRI-180
Reported by: Alexandr Dranchuk

Change-Id: I62313bf9cc1d2f3b0231f0c07a784717ddba0415
---
M q931.c
1 file changed, 34 insertions(+), 1 deletion(-)


  git pull ssh://gerrit.asterisk.org:29418/libpri refs/changes/25/2425/1

diff --git a/q931.c b/q931.c
index 0e7ff79..69c210e 100644
--- a/q931.c
+++ b/q931.c
@@ -8726,6 +8726,7 @@
int res;
int changed;
int mand_cause;
+   enum Q931_CALL_STATE ourcallstate_orig;
struct apdu_event *cur = NULL;
struct pri_subcommand *subcmd;
struct q931_call *master_call;
@@ -9265,14 +9266,46 @@
}
}
 
+   ourcallstate_orig = c->ourcallstate;
UPDATE_OURCALLSTATE(ctrl, c, 
Q931_CALL_STATE_DISCONNECT_INDICATION);
c->peercallstate = Q931_CALL_STATE_DISCONNECT_REQUEST;
c->sendhangupack = 1;
 
/* wait for a RELEASE so that sufficient time has passed
   for the inband audio to be heard */
-   if (ctrl->acceptinbanddisconnect && (c->progressmask & 
PRI_PROG_INBAND_AVAILABLE))
+   if (ctrl->acceptinbanddisconnect
+   && (c->progressmask & PRI_PROG_INBAND_AVAILABLE)) {
+   switch (ourcallstate_orig) {
+   case Q931_CALL_STATE_CALL_INITIATED:
+   case Q931_CALL_STATE_OVERLAP_SENDING:
+   case Q931_CALL_STATE_OUTGOING_CALL_PROCEEDING:
+   case Q931_CALL_STATE_CALL_DELIVERED:
+   /*
+* Open the media path if it isn't already open 
so
+* the user can hear the inband audio.
+*/
+   if (ctrl->debug & PRI_DEBUG_Q931_STATE) {
+   pri_message(ctrl, "Report the 
DISCONNECT as a PROGRESS instead.\n");
+   }
+   ctrl->ev.e = PRI_EVENT_PROGRESS;
+   ctrl->ev.proceeding.cause = c->cause;
+   ctrl->ev.proceeding.subcmds = >subcmds;
+   ctrl->ev.proceeding.channel = 
q931_encode_channel(c);
+   ctrl->ev.proceeding.progress = c->progress;
+   ctrl->ev.proceeding.progressmask = 
c->progressmask;
+   ctrl->ev.proceeding.cref = c->cr;
+   ctrl->ev.proceeding.call = c->master_call;
+   return Q931_RES_HAVEEVENT;
+   default:
+   break;
+   }
+   /*
+* Suppress reporting DISCONNECT to the upper layer.  
The
+* media path should already be open and we cannot 
report
+* a PROGRESS at this time anyway.
+*/
break;
+   }
 
/* Return such an event */
ctrl->ev.e = PRI_EVENT_HANGUP_REQ;

-- 
To view, visit https://gerrit.asterisk.org/2425
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I62313bf9cc1d2f3b0231f0c07a784717ddba0415
Gerrit-PatchSet: 1
Gerrit-Project: libpri
Gerrit-Branch: 1.4
Gerrit-Owner: Richard Mudgett <rmudg...@digium.com>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Add .gitignore (libpri[master])

[Richard Mudgett]

Richard Mudgett has uploaded a new change for review.

  https://gerrit.asterisk.org/2424

Change subject: Add .gitignore
..

Add .gitignore

Change-Id: I11ac3b47a9d5d0a0c1ea4559280b75ef5d866d62
---
A .gitignore
1 file changed, 12 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/libpri refs/changes/24/2424/1

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..78b897b
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,12 @@
+*.o
+*.o.d
+*.lo
+*.so
+*.a
+libpri.so.*
+pridump
+pritest
+rosetest
+testprilib
+version.c
+

-- 
To view, visit https://gerrit.asterisk.org/2424
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I11ac3b47a9d5d0a0c1ea4559280b75ef5d866d62
Gerrit-PatchSet: 1
Gerrit-Project: libpri
Gerrit-Branch: master
Gerrit-Owner: Richard Mudgett <rmudg...@digium.com>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Add .gitignore (libss7[2.0])

[Richard Mudgett]

Richard Mudgett has uploaded a new change for review.

  https://gerrit.asterisk.org/2420

Change subject: Add .gitignore
..

Add .gitignore

Change-Id: I068e59b57102551e3ef7c10eb5774ac071a7c5b6
---
A .gitignore
1 file changed, 11 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/libss7 refs/changes/20/2420/1

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..ad4dc18
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,11 @@
+*.o
+*.o.d
+*.lo
+*.so
+*.a
+libss7.so.*
+parser_debug
+ss7linktest
+ss7test
+version.c
+

-- 
To view, visit https://gerrit.asterisk.org/2420
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I068e59b57102551e3ef7c10eb5774ac071a7c5b6
Gerrit-PatchSet: 1
Gerrit-Project: libss7
Gerrit-Branch: 2.0
Gerrit-Owner: Richard Mudgett <rmudg...@digium.com>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Add .gitignore (libss7[1.0])

[Richard Mudgett]

Richard Mudgett has uploaded a new change for review.

  https://gerrit.asterisk.org/2422

Change subject: Add .gitignore
..

Add .gitignore

Change-Id: I068e59b57102551e3ef7c10eb5774ac071a7c5b6
---
A .gitignore
1 file changed, 11 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/libss7 refs/changes/22/2422/1

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..ad4dc18
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,11 @@
+*.o
+*.o.d
+*.lo
+*.so
+*.a
+libss7.so.*
+parser_debug
+ss7linktest
+ss7test
+version.c
+

-- 
To view, visit https://gerrit.asterisk.org/2422
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I068e59b57102551e3ef7c10eb5774ac071a7c5b6
Gerrit-PatchSet: 1
Gerrit-Project: libss7
Gerrit-Branch: 1.0
Gerrit-Owner: Richard Mudgett <rmudg...@digium.com>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] q931.c: Fix DISCONNECT Progress Indicator ie handling. (libpri[1.4])

[Richard Mudgett]

Richard Mudgett has uploaded a new change for review.

  https://gerrit.asterisk.org/2426

Change subject: q931.c: Fix DISCONNECT Progress Indicator ie handling.
..

q931.c: Fix DISCONNECT Progress Indicator ie handling.

There are two scenarios that are exposed by DISCONNECT not initializing
the progress indicator value before processing the message when the
chan_dahdi.conf inbanddisconnect=yes option is set.

1) If a DISCONNECT comes in without a Progress Indicator ie and an earlier
message (such as SETUP-ACKNOWLEDGE or PROCEEDING) came in with the
indicator #8 (Inband audio present) then the DISCONNECT would not cause an
immediate hangup.  We would be letting the user hear the inband audio even
though there isn't any.

2) If a DISCONNECT message comes in with the indicator #8 (Inband audio
present) and then later the DISCONNECT message is repeated without a
Progress Indicator ie we would still ignore the second DISCONNECT to let
the user hear inband audio even though it likely isn't there anymore.

PRI-180 #close
Reported by: Alexandr Dranchuk

Change-Id: Ic88aafb45053146b5701d666e6212f773624
---
M q931.c
1 file changed, 2 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/libpri refs/changes/26/2426/1

diff --git a/q931.c b/q931.c
index 69c210e..52afb3c 100644
--- a/q931.c
+++ b/q931.c
@@ -7381,6 +7381,8 @@
c->cause = -1;
c->causecode = -1;
c->causeloc = -1;
+   c->progress = -1;
+   c->progressmask = 0;
c->aoc_units = -1;
pri_schedule_del(ctrl, c->retranstimer);
c->retranstimer = 0;

-- 
To view, visit https://gerrit.asterisk.org/2426
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Ic88aafb45053146b5701d666e6212f773624
Gerrit-PatchSet: 1
Gerrit-Project: libpri
Gerrit-Branch: 1.4
Gerrit-Owner: Richard Mudgett <rmudg...@digium.com>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 13.7.0 app PAGE plays participant count

[Richard Mudgett]

On Wed, Jan 27, 2016 at 6:35 PM, Ross Beer  wrote:

>
>  Hi,
>
> I'm having an issue with the PAGE feature in Asterisk 13.7.0, when
> connecting a PAGE it says 'there is only one other participant in the
> conference'.
>
> This shouldn't be happening, I know that PAGE used ConfBridge however it
> should only use this to bridge the call.
>
> The options I am using are as follows:
>
>
> Page(,ni)
>
>
> The options should suppress any messages however this is not the case. Is
> this currently a bug with the PAGE feature?
>

Page is using the default_bridge profile of confbridge.  So you need to
configure
that profile to not announce the number of participants.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] How to use a DAHDI kernel driver in linux using The Bridging Framework Tecnology in the Asterisk 13

[Richard Mudgett]

On Wed, Jan 6, 2016 at 6:27 AM, Diógenes Vila Nova Pereira <
d...@cesar.org.br> wrote:

> Hi Folks,
>
> I'm newbie in Asterisk developement tecnology. I had read and seen
> documentation that the Asterisk supports new bridging framework tecnology
> that has a pluggable interface, allowing a native bridging to be written in
> a separate module and selected based on criteria it presents to the core.
>
> I have a scenary that following this way: I have a PABX where there's a
> digital matrix controled by DSP card that controls the TDM networks
> channels commutation between cards FX0, FXS, E1 and Media Gateway for RTP
> audio.
>
> How to configure the Asterisk and what level implement/modify/customize a
> DAHDI kernel module that does possible to use Asterisk by a native bridge
> to control and permit two audio channels commutes direct by DSP without the
> interference and just so to monitor this until hangup complete of calling
> by the Asterisk.
>

I think you are mixing up the various software layers involved.  Since you
are talking about
implementing a DAHDI kernel module you need to follow the rules within
DAHDI to implement
your native bridge.  There is already an Asterisk level native DAHDI bridge
technology
implemented that uses the DAHDI API to setup the native bridge.

1) Asterisk bridging framework where channels can freely be moved between
bridges.
2) Asterisk bridging technology (holding, simple, softmix, native_rtp,
native_DAHDI) - The technology determines how media frames are exchanged
between channels.
3) DAHDI itself (Directly interfaces with hardware.)

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Bridges, T.38, and other good times

[Richard Mudgett]

On Sun, Dec 6, 2015 at 7:57 PM, Matthew Jordan  wrote:

> Hello all -
>
> One of the efforts that a number of developers in the community here at
> Digium have been at work at are cleaning up test failures exposed by
> Jenkins [1]. One of these, in particular, has been rather difficult to
> resolve - namely, fax/pjsip/directmedia_reinvite_t38 [2]. This e-mail goes
> over what has been accomplished, and asks some questions on how we might
> try and fix Asterisk under this scenario.
>
> The directmedia_reinvite_t38 test attempts to do the following:
>  (1) UAC1 calls UAC2 through Asterisk, with audio as the media. The dial
> is performed using the 'g' flag, such that UAC2 will continue on if UAC1
> hangs up.
>  (2) UAC1 and UAC2 are configured for direct media. Asterisk sends a
> re-INVITE to UAC1 and UAC2 to initiate direct media.
>  (3) After responding with a 200 OK to the direct media requests, UAC1
> sends a re-INVITE offering T.38.
>  (4) Asterisk sends an INVITE with T.38 to UAC2
>  (5) UAC2 sends back a 200 OK for T.38; Asterisk sends that to UAC1.
> Asterisk switches out of a direct media bridge to a core bridge.
>  (6) UAC1 hangs up. Asterisk sends a re-INVITE to UAC2 for audio back to
> Asterisk. UAC2 responds with a 200 OK for the audio.
>  (7) Asterisk ejects UAC2 back to the dialplan.
>
> It's important to note that this test never should have passed - an update
> to the test suite "fixed" the test erroneously passing, which led to us
> investigating why the scenario was failing. This test was copied over from
> an identical chan_sip test, which passes.
>
> The PJSIP stack has two issues which make life difficult for it in this
> scenario:
> (1) The T.38 logic is implemented in res_pjsip_t38. While that is _mostly_
> a very good thing - as it keeps all the fax state logic outside of the
> channel driver - we are also a layer removed from interactions that occur
> in the channel driver. That makes it challenging to influence direct media
> checks and other Asterisk/channel interactions.
> (2) Being very asynchronous, requests may be serviced that influence T.38
> state while other interactions are occurring in the core. Informing the
> core of what has occurred can have more race conditions than what occurs in
> chan_sip, which is single threaded.
>
> The first bug discovered when the test was investigated was an issue in
> step (2). We never actually initiated a direct media re-INVITE. This was
> due to res_pjsip_t38 using a frame hook, and not implementing the
> .consume_cb callback. That callback allows a framehook to inform the core
> (and also the bridging framework) of the types of frames that a framehook
> wants to consume. If a framehook needs audio, a direct media bridge will be
> explicitly denied, and - by default - the bridging framework assumes that
> framehooks will want all frames. Another bug that was discovered occurred
> in step (6). When UAC1 sends a BYE request, nothing informed UAC2 that the
> fax had ended - instead, it was merely ejected from the bridge. This meant
> that it kept its T.38 session going, and Asterisk never sent a re-INVITE to
> UAC2. Both of these bugs were fixed by 726ee873a6.
>
> Except, unfortunately, the second bug wasn't really fixed.
>
> 726ee873a6 did the "right" thing by intercepting the BYE request sent by
> UAC1, and queueing up a control frame of type AST_CONTROL_T38_PARAMETERS
> with a new state of AST_T38_TERMINATED. This is supposed to be passed on to
> UAC2, informing it that the T.38 fax has ended, and that it should have its
> media re-negotiated back to the last known state (audio) but also back to
> Asterisk (since we aren't going to be in a bridge any longer).
> Unfortunately, this code was insufficient.
>
> A race condition exists in this case. On the one hand, we've just queued
> up a frame on UAC1's channel to be passed into the bridge, which should get
> tossed onto UAC2's channel. On the other hand, we've just told the bridging
> framework to kill UAC1's channel with extreme prejudice, thereby also
> terminating the bridge and ejecting UAC2 off into the dialplan. In the
> first case, this is an asynchronous, message passing mechanism; in the
> second case, the bridging framework inspects the channel to see if it
> should be hung up on *every frame* and *immediately* starts the
> hangup/shutdown procedure if it knows the channel should die. This is not
> asynchronous in any way. As a result, UAC1 may be hung up and the bridge
> dissolved before UAC2 ever gets its control frame from UAC1.
>
> There were a couple of solutions to this problem that were tried:
> (1) First, I tried to make sure that enqueued control frames were flushed
> out of a channel and passed over the bridge when a hangup was detected. In
> practice, this was incredibly cumbersome - some control frames should get
> tossed, others need to be preserved. What was worse was the sheer number of
> places the bridge dissolution can be triggered. While 

Re: [asterisk-dev] Proposing change to Queue and missed calls behavior

[Richard Mudgett]

On Wed, Dec 9, 2015 at 2:06 AM, Stian Hvatum  wrote:

> On 12/07/2015 05:02 PM, Olle E. Johansson wrote:
>
>> On 07 Dec 2015, at 16:53, Mark Michelson  wrote:
>>>
>>> On 12/04/2015 01:00 PM, Stian Hvatum wrote:
>>>
 Hi,
 I have a problem with an accompanying solution that I wish to share,
 but I am not sure if it is valuable enough or correct enough to be
 suggested as a patch to Asterisk.

 When SIP-phones are members of a queue, they tend to accumulate "missed
 calls" unless the C-flag is applied. When the C-flag is applied there is no
 missed calls at all, since all hangups are marked as "answered elsewhere".
 I have created and attached a patch which makes the C-flag "answer
 elsewhere" all hangups that are caused by app_queue canceling the dial or
 the call is really answered elsewhere, but sets normal cause when caller
 actually hangs up before the call is answered.

 I know the patch alters the behavior of the C-flag, and altering
 behavior of existing flags is probably a bad thing. I can try to create a
 new flag for this "missed call on caller hangup"-behavior if that is of any
 value. Also, I don't have much experience with the Asterisk source code, so
 if I break something by setting normal cause here I would be very happy if
 anyone would give me a hint about it. The only problem I have seen so far
 is that if the caller hangs up during an announcement or between
 app_queue's dial outs, the call is not marked as missed (as the previous
 call was "answered elsewhere" and no new calls went out to the phones).

 The code is running a few places without causing any trouble as far as
 I can tell. I wrote this after a customer had a few thousand missed calls
 on his queue-connected phone...

 Best regards and thanks for a great project!
 Stian Hvatum

>>> In my opinion, if the c-flag is set and the caller hangs up, you are
>>> correct that the "answered elsewhere" status should not be applied. I also
>>> think the "answered elsewhere" status should not be applied if a call to a
>>> single queue member times out before the member answers the call. The
>>> c-flag behavior should only be applied when multiple queue members' phones
>>> are ringing at the same time, and Asterisk has to cancel the outgoing call
>>> to certain members due to the call being answered by someone else.
>>>
>>> I think the change you are suggesting would be welcome.
>>>
>> Mark,
>> That was not the idea when I wrote it. (If I remember correctly). The
>> case was that the phone should NEVER show any queue calls as missed,
>> regardless of why.
>>
>> This behaviour is still useful - to separate personal calls that require
>> callback from calls that doesn’t require call back (i.e. calls from the
>> queue).
>>
>> I like the idea with a new option.
>>
>> /O
>>
>
> Thanks for comments.
> As Olle writes, there are many cases where a call never should be shown as
> missed. I think it might be better to implement a new option, then it at
> least won't hurt any one relying on the current behavior. Are there any
> naming schemes for these options, or can I use e.g. "M" for "only show call
> as Misse when first caller in line hangs up"?
>
> If I want to commit this as a new option upstream, should I also write
> some sort of unit test or regression test?
>

These links will answer your questions:

https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process
https://wiki.asterisk.org/wiki/display/AST/New+Feature+Guidelines

Basically it is a good idea to have either a testsuite test or unit test
whichever is appropriate.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] pjsip vs cel

[Richard Mudgett]

On Wed, Jun 10, 2015 at 6:22 PM, James Cloos cl...@jhcloos.com wrote:

 I've finally gotten a box setup with pjsip.

 I see that the CHAN_START cel event logs exten='s', context='default'
 instead of the INVITEd extension and the endpoint's context.

 All of the rest of the events log the expected data.

 This is unlike chan_sip.

 Is this a bug?  Or an expected behavorial difference beteen chan_sip and
 res_pjsip?

 For reference, this particular box does not have a context named
 default.  And I do not see any way to tell res_pjsip what the default
 context should be, like sip.conf's [general] section.


You can specify the dialplan context incoming calls go to when defining
the endpoint.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] (unreported) uninitialized: struct ast_sockaddr

[Richard Mudgett]

On Wed, May 13, 2015 at 3:59 AM, Alexander Traud pabstr...@compuserve.com
wrote:

  What you're proposing is a change to the semantics of ast_sockaddr.

 Not sure what you mean by semantics. Please, let us ignore ast_sockaddr for
 a second and see http://www.ex-parrot.com/~chris/random/initialise.html:


Semantics just mean how something has to be used.  You are changing the
semantics of ast_sockaddr by adding something that must be explicitly
released.
Whereas, before there was nothing that needed to be explicitly released so
nothing would need to be explicitly called to destroy the ast_sockaddr
instance.



 Currently, when a struct with automatic storage duration is created in
 Asterisk, it is initialized
 A) (correct) with {0},
 B) (questionable) via memset,
 C) (questionable) at first use, or
 D) (wrong) not at all.

 Is case D important enough to get fixed, at a whole, or partially. If
 partially, to which extend?

 Example 1:
 The *opaque* peercnt (channels/chan_iax2.c) contains ast_sockaddr and
 therefore has to be initialized correctly in my case to avoid a wild
 pointer. Actually, I am using chan_sip only, added a pointer to
 ast_sockaddr, cleaned memory, and my Asterisk was segfaulting in a complete
 different module (chan_iax2.c). [Offtopic: Yes, my modules.conf was wrong.]


struct peercnt is not opaque as the struct definition is visible to the code
using the structure.  If it were opaque you would only be able to create
pointer
variables to the struct and not instances of the struct itself.  The
compiler
cannot let you create an instance of struct peercnt if it does not know the
size
of it.

struct peercnt *pointer_to_peercnt;
struct peercnt instance_of_peercnt;



 Example 2:
 The *private* sip_peer (channels/sip/include/sip.h) contains pointers and
 is
 not initialized at all twice, at least (sip_peer tmp_peer). This creates
 wild pointers which segfaulted the pointer in my ast_sockaddr.


These particular uses of peercnt in chan_iax2.c and sip_peer in chan_sip.c
are
dummy objects with just enough fields filled in to perform an ao2_find().
Those
dummy objects are never destroyed so the uninitialized pointers are
irrelevant.
The coding pattern that creates a dummy object with the container key fields
filled in pre-dates the introduction of OBJ_SEARCH_KEY and the older name
OBJ_KEY.



 Asked differently:
 I have a diff/patch correcting just the struct-inits for 62 lines of code
 at
 54 places in 5 files, which affects my downstream code. Am I allowed to
 commit just that, although it does not address the issue at a whole (there
 are many more struct inits which stay wrong)?

 Or: Is my compiler configured incorrectly somehow, not setting pointers to
 (void *)0 automatically in structs with automatic storage duration?


I haven't seen a compiler that tracks uninitialized struct members.  You
should
make your addition as a char array rather than an allocated pointer to avoid
incompatibilities in unexpected places.  Otherwise, the semantic change
breaks code all over the place.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Contacts, Contact Status and Sorcery

[Richard Mudgett]

On Thu, Apr 30, 2015 at 2:10 PM, George Joseph george.jos...@fairview5.com
wrote:


 Change https://gerrit.asterisk.org/261 sparked some discussion about
 contacts and contact status so I'd like to continue that here.

 Today, dynamic contacts (incoming registrations) are created on the fly as
 full sorcery objects and stored in an astdb back-end so they survive a
 restart.  Permanent contacts however, are created on the fly as sorcery
 objects when the aor is created but instead of being managed by sorcery,
 are stored in an aor-specific container. Contact statuses for both types of
 contacts are created as full sorcery objects and stored in a memory
 back-end.  They obviously do not survive a restart.  This makes navigating
 the life-cycle of these objects a little convoluted.

 The handling of dynamic contacts is pretty straightforward and I have no
 issue there.  Permanent contacts are another matter however.  Because they
 aren't managed by sorcery, none of the sorcery life-cycle observers get
 called and you can't retrieve them by id from sorcery like you can for
 dynamic contacts.  When you're dealing with contacts in general, you have
 to understand and account for that.   So, my first suggestion is that we
 treat the permanent contacts exactly as dynamic ones.   I.E.  They become
 fully-managed objects and get stored in the astdb with a flag or their
 expiration set such that when asterisk reloads, they get immediately
 expired.  They'll then be immediately rebuilt as the aors are parsed.  We
 can then get rid of the aor-specific containers and the processing around
 them.

 Contact status is also pretty straightforward but there's one minor
 complication related to the fact that status is mutable and sorcery objects
 can't be...  So although status is backed up by a memory wizard (which is
 just an ao2_container), in order to update the status you have to clone the
 object and replace the original object with the new one (well, you don't
 have to but Josh gets upset if you don't :)).   It's easy enough but it's
 also extra code and an opportunity for reference leaks.   My proposal here
 is that we modify the memory wizard such that if the sorcery_update method
 is called, we compare the object reference passed in with the object
 reference we have in the container and if it's equal, we just noop.  You
 still need to call ast_sorcery_update to trigger the observers but at least
 you don't have to clone the object anymore.


The sorcery objects are immutable so you don't need a lock on the object.
If they become mutable you will need a lock and all the nasty locking
issues that entails.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] IAX different reentrant locks depth in the same function

[Richard Mudgett]

On Tue, Apr 21, 2015 at 2:42 PM, Yousf Ateya y.at...@starkbits.com wrote:

 While testing the patch of
 https://issues.asterisk.org/jira/browse/ASTERISK-24983, I found that in
 some paths (ex. in call hangup procedure) we acquire the lock multiple
 times from the same thread.

 The lock implementation supports reentrant locks, so it works; until you
 stuck in a deadlock!

 For example (lock iaxs[callno]), the function iax2_destroy_helper is
 called from multiple paths:
   1 - iax2_hangup - iax2_destroy_helper : In this path the lock is locked
 only once (in iax2_hangup).

   2 - socket_process_helper (ACK for hangup) - iax2_destroy -
 pvt_destructor (because of ao2_ref(pvt,-1) - iax2_destroy_helper : In this
 path lock is locked twice, one in socket_process_helper and the other in
 pvt_destructor.

 The problem of this is that in function iax2_destroy_helper, I wanted to
 avoid deadlock with other thread (sending scheduled lagrq), so I did
 ast_mutex_unlock. But I still got deadlock!!

 Why? Because you need to unlock it twice in path 2!

 Personally, I didn't like it that much.

 Is it common, and we live with it (will do a work around for this specific
 case)?

 Or this seems trouble making pattern and we should have deeper look
 (probably in IAX and other components)?


This is an architectural problem in chan_iax2 that causes it to hold
onto locks to prevent things from disappearing on you (I think it is
mostly iaxs[callno] becoming NULL).  The design pre-dates ao2
objects!  Simply unlocking locks to avoid a deadlock can lead to
things disappearing.  I don't think there will be an easy solution.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] running pjsip testsuite

[Richard Mudgett]

Another thing that is important is that the sample configs must be
installed.
Many tests have some difficulty if this is not the case.  For me it was
because
I had configurations defining the same endpoints with chan_sip and
chan_pjsip.
The conflicting configs caused crashes in tests that did not use SIP at all.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 12 - Security Fix Only! (aka: update repotools)

[Richard Mudgett]

On Wed, Dec 10, 2014 at 1:25 PM, Matthew Jordan mjor...@digium.com wrote:

 tl;dr: Update repotools, run 'make'/'make install'

 Since the final bug fix release of Asterisk 12 has now been made as a
 release candidate, we need to start merging bug fixes from the
 Asterisk 11 branch directly into Asterisk 13. As such, repotools has
 been updated with new merge links to support merge1113 and its
 variants.

 Please update your repotools check-outs, and re-install the scripts
 using the Makefile script. Thanks!


Don't forget to rerun ./configure before rerunning make!

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Opinions Needed: Case sensitivity in config file section names

[Richard Mudgett]

On Tue, Sep 23, 2014 at 10:51 AM, George Joseph george.jos...@fairview5.com
 wrote:

 On Tue, Sep 23, 2014 at 9:45 AM, George Joseph 
 george.jos...@fairview5.com wrote:

 I've been working on some changes for config.c and in the process I've
 found 5 instances of someone attempting to do cat-name == category_name
 instead of strcmp(cat-name, category_name).Example:

 /* try exact match first, then case-insensitive match */
 for (cat = config-root; cat; cat = cat-next) {
 if (cat-name == category_name  (ignored || !cat-ignored))
 return cat;
 }

 for (cat = config-root; cat; cat = cat-next) {
 if (!strcasecmp(cat-name, category_name)  (ignored || !cat-ignored))
 return cat;
 }

 The result is that the case sensitive match never succeeds and it's
 always the case insensitive match that's run.

 My question is...  Should I fix these so the case sensitive match works
 and runs first or just remove the first loop so the match is always
 case-insensitive?   I'm hoping the latter not only because it makes the
 code simpler but because that's how it's worked for years and suddenly
 making the match case sensitive might cause unexpected problems.

 Thoughts?

 Forgot to mention...There are other places in the code where the
 comparison is always case-insensitive.


I was under the impression that the code was done this way
initially to avoid doing a string comparison.  Though, I'm not
sure avoiding the string comparison really buys much in the
way of performance anyway.

Another reason is if you have several sections named [foo]
and you need to resume with the same [foo] section as last
time.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Looking for definitive answer for Busy() vs. Hangup() when used on a non-answered PRI channel

[Richard Mudgett]

On Thu, Jul 10, 2014 at 10:57 AM, Justin Killen 
jkil...@allamericanasphalt.com wrote:

  Hi,



 I’m using freepbx, and I’ve gotten myself into a bit of an argument (
 http://issues.freepbx.org/browse/FREEPBX-7706) about when to use Busy()
 vs. Hangup(17).  The conversation boils down to the fact that in a certain
 condition within the freepbx dialplan, an incoming PRI call runs the
 application Playtone(busy) followed by Busy(20).  My issue here is that
 PRI_CAUSE never gets set, so the calling phone doesn’t ever ring busy, it
 just rings normally.  I should note that this call is never Answer()’d.
 The stance of the freepbx team member is that calling Busy() should be all
 that an application needs to do – they shouldn’t have to worry about
 writing special code depending on the type of the underlying channel.  I
 can’t say that I disagree with that, especially after viewing the official
 docs, which describe Busy() as:



 This application will indicate the busy condition to the calling channel.



 This to me implies that calling Busy() on a PRI channel should internally
 set PRI_CAUSE = 17.



 What I’m really looking for here is a definitive answer as to what should
 change here, either:

 a)   Dialplans be required to check channel status and run
 playtones/busy on answered channels or hangup(17) on non-answered channels

 or

 b)  Busy(), when called on a non-answered channel, should set the
 PRI_CAUSE (or whatever other appropriate variable for the channel)





 Lastly, I should mention that I’ve posted this to the users group, and
 although I have gotten workarounds, I have not been able to get a
 definitive answer on how this actually *should* work, only on how it *does
 *work and how to work around it.


The Hangup(), Busy(), and Congestion() applications are not equivalent
in their behaviours even though some channel drivers treat Busy() as
Hangup(17) and Congestion() as Hangup(34).  The Hangup() application
always sets the cause code and immediately begins hangup
procedures.  The Busy() and Congestion() applications send a control
frame to the channel driver to handle as it sees fit and then the
application waits with optional timeout for the far end to hangup the call.
For chan_dahdi PRI, this behaviour is configurable in chan_dahdi.conf to
work either way when the Busy()/Congestion() applications are used.
The default is to send the inband busy/congestion tone rather than send
the cause code 17/34 so a caller can hear the tone and hangup.

Excerpt from chan_dahdi.conf.sample file:

; PRI Out of band indications.
; Enable this to report Busy and Congestion on a PRI using out-of-band
; notification. Inband indication, as used by Asterisk doesn't seem to work
; with all telcos.
;
; outofband:  Signal Busy/Congestion out of band with RELEASE/DISCONNECT
; inband: Signal Busy/Congestion using in-band tones (default)
;
; priindication cannot be changed on a reload.
;
;priindication = outofband

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Looking for definitive answer for Busy() vs. Hangup() when used on a non-answered PRI channel

[Richard Mudgett]

On Thu, Jul 10, 2014 at 12:36 PM, Justin Killen 
jkil...@allamericanasphalt.com wrote:

   Okay, that makes sense.  So then, how does the answer()’d status affect
 that?  From my (admittedly limited) experience, it seems that playing
 in-band tones only works if the call has been answered?



 Here’s the setup I’m using, maybe it will help if I give an example of
 what I’m trying to figure out:





 Phone A -sip- asterisk site A -PRI- PTSN -PRI- asterisk site B





 If then I have a dialplan at site B for the dialed DID that looks like
 this:



 Playtone(busy)

 Busy(20)



 And given that I’m using default in-band tones, what is the expected
 resulting sound coming out of Phone A?


Inband tones before answering is known as early media.  After answering
it is just a normal audio path that the tones would go over.

Asterisk B in the above situation before answering with the shown dialplan
snippet, the Playtone() would effectively be a NoOp because nothing is shown
that would open a path for early media.  (The Progress() application should
be
done first to open the path.)  Then the Busy() would cause
chan_dahdi/sig_pri
to send a PROGRESS message toward Asterisk A if needed to open the media
path and start its own busy tones.  From Asterisk B to Phone A there are
several things that could block the early media.  The telco network,
Asterisk A configuration, and Phone A itself.

You may need to investigate these options on Asterisk A from
sip.conf.sample:
;prematuremedia=no  ; Some ISDN links send empty media frames
before
; the call is in ringing or progress state.
The SIP
; channel will then send 183 indicating
early media
; which will be empty - thus users get no
ring signal.
; Setting this to yes will stop any media
before we have
; call progress (meaning the SIP channel
will not send 183 Session
; Progress for early media). Default is
yes. Also make sure that
; the SIP peer is configured with
progressinband=never.
;
; In order for noanswer applications to
work, you need to run
; the progress() application in the
priority before the app.

;progressinband=never   ; If we should generate in-band ringing
always
; use 'never' to never use in-band
signalling, even in cases
; where some buggy devices might not render
it
; Valid values: yes, no, never Default:
never

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Looking for definitive answer for Busy() vs. Hangup() when used on a non-answered PRI channel

[Richard Mudgett]

On Thu, Jul 10, 2014 at 2:33 PM, Justin Killen 
jkil...@allamericanasphalt.com wrote:

On Thu, Jul 10, 2014 at 12:36 PM, Justin Killen 
 jkil...@allamericanasphalt.com wrote:

 Okay, that makes sense.  So then, how does the answer()’d status affect
 that?  From my (admittedly limited) experience, it seems that playing
 in-band tones only works if the call has been answered?



 Here’s the setup I’m using, maybe it will help if I give an example of
 what I’m trying to figure out:





 Phone A -sip- asterisk site A -PRI- PTSN -PRI- asterisk site B





 If then I have a dialplan at site B for the dialed DID that looks like
 this:



 Playtone(busy)

 Busy(20)



 And given that I’m using default in-band tones, what is the expected
 resulting sound coming out of Phone A?



 Inband tones before answering is known as early media.  After answering
 it is just a normal audio path that the tones would go over.

 Asterisk B in the above situation before answering with the shown dialplan
 snippet, the Playtone() would effectively be a NoOp because nothing is
 shown
 that would open a path for early media.  (The Progress() application
 should be
 done first to open the path.)  Then the Busy() would cause
 chan_dahdi/sig_pri
 to send a PROGRESS message toward Asterisk A if needed to open the media
 path and start its own busy tones.  From Asterisk B to Phone A there are
 several things that could block the early media.  The telco network,
 Asterisk A configuration, and Phone A itself.

 You may need to investigate these options on Asterisk A from
 sip.conf.sample:
 ;prematuremedia=no  ; Some ISDN links send empty media frames
 before
 ; the call is in ringing or progress
 state. The SIP
 ; channel will then send 183 indicating
 early media
 ; which will be empty - thus users get no
 ring signal.
 ; Setting this to yes will stop any
 media before we have
 ; call progress (meaning the SIP channel
 will not send 183 Session
 ; Progress for early media). Default is
 yes. Also make sure that
 ; the SIP peer is configured with
 progressinband=never.
 ;
 ; In order for noanswer applications to
 work, you need to run
 ; the progress() application in the
 priority before the app.

 ;progressinband=never   ; If we should generate in-band ringing
 always
 ; use 'never' to never use in-band
 signalling, even in cases
 ; where some buggy devices might not
 render it
 ; Valid values: yes, no, never Default:
 never



 Richard





 Okay, so given the default dahdi config value of sending tones in-band,
 busy() will send an in-band busy tone.  If the call hasn’t been answer()’d
 yet, and if we have previously established an early media path via
 progress(), then the busy tone will be sent in-band via early media.



 What happens if progress() has not been called?  Will the call to busy()
 recognize that we haven’t answer()’d the call and automatically attempt to
 establish an early media path?  If not, what would be the downside of doing
 so?


chan_dahdi/sig_pri will recognize that Progress() has not happened yet and
open the early media path itself.  I was just pointing out that the
Playtones()
in that dialplan snipet was effectively a NoOp because nothing before it
opened the media path.  Another reason it is a NoOp is chan_dahdi/sig_pri
starts its own busy tones.






 It seems like for busy() to work properly, we must either:

 A)  Answer() the channel earlier in the dialplan, to allow the tones to
 be played in-band

 B)  Progress() the channel earlier in the dialplan, to allow the tones to
 be played as early media

 C)  Change the dahdi config to send signals out-of-band (on a side-note,
 why isn’t this the default?  Is it broken in a lot of telcos?)


For your case just do C.  It is really better for trunks anyway.






 Looking at option B - what (if any) side effects / disadvantages are there
 to calling progress() on every inbound call?


Calling Progress() without following it with something that generates media
is not a good thing.  SIP phones in particular will have problems because
you may not hear a ringing tone as many phones will ignore the 180 Ringing
message because it has already seen a 183 Progress message.






 The behavior I see now is that Phone A rings for about 20 seconds and then
 times out locally.  Meanwhile on site B I can see that it ran busy(), but
 the signal never got back to A.  When I change the dialplan to use
 hangup(17) instead of busy(20), I get a busy tone on Phone A immediately.
  How then does the PROGRESS message sent by busy() differ from the 

Re: [asterisk-dev] ISDN Userfield UUI has a length constraint?

[Richard Mudgett]

On Mon, Jun 16, 2014 at 3:03 PM, Yves A. yves...@gmx.de wrote:

 Hello List,

 I made the changes in the q931.c sourcefile and got rid of the 35
 character constraint.
 thanks for your attention.
 yves

 Am 16.06.2014 15:23, schrieb Yves A.:

  seems, I found the right place by myself... no wonder I could not find it
 in asterisk sources
 the constraint is located in the sources of libpri I will change
 that, recompile and post feedback here...

 thanks anyways,
 yves

 Am 16.06.2014 14:57, schrieb Yves A.:

 Hi,

 I am using the Q931 / ISDN USER-USER-INFO field for transferring data
 between the caller and the called party.
 This works fine as long as the information does not exceed 35
 characters...
 Unfortunately sometimes I need more space and due to the Q931 Specs I
 think there should be space for max. 128 octets (bytes/characters)...
 Can someone point me to the place in the sources where I can check and
 adopt this?
 I have tested this on an asterisk 11.3 and on an asterisk 1.6.2.24
 both show the same limit of 35 characters...


That restriction has been there since the feature was put into the code.
This would be the reason for the 35 character restriction:

ITU Q.931 Section 4.5.30:
{quote}
In USER INFORMATION messages sent in association with a circuit-mode
connection, the User-
user information element has a network dependent maximum size of 35 or 131
octets. For USER
INFORMATION messages sent in a temporary or permanent user-user signalling
connection, the
user information field contained inside this information element has a
maximum size equal to the
maximum size of messages defined in clause 3, that is 260 octets.
{quote}

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] app_confbridge + USER_OPT_TALKER_DETECT

[Richard Mudgett]

On Wed, May 21, 2014 at 9:19 PM, Jared Mauch ja...@puck.nether.net wrote:


 Hello,

 I'm trying to finish porting over my app_meetme systems to interact
 with app_confbridge in 12.2.0 and I can't see to get the talker detection
 data either via CLI or AMI.  I've not tried with ARI yet, but don't see
 any clear examples of getting that information out.

 Is this something where having talk_detection_events=yes set
 does not promote this?


The ConfBridge talk detection enabled by the talk_detection_events=yes
option generates AMI events when the talking status changes.  ConfBridge
currently does not store the last talking status for reporting by a list CLI
command or AMI action.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk CALLINGTON for SS7

[Richard Mudgett]

On Thu, May 15, 2014 at 9:45 AM, Alberto Rinaudo
alberto.rina...@gmail.comwrote:

 Good morning,
 I have a problem with that variable:
 I use asterisk 11 + dahdi 2.7.0.1 + libss7 1.0.2 + libpri 1.4
 in another box (with pri cards) I use CALLINGTON. But I recently found out
 that this variable is not populated for SS7.
 My question is: there's another variable I can use? I couldn't find
 anything in documentation/source.
 Thanks.


That is the correct variable for the information.  You could also use
CALLERID(num-plan) or CALLERID(ton).
Unfortunately that information is not extracted for SS7.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk CALLINGTON for SS7

[Richard Mudgett]

On Thu, May 15, 2014 at 11:56 AM, Alberto Rinaudo alberto.rina...@gmail.com
 wrote:

 If I'm right CALLINGTON is populated from a variable
 caller.id.number.plan that is equals to p-cid_ton

 I was comparing sig_pri.c and sig_ss7.c using asterisk 11.9


 in sig_pri.c
279  caller.id.number.plan = p-cid_ton;
  4210  pri-pvts[chanpos]-cid_ton = ast_connected.id.number.plan;
  6263  pri-pvts[chanpos]-cid_ton = e-ring.callingplan; /* this
 is the callingplan (TON/NPI), e-ring.callingplan4 would   be the TON
 */

 this variable cid_ton is set equals to the number plan or the calling
 plan, depends on the flow.


 while in sig_ss7.c
   192  caller.id.number.plan = p-cid_ton;
 1071  p-cid_ton = 0;


You want to use e-iam.calling_nai to assign to p-cid_ton.  However, SS7
uses
different code values so you will have to convert to the ISDN equivalent
value that
gets put there.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] ISDN UDI Call with Dial command

[Richard Mudgett]

On Thu, May 8, 2014 at 5:29 PM, Pawel Pastuszak pawelpastus...@gmail.comwrote:

 Hello,


 I have notice that if i uses Dial(DAHDI/g1d/1234) the d option doesn't get to 
 chan_dahi but if i uses originate with d option i see the UDI call but not 
 with dial can some help why is this?


 Example of the originate

 channel originate dahdi/g1d/$number3 extension s@udi



 Example of my dialplan

 [udicall]

 exten = _XX.,1,Set(CALLERID(num)=1244)

 exten = _XX.,n,Dial(Dahdi/g1d/1234)


 My call is to set the callerid on an Data Call (UDI).


The 'd' option is very esoteric.  Its purpose is for use with originated
calls
because that is the only place where an originated call can specify that
the outgoing call legs need digital transfer capability.

Using the Dial application is going to get the 'd' option overridden by the
calling channel executing the application because the transfer capability
of the outgoing channel must match the incoming channel executing the
Dial application.

This question should have been asked on the asterisk-users list as it
has nothing to do with the development of Asterisk itself.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [svn-commits] rmudgett: branch 1.8 r411715 - in /branches/1.8: ./ channels/ configs/ includ...

[Richard Mudgett]

On Sat, Apr 5, 2014 at 1:58 AM, Olle E. Johansson o...@edvina.net wrote:


 On 04 Apr 2014, at 20:32, SVN commits to the Digium repositories 
 svn-comm...@lists.digium.com wrote:

  - case 'I':
  - ast_set_flag(ast_options,
 AST_OPT_FLAG_INTERNAL_TIMING);
  - break;

 Just checking... I would rather add a NOTICE log here that i is not
 needed any more. Please make sure that configurations starting with - i
 will not suddenly fail.


Yes.  You can still specify the -I option without harm.  It is simply
ignored because
it was not removed from the getopt() option parameter string.  The
UPGRADE.txt file
does contain a note about the removal of the option.  I'll change the code
to print a
notice to stderr about the option no longer being needed.  The notice
cannot be sent
to the log because the command line options are parsed before anything else
is even
initialized.

The asterisk.conf internal_timing option is also simply ignored as anything
else not
recognized by non-config framework config file handling code.  I'll put a
NOTICE log
there as well.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] magic number 128- for concurrent meetme monitoring calls.

[Richard Mudgett]

On Thu, Mar 13, 2014 at 5:07 PM, beiyan jin jinbeiyan2...@yahoo.com wrote:

 In my load test calls,
 1. each call has two parties connected by meetme conference.
 2. Each call is recorded by monitor.

 For every load test, before the number of concurrent calls reach 128,
 everything is fine. But after 128, newly started calls get dropped.
 Both CPU and memory are ok in the linux box hosting asterisk.

 The behavior is like asterisk is configured to only allow 128 concurrent
 calls or 256 concurrent channels.

 If this is configured like this by default, where can I change the
 configuration?
 If it is not configured, then why it only allows 128 concurrent calls?


Sounds like the ulimit is at the default 1024.  You need to increase it
because
Asterisk needs a lot of file descriptors.

This kind of question is better asked on the asterisk-users list.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 3192: chan_dahdi: handle DAHDI_EVENT_REMOVED on a pri D-Channel

[Richard Mudgett]

On Fri, Feb 7, 2014 at 7:20 AM, Tzafrir Cohen tzafrir.co...@xorcom.comwrote:

 On Thu, Feb 06, 2014 at 07:04:39PM -, rmudgett wrote:
 
  ---
  This is an automatically generated e-mail. To reply, visit:
  https://reviewboard.asterisk.org/r/3192/#review10796
  ---
 
  Ship it!
 
 
  Use svn merge to backport the revisions -r394552 and -r394567 for the
 patch so comparing the files between version does not show up unnecessary
 differences.  Also you should use the commit message from -r394552 adding a
 note indicating that the change was backported.

 How do I do that?

 I tried:

 $  ~/bin/svnmerge merge -r394552 --source
 https://origsvn.digium.com/svn/asterisk/trunk
 svnmerge: no integration info available for path /trunk

 Or should I just mark it as blocked in branch 12 (also in trunk)?

 Someone on IRC suggested using svn merge:

 $ svn merge https://origsvn.digium.com/svn/asterisk/trunk@394551
 https://origsvn.digium.com/svn/asterisk/trunk@394552 .

 Are svn merge and svnmerge compatible?


svn merge is a subcommand of svn itself.

svnmerge is a script that uses svn properties to guide how it uses svn
merge.  In
this case there are no svn properties setup for this off-nominal merge path.

In your v1.8 svn workspace directory the commands to execute are:

To merge the main change:
svn merge -c394552 https://origsvn.digium.com/svn/asterisk .

To merge the spacing change for completeness:
svn merge -c394567 https://origsvn.digium.com/svn/asterisk .

Fixup any conflicts and compile problems from the merge.  I don't think
there
will be any.  A svn status of the v1.8 workspace should not show any
changes to the '.' directory.

Get the main change log message:
svn log -r394552 https://origsvn.digium.com/svn/asterisk  msg.txt

Edit msg.txt appropriately and add the note about the change being a
backport.

svn commit -F msg.txt

Then merge normally to the newer branches until v12 since the change is
already there.  If you did merge it to v12 anyway the resulting merge should
only have changes to the '.' directory svn properties.  Blocking the merge
to
v12 does not really accomplish much.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] 302 redirects ocassionally ignored; hypothesis: later queued busy preferred to earlier early media frame

[Richard Mudgett]

On Thu, Feb 6, 2014 at 10:23 AM, Dave WOOLLEY dave.wool...@bts.co.ukwrote:

 We have a situation where about 1% of incoming 302 responses result in the
 call failing as busy, rather than redirecting.  We are using a heavily
 patched 1.6.1.0, however we have a theory for the mechanism that still
 seems to be valid on Asterisk 12.  Could anyone verify the analysis and
 comment on our current proposed solution, or suggests alternatives?

 We are making calls, actually via an ApplianX gateway and iSDX, that can
 end up with a 302 redirect to the voicemail number, if there is no answer.
  We have Asterisk configured for promiscuous redirects.  Most of the time
  these work.  However, of the order of 1% of the times, the 302 is received
 (sip debug), and recognized, RDNIS is logged (back port), but the Dial
 operation ends up failing with a busy status.  The interim response before
 the 302 is a 180 with SDP.

 Our understanding of what happens is that redirects are passed from the
 channel driver to Dial by setting a call forward string in the channel
 structure, then pushing AST_CONTROL_BUSY into the channel's queue, and
 writing to the alertpipe to wake things up.

 When woken up, Dial checks for the presence of the forwarding string, and
 goes into the redirect processing.  If it doesn't find it, it calls
 ast_read.  Amongst other things, ast_read first tries to read from the
 queue, then, if there is nothing there, reads from the channel driver,
 adding everything after the first frame retrieved onto the queue.

 If everything arrives from the channel driver, this is the correct order
 of processing, however, if something is pushed directly onto the queue,
 like the AST_CONTROL_BUSY, it will have precedence over frames that were
 available earlier from the channel driver.

 Our current hypothesis is that an early media frame arrives on the RTP
 socket.  This causes the ast_waitfor_n in Dial to wake up.  Just after it
 passes the check for a redirection (c-call_forward), the 302 arrives and
 sets the redirection and queues the AST_CONTROL_BUSY.  When Dial reaches
 the ast_read, it reads the AST_CONTROL_BUSY without having seen the
 redirection address and aborts the call.

 The simplest approach to this would be to delay do_transfer until after
 the ast_read.  Are there any reasons why this might not be safe?


Without looking into the code, queueing a busy frame to wake up the read
thread and look at the call-forward string seems wrong.  The null frame
should be queued instead.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] 302 redirects ocassionally ignored; hypothesis: later queued busy preferred to earlier early media frame

[Richard Mudgett]

On Thu, Feb 6, 2014 at 11:43 AM, Dave WOOLLEY dave.wool...@bts.co.ukwrote:

 One point of detail.  It is actually the write to the alertpipe, within
 ast_queue_control that does the wakeup.


Yes, but there needs to be at least one write to the alertpipe for every
frame in the queue.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [r400723-400741] ConfBridge now has the ability to set the language of announcements

[Richard Mudgett]

On Thu, Feb 6, 2014 at 6:40 PM, Jonathan White j...@uvacity.com wrote:

   Good afternoon. Thanks for adding this feature. I have been testing it 
 today and notice some unexpected behaviour.

 When multiple users call in and set different languages they will only hear 
 the language set by the first caller to join the conference.

 Is this the expected and desired behaviour?

 I would have expected the desired result would be for each caller who sets 
 their own language to hear the prompts they selected not the language of the 
 first caller.

 That option sets the language of the conference bridge itself so any
prompts
played to the bridge get played in the selected language of the bridge.
Prompts
played to the bridge are heard by everyone in the bridge at the same time.
Prompts played to a specific user would be in that users language and are
heard by that user only.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] DAHDI / indications: US tone as stutter on India, Mexico, and the Philippines

[Richard Mudgett]

On Mon, Jan 27, 2014 at 4:52 AM, Tzafrir Cohen tzafrir.co...@xorcom.comwrote:

 On Sun, Jan 26, 2014 at 04:21:35PM -0600, Richard Mudgett wrote:
  On Sun, Jan 26, 2014 at 7:44 AM, Tzafrir Cohen tzafrir.co...@xorcom.com
 wrote:
 
   Hi,
  
   A while ago we noticed while testing that if you set the tonezone of a
   DAHDI phone to Mexican (mx), a phone with a message waiting
 eventually
   gives a US dialtone after the stutter tone is over. This is because in
   zonedata.c:
  
 .country = mx,
   ...
   { DAHDI_TONE_DIALTONE, 425 },
   ...
   { DAHDI_TONE_STUTTER,
  
 !350+440/100,!0/100,!350+440/100,!0/100,!350+440/100,!0/100,!350+440/100,!0/100,!350+440/100,!0/100,!350+440/100,!0/100,350+440
   },
  
   As you can see, it ends with the tones 350+440, the same as the US
   dialtone. I suspect that this is copypaste from the us definition.
  
   A quick look at the file shows that the India (in) and Philipines (ph)
   definitions have the same issue. It's the same in indications.conf.

 Likewise for Thailand (th)

  
   Asterisk's indications.conf gives [1] as a reference to some country's
   indications data. That file does not have information about voicemail
   indication tone for Mexico.
  
   Is this a problem or is this the expected behaviour? A quick search
   found no results.
  
   [1] http://www.itu.int/ITU-T/inr/forms/files/tones-0203.pdf
  
 
  Since the stutter tone is not defined by the standard but is a dialtone,
 I
  think it should
  stutter the same tones as the country specific dialtone.  At the very
 least
  it should stop
  stuttering and become a normal dialtone.

 I noticed that some countries don't have stutter tones. Should they be
 added in the same way? The us stutter tone ended with the country's dial
 tone?

 [es]
 stutter =
 !425/100,!0/100,!425/100,!0/100,!425/100,!0/100,!425/100,!0/100,!425/100,!0/100,!425/100,!0/100,425

 [fi]
 stutter =
 !425/100,!0/100,!425/100,!0/100,!425/100,!0/100,!425/100,!0/100,!425/100,!0/100,!425/100,!0/100,425

 [my]
 ; missing some other fields
 stutter =
 !425/100,!0/100,!425/100,!0/100,!425/100,!0/100,!425/100,!0/100,!425/100,!0/100,!425/100,!0/100,425

 [ve]
 stutter =
 !425/100,!0/100,!425/100,!0/100,!425/100,!0/100,!425/100,!0/100,!425/100,!0/100,!425/100,!0/100,425



Yes they should because chan_dahdi does not check if the tone exists or not
before
attempting to use it.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev