Re: [asterisk-dev] ChanSpy / ConfBridge limitation

2024-01-28 Thread Mark Murawski 



On 1/15/24 04:42, Joshua C. Colp wrote:
On Sun, Jan 14, 2024 at 9:10 PM Mark Murawski 
 wrote:


... snip...

Goal:
   Extract out an individual speaker's audio that's going into a ConfBridge
   (Cannot join the bridge as a member, because then you're getting all 
participants audio)


Summary:
   1) You can whisper to a channel that joined a ConfBridge
   2) You cannot listen to the audio from a channel that joined a ConfBridge


Also:
   I tried ChanSpy()'ing into both CBAnn/...;1  and CBAnn/...;2 and I could 
not get audio from here either


Is this a bug or a limitation/missing-feature?


What would be a good place to look into for resolving #2 ?


So what is the actual state of the channel and ConfBridge at that 
point in time? You haven't really clarified that in this email at all. 
Is it listening to music on hold? Is there no other channel present? 
Have you looked at the core debug to see what the audiohooks API is 
saying? Ultimately that's what is capturing the audio and making it 
available for ChanSpy and it has no idea of ConfBridge or Dial or etc, 
so narrow down the issue to either the ChanSpy module itself or 
audiohooks, and then go from there. In a general sense from the 
available information I would say it is a bug, though I am aware that 
this has worked for other people without problem.


--
Joshua C. Colp
Director of Engineering | Asterisk Project Lead
Sangoma Technologies
Check us out at www.sangoma.com <http://www.sangoma.com> and 
www.asterisk.org <http://www.asterisk.org>





Hi Joshua,

The current state of ConfBridge is that it there is one caller, and I'm 
ChanSpying to that caller's channel, wishing to grab the audio coming in 
from the endpoint that's sending audio to at this point, an empty 
ConfBridge.-- 
_
-- 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] ChanSpy / ConfBridge limitation

2024-01-14 Thread Mark Murawski 

Howdy -dev,

Looking for a starting point to investigate this issue:

Using the following AEL (and Running straight-dialplan results in the 
same issue)


context services {
  2802 => {
Answer();
Set(GLOBAL(foo)=${CHANNEL});
ConfBridge(Agent-PJSIP/2802);
  }

  9000 => {
Answer();
ChanSpy(${foo},qoSE);
  }
}

PJSIP/2802-3b18 -> ConfBridge("Agent-PJSIP/2802")
 joined 'softmix' base-bridge 
<56974564-b175-4b6a-93fc-fe4753082213>
 joined 'softmix' base-bridge 
<56974564-b175-4b6a-93fc-fe4753082213>

PJSIP/trunk-bob-3b19 -> ChanSpy("PJSIP/2802-3b18,qoSE")
Spying on channel PJSIP/2802-3b18
Attaching spy channel PJSIP/trunk-bob-3b19 to PJSIP/2802-3b18


Issue:
  No audio is flowing from Spied-on PJSIP/2802-3b18 to the spy-er 
PJSIP/trunk-bob-3b19


If for example, you change 2802 to the following:

  2802 => {
Answer();
Set(GLOBAL(foo)=${CHANNEL});
Dial(PJSIP/2803);
  }


Wait for the call to connect/answer
  PJSIP/2802-3b20 -> PJSIP/2803-3b5d (callee answered)

And then run the same ChanSpy with options qoSE, resulting in:
  PJSIP/trunk-bob-3b97 -> ChanSpy("PJSIP/2802-3b20,qoSE")
  Attaching spy channel PJSIP/trunk-bob-3b97 to PJSIP/2802-3b20


Result:
  Audio IS flowing from spied-on PJSIP/2802-3b20 to the spy-er on 
PJSIP/trunk-bob-3b97



One might say: Well, ChanSpy/ConfBridge don't mix... but then if you do the 
following... this DOES work:
  
context services {

  2802 => {
Answer();
Set(GLOBAL(foo)=${CHANNEL});
ConfBridge(Agent-PJSIP/2802);
  }

  9000 => {
Answer();
ChanSpy(${foo},qwSE);
  }
}

Changing the option from 'o' to 'w', allows you to whisper to PJSIP/2802




Goal:
  Extract out an individual speaker's audio that's going into a ConfBridge
  (Cannot join the bridge as a member, because then you're getting all 
participants audio)


Summary:
  1) You can whisper to a channel that joined a ConfBridge
  2) You cannot listen to the audio from a channel that joined a ConfBridge


Also:
  I tried ChanSpy()'ing into both CBAnn/...;1  and CBAnn/...;2 and I could not 
get audio from here either


Is this a bug or a limitation/missing-feature?


What would be a good place to look into for resolving #2 ?


Thanks!


-- 
_
-- 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] chan_sip deprecation

2022-11-21 Thread Mark Murawski 

Hi Michal,

I would recommend you loop up with other users/developers who still need 
chan_sip and start a new repo for it.  It probably won't be officially 
endorsed by Sangoma/Asterisk but it's definitely possible to keep it 
alive with the right team.





On 10/29/22 12:40, Michal Rybarik wrote:


Hello all,

chan_sip has been deprecated in Asterisk 17 and there is a plan to 
remove it in 21 (expected next year).

https://issues.asterisk.org/jira/browse/ASTERISK-29567

However, we still have many things depending on chan_sip, and its 
replacing with chan_pjsip needs significant amount of work and 
testing, depending on other parties too. I'm thinking how to continue 
using chan_sip in the next years, while keep using latest asterisk 
source (master branch).


Would it be possible to postpone the removal from Asterisk by several 
versions?


Or to move chan_sip to a separate repository and let it exist there - 
like libpri, libss7, dahdi, etc?


Thank you in advance.

--
Regards,
Michal Rybarik

-- 
_
-- 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] Methodologies for validating dialplan

2022-01-05 Thread Mark Murawski 

Oh!  And One more thing!

There needs to be an externally-facing way to call function/application 
validators for those of us who write dynamic dialplan generators.  Maybe 
an AMI command?



Action: ValidateFunction
Function: MAX
Param[0]: foobar

Response: Error
Message: All inputs must be integer


Action: ValidateApplication
Application: Goto
Strict: false<-- allow for generic 'does it look okay' testing vs 
does the destination actually exist

Param[0]: foo
Param[1]: bar
Param[2]: 1234

Response: Success
Warning: Destination context 'foo', extension 'bar', priority 1234 does 
not exist




Action: ValidateApplication
Application: Goto
Strict: true
Param[0]: foo
Param[1]: bar
Param[2]: 1234

Response: Error
Message: Destination context 'foo', extension 'bar', priority 1234 does 
not exist





And then more of a full validator via a new application and AMI Command
ValidateDialplanFile(/tmp/new_extensions.conf,/tmp/path_to_errors.log);
^--- Sets DIALPLAN_VALID = 1/0

