On 31.05.19 at 19:25 Joshua C. Colp wrote:
> On Fri, May 31, 2019, at 1:57 PM, Michael Maier wrote:
>
> <snip>
>
>>
>> Thanks Joshua!
>>
>> I added the attached changes. Afterwards, I could see one SIGSEGV so
>> far which I can't understand. I would be very happy, if you could take
>> a
>> look at it - maybe you have an idea? Most probably I'm doing something
>> I shouldn't do (locking problem)?
>>
>> What I'm doing:
>> In qualify_contact_cb, I'm checking for the status code of the received
>> response. If the status code is 494, I'm again calling
>> sip_options_qualify_contact() with the flag 494. In
>> sip_options_qualify_contact, I'm checking for the flag == 494 to add
>> the additional mediasec
>> headers.
>>
>>
>> Strangely, suddenly I could see one SIGSEGV (seems not (easily) to be
>> reproducible) in
>> qualify_contact_cb(void *token, pjsip_event e) at
>>
>> if (e->body.tsx_state.src.rdata->msg_info.msg->line.status.code == 494) {
>>
>> according core dump.
>>
>> The crash directly happened after a successful sequence of mediasec
>> relevant endpoint (endpoint2):
>>
>> - request OPTIONS
>> - response 494
>> - request OPTIONS w/ MEDIASEC
>> - response 200 OK
>> - Crash
>>
>> Obviously, there has been a problem with the processing of the received
>> 200 OK. But why?
>
> You are assuming that the callback will always have a message. This isn't
> true. The callback can occur if the request was sent and it received no
> response. The switch statement handles this, specifically the
> PJSIP_EVENT_RX_MSG type, which occurs if there is a response received.
Thanks for your very fast and kind support! I really missed the fact that there
could be a callback w/o any response because of timeout. To
be honest: I just didn't know that (but it is logically consistent because
otherwise you wouldn't know what happened)! Therefore, I moved
the check behind the switch as suggested and check at first for status ==
AVAILABLE. This should work now.
Thanks
Michael
diff -urN asterisk-16.3.0.orig/res/res_pjsip/pjsip_options.c asterisk-16.3.0/res/res_pjsip/pjsip_options.c
--- asterisk-16.3.0.orig/res/res_pjsip/pjsip_options.c 2019-04-04 16:49:57.000000000 +0200
+++ asterisk-16.3.0/res/res_pjsip/pjsip_options.c 2019-05-31 19:56:42.732000000 +0200
@@ -212,6 +212,8 @@
*/
static struct ast_taskprocessor *management_serializer;
+static int sip_options_qualify_contact(void *obj, void *arg, int flags);
+
static pj_status_t send_options_response(pjsip_rx_data *rdata, int code)
{
pjsip_endpoint *endpt = ast_sip_get_pjsip_endpoint();
@@ -801,6 +803,14 @@
break;
}
+ /* check for 494 */
+ if (status == AVAILABLE && e->body.tsx_state.src.rdata->msg_info.msg->line.status.code == 494) {
+ /* need to resend the options request with mediasec headers */
+ ast_verb(3,"detected 494 - call sip_options_qualify_contact again with mediasec header\n");
+ sip_options_qualify_contact(contact_callback_data->contact, contact_callback_data->aor_options, 494);
+ return;
+ }
+
/* Update the callback data with the new status, this will get handled in the AOR serializer */
contact_callback_data->status = status;
@@ -905,6 +915,14 @@
return 0;
}
+ if (flags && flags == 494) {
+ /* add mediasec header */
+ ast_verb(3,"OPTIONS: adding MEDIASEC headers\n");
+ ast_sip_add_header(tdata,"Security-Verify","msrp-tls;mediasec");
+ ast_sip_add_header(tdata,"Security-Verify","sdes-srtp;mediasec");
+ ast_sip_add_header(tdata,"Security-Verify","dtls-srtp;mediasec");
+ }
+
if (ast_sip_send_out_of_dialog_request(tdata, endpoint,
(int)(aor_options->qualify_timeout * 1000), contact_callback_data,
qualify_contact_cb)) {
--
_____________________________________________________________________
-- 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
