On Sat, Feb 27, 2021 at 1:57 PM Mark Murawski <[email protected]>
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.
>
<snip>
> {
> + 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.
<snip>
+ 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 and 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