Action: ValidateDialplanFile
File: /tmp/new_extensions.conf
Log: /tmp/path_to_errors.log

Response: Success



And, direct response via AMI


Action: ValidateDialplanFile
File: /tmp/new_extensions.conf

Response: Error
EventList: start
Message: Errors/Warnings will follow
etc etc



On 1/5/22 18:06, Mark Murawski wrote:

Hi!

Throwing my .02 in here.  Adjust to .10 for inflation!


On 1/4/22 14:53, aster...@phreaknet.org wrote:
 However, there are a lot of dialplan problems that represent 
potentially valid syntax that will cause an error at runtime, such as 
branching to somewhere that doesn't exist. The dialplan will reload 
with no errors, since there isn't a syntax issue, but at runtime, the 
call will fail (and most likely crash). I found over the years that a 
lot of these were often simple typos or issues that were easily fixed 
but wasted a lot of time in finding solely in the "test, test, test" 
approach. Another common grievance I hear time to time about the 
dialplan is most issues are caught at runtime, not "compile time" 
(i.e. dialplan reload).



I love it!

And... take an example from a basic cli call that has a validator built-in:



static char *meetme_kick_cmd(struct ast_cli_entry *e, int cmd, struct 
ast_cli_args *a)

{
     switch (cmd) {
     case CLI_INIT:
     e->command = "meetme kick";
     e->usage =
     "Usage: meetme kick  all|\n"
     "   Kick a conference or a user in a 
conference.\n";

     return NULL;
     case CLI_GENERATE:
     return complete_meetmecmd_mute_kick(a->line, a->word, 
a->pos, a->n);

     }

     if (a->argc != 4) {
     return CLI_SHOWUSAGE;
     }

     return meetme_cmd_helper(a);
}


This design pattern has self-contained validation.  And it's up to the 
function to validate as much or as little as it wants to.


We would need a new ast_register_application_xml2 and 
ast_custom_function_register2 to have a new design pattern for 
self-validating functions and applications.


Each application would know what kind of parameters it takes, and what's 
valid and not valid


new-stle for say... Goto Application

static int gosub_exec(int cmd, struct ast_channel *chan, const char *data)
{
 if (cmd == APP_PARAMS_VALIDATE)
     ... do some validation!



ideally gosub knows it's being passed an exten/context/priority and can 
call ast_exists_extension at dialplan parse time via the validator flow


This would be a major undertaking to add validation for every function 
and every application but since dialplan is so ubiquitous and is 
probably never going away... would make huge inroads to making sure 
everything is as correct as possible at parse/load time.





--
_
-- 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] Methodologies for validating dialplan

2022-01-05 Thread Mark Murawski 

Hi!

Throwing my .02 in here.  Adjust to .10 for inflation!


On 1/4/22 14:53, aster...@phreaknet.org wrote:
 
However, there are a lot of dialplan problems that represent potentially 
valid syntax that will cause an error at runtime, such as branching to 
somewhere that doesn't exist. The dialplan will reload with no errors, 
since there isn't a syntax issue, but at runtime, the call will fail 
(and most likely crash). I found over the years that a lot of these were 
often simple typos or issues that were easily fixed but wasted a lot of 
time in finding solely in the "test, test, test" approach. Another 
common grievance I hear time to time about the dialplan is most issues 
are caught at runtime, not "compile time" (i.e. dialplan reload).



I love it!

And... take an example from a basic cli call that has a validator built-in:



static char *meetme_kick_cmd(struct ast_cli_entry *e, int cmd, struct 
ast_cli_args *a)

{
switch (cmd) {
case CLI_INIT:
e->command = "meetme kick";
e->usage =
"Usage: meetme kick  all|\n"
"   Kick a conference or a user in a 
conference.\n";

return NULL;
case CLI_GENERATE:
return complete_meetmecmd_mute_kick(a->line, a->word, 
a->pos, a->n);

}

if (a->argc != 4) {
return CLI_SHOWUSAGE;
}

return meetme_cmd_helper(a);
}


This design pattern has self-contained validation.  And it's up to the 
function to validate as much or as little as it wants to.


We would need a new ast_register_application_xml2 and 
ast_custom_function_register2 to have a new design pattern for 
self-validating functions and applications.


Each application would know what kind of parameters it takes, and what's 
valid and not valid


new-stle for say... Goto Application

static int gosub_exec(int cmd, struct ast_channel *chan, const char *data)
{
if (cmd == APP_PARAMS_VALIDATE)
... do some validation!



ideally gosub knows it's being passed an exten/context/priority and can 
call ast_exists_extension at dialplan parse time via the validator flow


This would be a major undertaking to add validation for every function 
and every application but since dialplan is so ubiquitous and is 
probably never going away... would make huge inroads to making sure 
everything is as correct as possible at parse/load time.



--
_
-- 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] Proper way to get the sip invite dialog?

2021-02-27 Thread Mark Murawski 

Thanks!

On 2/27/21 2:53 PM, Joshua C. Colp wrote:
On Sat, Feb 27, 2021 at 1:57 PM Mark Murawski 
mailto:markm-li...@intellasoft.net>> wrote:


H!,

