[asterisk-dev] pjsip asterisk 13.24: sips / srtp and Deutsche Telekom doesn't work because of missing mediasec parameters

[Joshua C. Colp]

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.

-- 
Joshua C. Colp
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org