I'm working on a cross-channel standard log line for processing new
calls.  I had no issue implementing this for DAHDI/IAX/CHAN_SIP, but I
have this so far for pjsip got this far, but this does not seem like
the
right approach because occasionally reads to the sip dialogue are
reading uninitialized data.




   {
+        RAII_VAR(struct ast_datastore *, datastore, NULL, ao2_cleanup);
          int res;
+       pjsip_dialog *dlg;
+        struct ast_channel *c = session->channel;
+        struct transport_info_data *transport_data;
+        char src_host_and_ip[PJ_INET6_ADDRSTRLEN+2] = "";
+        char dst_host_and_ip[PJ_INET6_ADDRSTRLEN+2] = "";

          /* Check for a to-tag to determine if this is a reinvite */
          if (rdata->msg_info.to->tag.slen) {
                  /* We don't care about reinvites */
                  return 0;
          }

+       pjsip_dlg_inc_lock(session->inv_session->dlg);


There is no need to do locking on this. The dialog is guaranteed to not 
change.



+       ast_verb(2, "<%s> New Call (Type: PJSIP) [%s -> %s] [%s] %s
<%s>
(Destination: %s@%s,%d)\n",
+               ast_channel_name(session->channel),
+               src_host_and_ip, dst_host_and_ip,
+               pj_strbuf(&dlg->call_id->id),


PJLIB strings are not guaranteed to be NULL terminated. The call-id 
implementation for the CHANNEL dialplan function does this:


snprintf(buf, buflen, "%.*s", (int) pj_strlen(&dlg->call_id->id), 
pj_strbuf(&dlg->call_id->id));


To place the proper amount in the buffer.

--
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com <http://www.sangoma.com/> and 
www.asterisk.org <http://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

[asterisk-dev] Proper way to get the sip invite dialog?

2021-02-27 Thread Mark Murawski 

H!,

I'm working on a cross-channel standard log line for processing new 
calls.  I had no issue implementing this for DAHDI/IAX/CHAN_SIP, but I 
have this so far for pjsip got this far, but this does not seem like the 
right approach because occasionally reads to the sip dialogue are 
reading uninitialized data.


Patch based on 16.16.1

diff --git a/channels/chan_pjsip.c b/channels/chan_pjsip.c
index f37ec3d712..cab4026e99 100644
--- a/channels/chan_pjsip.c
+++ b/channels/chan_pjsip.c
@@ -3060,28 +3060,65 @@ static int call_pickup_incoming_request(struct 
ast_sip_session *session, pjsip_r

 }

 static struct ast_sip_session_supplement call_pickup_supplement = {
.method = "INVITE",
.priority = AST_SIP_SUPPLEMENT_PRIORITY_LAST - 1,
.incoming_request = call_pickup_incoming_request,
 };

 static int pbx_start_incoming_request(struct ast_sip_session *session, 
pjsip_rx_data *rdata)

 {
+RAII_VAR(struct ast_datastore *, datastore, NULL, ao2_cleanup);
int res;
+   pjsip_dialog *dlg;
+struct ast_channel *c = session->channel;
+struct transport_info_data *transport_data;
+char src_host_and_ip[PJ_INET6_ADDRSTRLEN+2] = "";
+char dst_host_and_ip[PJ_INET6_ADDRSTRLEN+2] = "";

/* Check for a to-tag to determine if this is a reinvite */
if (rdata->msg_info.to->tag.slen) {
/* We don't care about reinvites */
return 0;
}

+   pjsip_dlg_inc_lock(session->inv_session->dlg);
+
+   dlg = session->inv_session->dlg;
+
+   /* local_addr */
+   datastore = ast_sip_session_get_datastore(session, 
"transport_info");

+   if (!datastore) {
+   ast_log(AST_LOG_WARNING, "No transport information for 
channel %s\n", ast_channel_name(c));

+   }
+   else {
+   transport_data = datastore->data;
+
+   if (pj_sockaddr_has_addr(&transport_data->local_addr)) {
+   pj_sockaddr_print(&transport_data->local_addr, 
dst_host_and_ip, sizeof(dst_host_and_ip), 3);

+   }
+
+   if (pj_sockaddr_has_addr(&transport_data->remote_addr)) {
+   pj_sockaddr_print(&transport_data->remote_addr, 
src_host_and_ip, sizeof(src_host_and_ip), 3);

+   }
+   }
+
+   ast_verb(2, "<%s> New Call (Type: PJSIP) [%s -> %s] [%s] %s <%s> 
(Destination: %s@%s,%d)\n",

+   ast_channel_name(session->channel),
+   src_host_and_ip, dst_host_and_ip,
+   pj_strbuf(&dlg->call_id->id),
+   S_COR(ast_channel_caller(c)->id.name.valid, 
ast_channel_caller(c)->id.name.str, ""),
+   S_COR(ast_channel_caller(c)->id.number.valid, 
ast_channel_caller(c)->id.number.str, ""),
+   ast_channel_exten(c), ast_channel_context(c), 
ast_channel_priority(c));

+
+   pjsip_dlg_dec_lock(session->inv_session->dlg);
+
res = ast_pbx_start(session->channel);

switch (res) {
case AST_PBX_FAILED:
ast_log(LOG_WARNING, "Failed to start PBX ;(\n");
ast_channel_hangupcause_set(session->channel, 
AST_CAUSE_SWITCH_CONGESTION);

ast_hangup(session->channel);
break;
case AST_PBX_CALL_LIMIT:
ast_log(LOG_WARNING, "Failed to start PBX (call limit 
reached) \n");



==12719== Conditional jump or move depends on uninitialised value(s)
==12719==at 0x4838C78: strlen (vg_replace_strmem.c:460)
==12719==by 0x30EF24: ast_ends_with (strings.h:119)
==12719==by 0x30EF24: format_log_message_ap (logger.c:1698)
==12719==by 0x31137B: ast_log_full (logger.c:2072)
==12719==by 0x311940: __ast_verbose_ap (logger.c:2189)
==12719==by 0x311940: __ast_verbose (logger.c:2200)
==12719==by 0x11061090: pbx_start_incoming_request (chan_pjsip.c:3104)
==12719==by 0x1033F26F: handle_incoming_request 
(res_pjsip_session.c:4388)

==12719==by 0x1034E25F: new_invite (res_pjsip_session.c:4107)
==12719==by 0x1034E25F: handle_new_invite_request 
(res_pjsip_session.c:4171)

==12719==by 0x1034E25F: session_on_rx_request (res_pjsip_session.c:4246)
==12719==by 0x48CE086: pjsip_endpt_process_rx_data (sip_endpoint.c:930)
==12719==by 0x102366B3: distribute (pjsip_distributor.c:955)
==12719==by 0x2B0E93: ast_taskprocessor_execute (taskprocessor.c:1237)
==12719==by 0x2B816F: execute_tasks (threadpool.c:1354)
==12719==by 0x2B0E93: ast_taskprocessor_execute (taskprocessor.c:1237)

Line 3104 of chan_pjsip in this case is the final ast_verb(2,... for the 
new call




diff --git a/channels/chan_pjsip.c b/channels/chan_pjsip.c
index f37ec3d712..cab4026e99 100644
--- a/channels/chan_pjsip.c
+++ b/channels/chan_pjsip.c
@@ -3060,28 +3060,65 @@ static int call_pickup_incoming_request(struct ast_sip_session *session, pjsip_r
 }

 static struct ast_sip_session_supplement call_pickup_supplement = {
.method = "INVITE",
.priority = AST_SIP_SUPPLEM

[asterisk-dev] Test

2021-01-05 Thread Mark Murawski 


Testing.  3, 2, 1.

--
_
-- 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] [PJSIP] Controlling RTP Media Source IP?

2021-01-05 Thread Mark Murawski 

Hi!

I have the following situation here:

;;;
; WAN1 and traffic to PBX-A / PBX-B

[transport-udp]
type   = transport
symmetric_transport= yes
protocol   = udp
bind   = 10.13.13.38:5060
external_media_address = XX.94.171.40
external_signaling_address = XX.94.171.40
external_signaling_port= 5060
allow_reload   = yes
tos= cs3
cos= 3
local_net  = 192.168.181.0/24
local_net  = 10.13.13.0/24

[transport-tcp]
type   = transport
symmetric_transport= yes
protocol   = tcp
bind   = 10.13.13.38:5060
external_media_address = XX.94.171.40
external_signaling_address = XX.94.171.40
external_signaling_port= 5060
allow_reload   = yes
tos= cs3
cos= 3
local_net  = 192.168.181.0/24
local_net  = 10.13.13.0/24

[transport-tcp-tls]
type   = transport
symmetric_transport= yes
protocol   = tls
allow_reload   = yes
bind   = 10.13.13.38:5061
external_media_address = XX.94.171.40
external_signaling_address = XX.94.171.40
external_signaling_port= 5061
tos= cs3
cos= 3
cert_file  = /etc/asterisk/keys/asterisk.crt
priv_key_file  = /etc/asterisk/keys/asterisk.key
method = tlsv1_2
local_net  = 192.168.181.0/24
local_net  = 10.13.13.0/24

;;
;;; WAN2
;
[transport-udp-wan2]
type   = transport
symmetric_transport= yes
protocol   = udp
bind   = 10.13.13.39:5060
external_media_address = YY.9.5.40
external_signaling_address = YY.9.5.40
external_signaling_port= 5060
allow_reload   = yes
tos= cs3
cos= 3
local_net  = 192.168.181.0/24
local_net  = 10.13.13.0/24

[transport-tcp-wan2]
type   = transport
symmetric_transport= yes
protocol   = tcp
bind   = 10.13.13.39:5060
external_media_address = YY.9.5.40
external_signaling_address = YY.9.5.40
external_signaling_port= 5060
allow_reload   = yes
tos= cs3
cos= 3
local_net  = 192.168.181.0/24
local_net  = 10.13.13.0/24

[transport-tcp-wan2-tls]
type   = transport
symmetric_transport= yes
protocol   = tls
allow_reload   = yes
bind   = 10.13.13.39:5061
external_media_address = YY.9.5.40
external_signaling_address = YY.9.5.40
external_signaling_port= 5061
tos= cs3
cos= 3
cert_file  = /etc/asterisk/keys/asterisk.crt
priv_key_file  = /etc/asterisk/keys/asterisk.key
method = tlsv1_2
local_net  = 192.168.181.0/24
local_net  = 10.13.13.0/24

I then have the following call

INVITE
(Call is attached)

Packet from: ZZ.75.184.42
Packet To: -> YY.9.5.40  (Ie: WAN2), Then firewall DNATs to
  10.13.13.39:5061, and asterisk gets the call

Use Case:
Now... in order for this dual-wan to operate correctly... say WAN1 is 
down.  Asterisk needs to be able to send RTP traffic (not just SIP 
Signalling) using the correct rtp bind, associated to the correct return 
transport and external_media_address


My expectation here is that since Asterisk knows it's using 
transport-tcp-wan2-tls, and it has set the correct media source in the 
SDP to YY.9.5.40, that the RDP engine would then send media from 
10.13.13.39.  But it does not


During the above call, the outgoing RTP looks like this from tcpdump:
08:52:13.234702 IP 10.13.13.38.16384 > ZZ.75.184.42.7078: UDP, length 182

The closest thing I've found so far in digging deeper to resolve this 
is: res_pjsip_sdp_rtp.c


static int create_rtp(struct ast_sip_session *session, struct 
ast_sip_session_media *session_media,

const pjmedia_sdp_session *sdp)
{
snip
transport = 
ast_sorcery_retrieve_by_id(ast_sip_get_sorcery(), "transport",

session->endpoint->transport);
if (transport) {
struct ast_sip_transport_state *trans_state;

trans_state = 
ast_sip_get_transport_state(ast_sorcery_object_get_id(transport));

if (trans_state) {
char hoststr[PJ_INET6_ADDRSTRLEN];

pj_sockaddr_print(&tran

Re: [asterisk-dev] Asterisk-11 DTMF bug ?

2017-04-07 Thread Mark Murawski 



On 4/6/17 4:23 PM, Matt Fredrickson wrote:


Hey Mark,

First off, thanks for reaching out to the Asterisk community to talk
about the trouble you're having :-)

This actually is a development related mailing list - so primarily for
development of Asterisk C source code level discussions, project
policy related discussions, and sometimes protocol development related
discussions.

Your question appears to be configuration or at the very least debug
related, rather than development related.  I would try referring it to
the asterisk-users mailing list or the community.asterisk.org forums
instead.

I think you probably should add more data about your Asterisk
configuration in this case, as well as your expectations as to what
should be working and what is not working, as that is not clear to me
from your description.  Are you not seeing DTMF bridged between the
two parties in the call, or is some other DTMF triggered behavior you
expect Asterisk to be demonstrating not occurring?  These are
questions I would hope to be answered when posting a follow up on one
of the other lists.

Hope that helps, and best wishes to you in resolving your problem! :-)



Hi Matt,

As a long time community member, I do understand the split of -users and 
-dev.  This is an internal implementation question/discussion and I 
believe this is more suited to the -dev list.


I'm in the process of collecting more test cases, so far I've also 
reproduced the issue with a soft phone.  So it does appear that it's not 
dependent on the endpoint user agent to exhibit this problem.


The purpose of this post was to put out feelers to see if this was 
possibly a known issue with handling DTMF with a B2BUA scenario. While 
it may wind up being a configuration issue to fix this, the expectation 
is that with the current settings, DTMF should 'just work'.  The 
endpoint is clearly sending RFC2833, and asterisk is not interpreting it 
in the B2BUA flow.


New Details: If I switch the endpoint to SIP INFO, then asterisk does 
interpret the DTMF.  To me, this signals that this is probably a bug.  
Given all else being equal that the asterisk config has not changed, and 
switching from 2833 to info, fixes the issue.


I'll be drawing out some diagrams and describing some test cases within 
a day or two.



--
_
-- 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-11 DTMF bug ?

2017-04-04 Thread Mark Murawski 

So... more information.

directmedia=no
directrtpsetup=no

In this situation below, asterisk is the B2BUA.  Call comes in from 
Polycom, then gets routed out to ITSP via Dial()


When the polycom directly calls into dialplan that handles media, 
asterisk *does* process the DTMF

ie: Polycom calls into Read()

[2017-04-04 17:21:41.557] [C-175d]  Got  RTP RFC2833 from  
10.0.90.6:8110 (type 101, seq 016608, ts 3618850425, len 04, mark 1, 
event 0003, end 0, duration 00160)




On 04/04/2017 04:52 PM, Mark Murawski wrote:
Er, small correction.  Asterisk clearly shows RTP *flowing*, but not 
receiving DTMF from 10.0.90.6





On 04/04/17 16:37, Mark Murawski wrote:

Hey,

So, I'm seeing an issue where a Polycom IP-550 with 4.1.1 firmware is
sending RFC2833 DTMF packets as shown in the capture attached. I can
send pcaps as necessary, if needed.

10.0.90.6 is the Polycom 10.0.90.1 is Asterisk.

So of course you do:

rtp set debug 10.0.90.6


And then get the below, while the polycom is sending digits. The packet
capture clearly shows DTMF going to 10.0.90.1, but Asterisk is not
picking them up.

[2017-04-04 14:14:18.830] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:18.830] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:18.850] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:18.850] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:18.870] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:18.870] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:18.890] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:18.890] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
...
[2017-04-04 14:14:22.210] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:22.210] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:22.230] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:22.230] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:22.250] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:22.250] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:22.270] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:22.270] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)


I am running 11.20 on this particular box, for some specific reasons.
I'm currently working out some other issues with the newer/latest 11's,
so I'm on this for now.

Before I start digging into the code, are there any known issues with
DTMF/RFC2833 in this version?  Any workarounds I can implement?









--
_
-- 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-11 DTMF bug ?

2017-04-04 Thread Mark Murawski 
Er, small correction.  Asterisk clearly shows RTP *flowing*, but not 
receiving DTMF from 10.0.90.6





On 04/04/17 16:37, Mark Murawski wrote:

Hey,

So, I'm seeing an issue where a Polycom IP-550 with 4.1.1 firmware is
sending RFC2833 DTMF packets as shown in the capture attached.  I can
send pcaps as necessary, if needed.

10.0.90.6 is the Polycom 10.0.90.1 is Asterisk.

So of course you do:

rtp set debug 10.0.90.6


And then get the below, while the polycom is sending digits.  The packet
capture clearly shows DTMF going to 10.0.90.1, but Asterisk is not
picking them up.

[2017-04-04 14:14:18.830] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:18.830] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:18.850] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:18.850] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:18.870] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:18.870] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:18.890] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:18.890] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
...
[2017-04-04 14:14:22.210] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:22.210] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:22.230] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:22.230] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:22.250] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:22.250] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:22.270] VERBOSE[21403][C-1424] res_rtp_asterisk.c:
[2017-04-04 14:14:22.270] [C-1424] Sent RTP P2P packet to
10.0.90.6:2242 (type 00, len 000160)


I am running 11.20 on this particular box, for some specific reasons.
I'm currently working out some other issues with the newer/latest 11's,
so I'm on this for now.

Before I start digging into the code, are there any known issues with
DTMF/RFC2833 in this version?  Any workarounds I can implement?






--
_
-- 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] Asterisk-11 DTMF bug ?

2017-04-04 Thread Mark Murawski 

Hey,

So, I'm seeing an issue where a Polycom IP-550 with 4.1.1 firmware is 
sending RFC2833 DTMF packets as shown in the capture attached.  I can 
send pcaps as necessary, if needed.


10.0.90.6 is the Polycom 10.0.90.1 is Asterisk.

So of course you do:
> rtp set debug 10.0.90.6

And then get the below, while the polycom is sending digits.  The packet 
capture clearly shows DTMF going to 10.0.90.1, but Asterisk is not 
picking them up.


[2017-04-04 14:14:18.830] VERBOSE[21403][C-1424] res_rtp_asterisk.c: 
[2017-04-04 14:14:18.830] [C-1424] Sent RTP P2P packet to 
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:18.850] VERBOSE[21403][C-1424] res_rtp_asterisk.c: 
[2017-04-04 14:14:18.850] [C-1424] Sent RTP P2P packet to 
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:18.870] VERBOSE[21403][C-1424] res_rtp_asterisk.c: 
[2017-04-04 14:14:18.870] [C-1424] Sent RTP P2P packet to 
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:18.890] VERBOSE[21403][C-1424] res_rtp_asterisk.c: 
[2017-04-04 14:14:18.890] [C-1424] Sent RTP P2P packet to 
10.0.90.6:2242 (type 00, len 000160)

...
[2017-04-04 14:14:22.210] VERBOSE[21403][C-1424] res_rtp_asterisk.c: 
[2017-04-04 14:14:22.210] [C-1424] Sent RTP P2P packet to 
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:22.230] VERBOSE[21403][C-1424] res_rtp_asterisk.c: 
[2017-04-04 14:14:22.230] [C-1424] Sent RTP P2P packet to 
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:22.250] VERBOSE[21403][C-1424] res_rtp_asterisk.c: 
[2017-04-04 14:14:22.250] [C-1424] Sent RTP P2P packet to 
10.0.90.6:2242 (type 00, len 000160)
[2017-04-04 14:14:22.270] VERBOSE[21403][C-1424] res_rtp_asterisk.c: 
[2017-04-04 14:14:22.270] [C-1424] Sent RTP P2P packet to 
10.0.90.6:2242 (type 00, len 000160)



I am running 11.20 on this particular box, for some specific reasons. 
I'm currently working out some other issues with the newer/latest 11's, 
so I'm on this for now.


Before I start digging into the code, are there any known issues with 
DTMF/RFC2833 in this version?  Any workarounds I can implement?


-- 
_
-- 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] Lockups in Asterisk 11

2015-11-17 Thread Mark Murawski 

On 11/17/15 15:39, Mark Murawski wrote:

On 11/16/15 10:59, Matthew Jordan wrote:



SNIP

Either way, nothing above makes me think there is a bug in Asterisk.




Here's a completely different box, different arch/hardware/kernel but 
compiled from the same exact asterisk source.


I hit this lockup when i did an attended transfer.  With two total 
channels active.  I'm going to work on reproducing this.



===   ():  (times locked)
===
=== Thread ID: 0x7f5a47dd2700 (do_monitor   started at [26934] 
chan_sip.c restart_monitor())
=== ---> Lock #0 (chan_sip.c): MUTEX 26387 handle_request_do &netlock 
0x7f5a4156c980 (1)

asterisk(ast_bt_get_addresses+0x1d) [0x4efb00]
asterisk(__ast_pthread_mutex_lock+0xc9) [0x4e8949]
/usr/lib/asterisk/modules/chan_sip.so(+0x80618) [0x7f5a4131d618]
/usr/lib/asterisk/modules/chan_sip.so(+0x8041f) [0x7f5a4131d41f]
asterisk(ast_io_wait+0x193) [0x4e298a]
/usr/lib/asterisk/modules/chan_sip.so(+0x82209) [0x7f5a4131f209]
asterisk() [0x56e7c8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7f5a4e9d8b50]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f5a4f22d95d]
=== ---> Lock #1 (chan_sip.c): MUTEX 8356 sip_pvt_lock_full chan 
0xba1db0 (1)

asterisk(ast_bt_get_addresses+0x1d) [0x4efb00]
asterisk(__ast_pthread_mutex_lock+0xc9) [0x4e8949]
asterisk(__ao2_lock+0x57) [0x44838b]
/usr/lib/asterisk/modules/chan_sip.so(+0x2aa20) [0x7f5a412c7a20]
/usr/lib/asterisk/modules/chan_sip.so(+0x806fe) [0x7f5a4131d6fe]
/usr/lib/asterisk/modules/chan_sip.so(+0x8041f) [0x7f5a4131d41f]
asterisk(ast_io_wait+0x193) [0x4e298a]
/usr/lib/asterisk/modules/chan_sip.so(+0x82209) [0x7f5a4131f209]
asterisk() [0x56e7c8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7f5a4e9d8b50]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f5a4f22d95d]
=== ---> Lock #2 (chan_sip.c): MUTEX 8357 sip_pvt_lock_full pvt 0xb9c6f0 (1)
asterisk(ast_bt_get_addresses+0x1d) [0x4efb00]
asterisk(__ast_pthread_mutex_lock+0xc9) [0x4e8949]
asterisk(__ao2_lock+0x57) [0x44838b]
/usr/lib/asterisk/modules/chan_sip.so(+0x2aa46) [0x7f5a412c7a46]
/usr/lib/asterisk/modules/chan_sip.so(+0x806fe) [0x7f5a4131d6fe]
/usr/lib/asterisk/modules/chan_sip.so(+0x8041f) [0x7f5a4131d41f]
asterisk(ast_io_wait+0x193) [0x4e298a]
/usr/lib/asterisk/modules/chan_sip.so(+0x82209) [0x7f5a4131f209]
asterisk() [0x56e7c8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7f5a4e9d8b50]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f5a4f22d95d]
=== ---> Waiting for Lock #3 (pbx.c): MUTEX 10576 
pbx_builtin_setvar_helper chan 0x7f5a20843590 (1)

asterisk(ast_bt_get_addresses+0x1d) [0x4efb00]
asterisk(__ast_pthread_mutex_lock+0xc9) [0x4e8949]
asterisk(__ao2_lock+0x57) [0x44838b]
asterisk(pbx_builtin_setvar_helper+0xfc) [0x525b49]
/usr/lib/asterisk/modules/chan_sip.so(+0x6e725) [0x7f5a4130b725]
/usr/lib/asterisk/modules/chan_sip.so(+0x7f1d2) [0x7f5a4131c1d2]
/usr/lib/asterisk/modules/chan_sip.so(+0x807f8) [0x7f5a4131d7f8]
/usr/lib/asterisk/modules/chan_sip.so(+0x8041f) [0x7f5a4131d41f]
asterisk(ast_io_wait+0x193) [0x4e298a]
/usr/lib/asterisk/modules/chan_sip.so(+0x82209) [0x7f5a4131f209]
asterisk() [0x56e7c8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7f5a4e9d8b50]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f5a4f22d95d]
=== --- ---> Locked Here: channel.c line 4598 (__ast_read)
=== ---
===
=== Thread ID: 0x7f5a1bf83700 (handle_tcptls_connection started at [ 
736] tcptls.c ast_tcptls_server_root())
=== ---> Waiting for Lock #0 (manager.c): MUTEX 4847 
action_coreshowchannels c 0xba1db0 (1)

asterisk(ast_bt_get_addresses+0x1d) [0x4efb00]
asterisk(__ast_pthread_mutex_lock+0xc9) [0x4e8949]
asterisk(__ao2_lock+0x57) [0x44838b]
asterisk() [0x4fc47c]
asterisk() [0x4fd1d9]
asterisk() [0x4fdaeb]
asterisk() [0x4fdfe6]
asterisk() [0x55d7b3]
asterisk() [0x56e7c8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7f5a4e9d8b50]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f5a4f22d95d]
=== --- ---> Locked Here: chan_sip.c line 8356 (sip_pvt_lock_full)
=== ---
===
=== Thread ID: 0x7f5a1bf07700 (handle_tcptls_connection started at [ 
736] tcptls.c ast_tcptls_server_root())
=== ---> Waiting for Lock #0 (manager.c): MUTEX 4847 
action_coreshowchannels c 0xba1db0 (1)

asterisk(ast_bt_get_addresses+0x1d) [0x4efb00]
asterisk(__ast_pthread_mutex_lock+0xc9) [0x4e8949]
asterisk(__ao2_lock+0x57) [0x44838b]
asterisk() [0x4fc47c]

Re: [asterisk-dev] Lockups in Asterisk 11

2015-11-17 Thread Mark Murawski 

On 11/16/15 10:59, Matthew Jordan wrote:





Things to investigate:
(1) Get a gdb backtrace when this occurs, so you can find out exactly
what the AstDB synchronization thread is doing that is blocking for a
long period of time.
(2) Find out *exactly* what is occurring on your system. If the AstDB
synchronization thread is taking a noticeable amount of time to do work,
you almost certainly have either a problem in your AstDB; have other I/O
problems on the system; or have something occurring here that is outside
the control of Asterisk.

Either way, nothing above makes me think there is a bug in Asterisk.

--
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org




I'm working on getting a core dump when this happens again.

Something of note I saw this lockup just a few hours ago:

=== Thread ID: 0xb5191b70 (do_monitor   started at [29517] 
chan_sip.c restart_monitor())
=== ---> Lock #0 (chan_sip.c): MUTEX 28923 handle_request_do &netlock 
0xb621b460 (1)

main/logger.c:1702 ast_bt_get_addresses() (0x813f4ae+19)
main/lock.c:258 __ast_pthread_mutex_lock() (0x813870f+85)
channels/chan_sip.c:28926 handle_request_do()
channels/chan_sip.c:28885 sipsock_read()
main/io.c:292 ast_io_wait() (0x8132e10+175)
channels/chan_sip.c:29484 do_monitor()
main/utils.c:1223 dummy_start()
:0 start_thread()
libc.so.6 clone() (0xb76690d0+5E)
=== ---> Lock #1 (chan_sip.c): MUTEX 8959 sip_pvt_lock_full pvt 
0xb3200018 (1)

main/logger.c:1702 ast_bt_get_addresses() (0x813f4ae+19)
main/lock.c:258 __ast_pthread_mutex_lock() (0x813870f+85)
main/astobj2.c:198 __ao2_lock() (0x80906ad+7C)
channels/chan_sip.c:8960 sip_pvt_lock_full()
channels/chan_sip.c:28939 handle_request_do()
channels/chan_sip.c:28885 sipsock_read()
main/io.c:292 ast_io_wait() (0x8132e10+175)
channels/chan_sip.c:29484 do_monitor()
main/utils.c:1223 dummy_start()
:0 start_thread()
libc.so.6 clone() (0xb76690d0+5E)
=== ---
===
=== Thread ID: 0xb3e87b70 (handle_tcptls_connection started at [  745] 
tcptls.c ast_tcptls_server_root())
=== ---> Waiting for Lock #0 (chan_sip.c): MUTEX 28923 handle_request_do 
&netlock 0xb621b460 (1)

main/logger.c:1702 ast_bt_get_addresses() (0x813f4ae+19)
main/lock.c:258 __ast_pthread_mutex_lock() (0x813870f+85)
channels/chan_sip.c:28926 handle_request_do()
channels/chan_sip.c:3045 _sip_tcp_helper_thread()
channels/chan_sip.c:2572 sip_tcp_worker_fn()
main/tcptls.c:694 handle_tcptls_connection()
main/utils.c:1223 dummy_start()
:0 start_thread()
libc.so.6 clone() (0xb76690d0+5E)
=== --- ---> Locked Here: chan_sip.c line 28923 (handle_request_do)
=== ---
===
===

core show locks was this same output over an 8 minute period until 
asterisk was restarted.  All sip traffic stopped processing at this 
point.  I don't have the core file on this, I wish I did, but for some

reason it didn't dump when it was restarted.



--
_
-- 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] Lockups in Asterisk 11

2015-11-14 Thread Mark Murawski 

Hi Jaco,

I do know what to look for with deadlocks, and the odd thing is that 
what I pasted in the earlier post is not your run of the mill mutex 
based deadlock.  Four locks are currently held and something inside each 
thread is just not finishing.  None of the threads are waiting for 
cross-thread locks.


We have netlock, a single sip private lock, an ao2 lock, and a dblock. 
None of these threads are waiting for additional locks.  It seems 
whatever they are doing is simply not finishing.




On 11/13/15 05:59, Jaco Kroon wrote:

Hi Mark,

You're right.  That looks like something else.  do_monitor() relates to
MWI.  This could be a completely different issue, if I need to guess I'd
say we're looking at a lock-ordering deadlock.  Eg:

Thread 1 grabs lock A.
Thread 2 grabs lock B.
Thread 1 blocks trying to lock B.
Thread 2 blocks trying to lock A.

I'm not seeing any direct changes in chan_sip from 11.19 => 11.20 that
would do anything with respect to netlock.  Also no changes with respect
to dblock (and ast_db_put is so trivial that there is almost no way that
it can be wrong unless the unlock call fails - which I think is impossible).

Out of my depth.  Sorry.

Kind Regards,
Jaco

On 12/11/2015 07:07, markm-li...@intellasoft.net wrote:

Hi Jaco,

I've tried this tmpfs workaround on asterisk 11 and I'm running into
the following (very very long duration) locks that block sip activity
completely.  My core issue is definitely not disk-io.


===   ():   
  (times locked)
===
=== Thread ID: 0xb524fb70 (do_monitor   started at [29517]
chan_sip.c restart_monitor())
=== ---> Lock #0 (chan_sip.c): MUTEX 28923 handle_request_do &netlock
0xb630b440 (1)
 main/logger.c:1702 ast_bt_get_addresses() (0x813f3ee+19)
 main/lock.c:258 __ast_pthread_mutex_lock() (0x813864f+85)
 channels/chan_sip.c:28926 handle_request_do()
 channels/chan_sip.c:28885 sipsock_read()
 main/io.c:292 ast_io_wait() (0x8132d50+175)
 channels/chan_sip.c:29484 do_monitor()
 main/utils.c:1223 dummy_start()
 :0 start_thread()
 libc.so.6 clone() (0xb77270d0+5E)
=== ---> Lock #1 (chan_sip.c): MUTEX 8959 sip_pvt_lock_full pvt
0x84b5660 (1)
 main/logger.c:1702 ast_bt_get_addresses() (0x813f3ee+19)
 main/lock.c:258 __ast_pthread_mutex_lock() (0x813864f+85)
 main/astobj2.c:198 __ao2_lock() (0x80906ad+7C)
 channels/chan_sip.c:8960 sip_pvt_lock_full()
 channels/chan_sip.c:28939 handle_request_do()
 channels/chan_sip.c:28885 sipsock_read()
 main/io.c:292 ast_io_wait() (0x8132d50+175)
 channels/chan_sip.c:29484 do_monitor()
 main/utils.c:1223 dummy_start()
 :0 start_thread()
 libc.so.6 clone() (0xb77270d0+5E)
=== ---> Lock #2 (chan_sip.c): MUTEX 17047 register_verify peer
0x86df2b8 (1)
 main/logger.c:1702 ast_bt_get_addresses() (0x813f3ee+19)
 main/lock.c:258 __ast_pthread_mutex_lock() (0x813864f+85)
 main/astobj2.c:198 __ao2_lock() (0x80906ad+7C)
 channels/chan_sip.c:17048 register_verify()
 channels/chan_sip.c:28477 handle_request_register()
 channels/chan_sip.c:28785 handle_incoming()
 channels/chan_sip.c:28953 handle_request_do()
 channels/chan_sip.c:28885 sipsock_read()
 main/io.c:292 ast_io_wait() (0x8132d50+175)
 channels/chan_sip.c:29484 do_monitor()
 main/utils.c:1223 dummy_start()
 :0 start_thread()
 libc.so.6 clone() (0xb77270d0+5E)
=== ---> Lock #3 (db.c): MUTEX 329 ast_db_put &dblock 0x8214f60 (1)
 main/logger.c:1702 ast_bt_get_addresses() (0x813f3ee+19)
 main/lock.c:380 __ast_pthread_mutex_trylock() (0x81389b7+85)
 main/db.c:329 ast_db_put() (0x80eeec4+124)
 channels/chan_sip.c:16242 parse_register_contact()
 channels/chan_sip.c:17069 register_verify()
 channels/chan_sip.c:28477 handle_request_register()
 channels/chan_sip.c:28785 handle_incoming()
 channels/chan_sip.c:28953 handle_request_do()
 channels/chan_sip.c:28885 sipsock_read()
 main/io.c:292 ast_io_wait() (0x8132d50+175)
 channels/chan_sip.c:29484 do_monitor()
 main/utils.c:1223 dummy_start()
 :0 start_thread()
 libc.so.6 clone() (0xb77270d0+5E)
=== ---
===
===


On 11.11.2015 10:03, Jaco Kroon wrote:

Hi Mark,

I suspect the following relates:


http://jkroon.blogs.uls.co.za/it/voip/asterisk-massively-speeding-up-those-register-requests


That should explain the underlying problem for you, and potentially
provide you with a fix depending on your situation.  We've been using
the proposed "workaround" there since the time of writing with no ill
effect, however, you need to take heed of the warnings posted there.

We had to modify code on at least some instances to avoid DB() dia

Re: [asterisk-dev] Lockups in Asterisk 11

2015-10-30 Thread Mark Murawski 

On 10/30/15 16:04, Mark Murawski wrote:

I'm getting the following lockup very randomly in 11.20.  This is pretty
devastating to one of my production systems.

===
=== 11.20.0
=== Currently Held Locks
===

>  snip

If this helps figure out the problem, I've added the following code to 
db.c, ast_db_put() and this appears to have alleviated the lockup


   {
int attempts = 10;

while (ast_mutex_trylock(&dblock) != 0) {
// didn't lock
attempts--;
usleep(100);

if (attempts <= 0) {
ast_log(LOG_ERROR, "ast_db_put() COULD 
NOT LOCK.  Abandon.\n");

return -1;
}
}
}

Now my logs are filling up with could not lock, but at least I'm not 
locking up entirely anymore.


--
_
-- 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] Lockups in Asterisk 11

2015-10-30 Thread Mark Murawski 
I'm getting the following lockup very randomly in 11.20.  This is pretty 
devastating to one of my production systems.


===
=== 11.20.0
=== Currently Held Locks
===
===
===   ():name>  (times locked)

===
=== Thread ID: 0xb6cffb70 (db_sync_thread   started at [ 1018] db.c 
astdb_init())

=== ---> Lock #0 (db.c): MUTEX 980 db_sync_thread &dblock 0x8214f60 (1)
main/logger.c:1702 ast_bt_get_addresses() (0x813f3a6+19)
main/lock.c:258 __ast_pthread_mutex_lock() (0x8138607+85)
main/db.c:981 db_sync_thread()
main/utils.c:1223 dummy_start()
:0 start_thread()
libc.so.6 clone() (0xb76e60d0+5E)
=== ---
===
=== Thread ID: 0xb4fc3b70 (do_monitor   started at [29517] 
chan_sip.c restart_monitor())
=== ---> Lock #0 (chan_sip.c): MUTEX 28923 handle_request_do &netlock 
0xb6190440 (1)

main/logger.c:1702 ast_bt_get_addresses() (0x813f3a6+19)
main/lock.c:258 __ast_pthread_mutex_lock() (0x8138607+85)
channels/chan_sip.c:28926 handle_request_do()
channels/chan_sip.c:28885 sipsock_read()
main/io.c:292 ast_io_wait() (0x8132d08+175)
channels/chan_sip.c:29484 do_monitor()
main/utils.c:1223 dummy_start()
:0 start_thread()
libc.so.6 clone() (0xb76e60d0+5E)
=== ---> Lock #1 (chan_sip.c): MUTEX 8959 sip_pvt_lock_full pvt 
0x8391ec8 (1)

main/logger.c:1702 ast_bt_get_addresses() (0x813f3a6+19)
main/lock.c:258 __ast_pthread_mutex_lock() (0x8138607+85)
main/astobj2.c:198 __ao2_lock() (0x80906ad+7C)
channels/chan_sip.c:8960 sip_pvt_lock_full()
channels/chan_sip.c:28939 handle_request_do()
channels/chan_sip.c:28885 sipsock_read()
main/io.c:292 ast_io_wait() (0x8132d08+175)
channels/chan_sip.c:29484 do_monitor()
main/utils.c:1223 dummy_start()
:0 start_thread()
libc.so.6 clone() (0xb76e60d0+5E)
=== ---> Lock #2 (chan_sip.c): MUTEX 17047 register_verify peer 
0xb4e44ed8 (1)

main/logger.c:1702 ast_bt_get_addresses() (0x813f3a6+19)
main/lock.c:258 __ast_pthread_mutex_lock() (0x8138607+85)
main/astobj2.c:198 __ao2_lock() (0x80906ad+7C)
channels/chan_sip.c:17048 register_verify()
channels/chan_sip.c:28477 handle_request_register()
channels/chan_sip.c:28785 handle_incoming()
channels/chan_sip.c:28953 handle_request_do()
channels/chan_sip.c:28885 sipsock_read()
main/io.c:292 ast_io_wait() (0x8132d08+175)
channels/chan_sip.c:29484 do_monitor()
main/utils.c:1223 dummy_start()
:0 start_thread()
libc.so.6 clone() (0xb76e60d0+5E)
=== ---> Waiting for Lock #3 (db.c): MUTEX 324 ast_db_put &dblock 
0x8214f60 (1)

main/logger.c:1702 ast_bt_get_addresses() (0x813f3a6+19)
main/lock.c:258 __ast_pthread_mutex_lock() (0x8138607+85)
main/db.c:325 ast_db_put() (0x80eeec4+D0)
channels/chan_sip.c:16242 parse_register_contact()
channels/chan_sip.c:17069 register_verify()
channels/chan_sip.c:28477 handle_request_register()
channels/chan_sip.c:28785 handle_incoming()
channels/chan_sip.c:28953 handle_request_do()
channels/chan_sip.c:28885 sipsock_read()
main/io.c:292 ast_io_wait() (0x8132d08+175)
channels/chan_sip.c:29484 do_monitor()
main/utils.c:1223 dummy_start()
:0 start_thread()
libc.so.6 clone() (0xb76e60d0+5E)
=== --- ---> Locked Here: db.c line 980 (db_sync_thread)
=== ---
===
=== Thread ID: 0xb4485b70 (handle_tcptls_connection started at [  745] 
tcptls.c ast_tcptls_server_root())
=== ---> Waiting for Lock #0 (chan_sip.c): MUTEX 28923 handle_request_do 
&netlock 0xb6190440 (1)

main/logger.c:1702 ast_bt_get_addresses() (0x813f3a6+19)
main/lock.c:258 __ast_pthread_mutex_lock() (0x8138607+85)
channels/chan_sip.c:28926 handle_request_do()
channels/chan_sip.c:3045 _sip_tcp_helper_thread()
channels/chan_sip.c:2572 sip_tcp_worker_fn()
main/tcptls.c:694 handle_tcptls_connection()
main/utils.c:1223 dummy_start()
:0 start_thread()
libc.so.6 clone() (0xb76e60d0+5E)
=== --- ---> Locked Here: chan_sip.c line 28923 (handle_request_do)
=== ---
===
===

--
_
-- 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] Asterisk-11 Trying to get Channel Name related to RTP/SIP Private

2015-10-30 Thread Mark Murawski 

Howdy All,

I'm working on trying to output the channel related to an rtp stream.  I 
found this line in ast_rtp_read()/res_rtp_asterisk.c and this pointed me 
to a starting position:


ast_verb(4, "%p -- Probation passed - setting RTP source address to 
%s\n", rtp, ast_sockaddr_stringify(&addr))


I figured to tried this:
{
  struct ast_channel *chan = ast_rtp_instance_get_chan(instance);
  ast_verb(4, "<%s> %p -- Probation passed - setting RTP source address 
to %s\n", chan ? ast_channel_name(chan) : "NoChannel", rtp, 
ast_sockaddr_stringify(&addr));

}

Sometimes this works, and sometimes this doesn't and I'm not sure why.

If media is setup "slowly", i'll get this:
> [2015-10-30 10:58:04.855] > [C-]  0xb4a94618 -- 
Probation passed - setting RTP source address to 192.168.5.125:


It appears that if the media is setup "fast" I'll get this output:
   > [2015-10-30 10:28:54.846]> [C-000a] 
 0x89ffda8 -- Probation passed - setting RTP source 
address to 192.168.5.123:2224
   > [2015-10-30 10:28:54.846]> [C-000a] 
 0x89ec480 -- Probation passed - setting RTP source 
address to 192.168.5.129:2250


How can I reliably get the channel name here (or pick a better spot to 
get the channel name related to rtp ports)?



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