Hello Gang,
thanks for the idea, but that doesn't seem to work. At first, there is no
rdata in on_tsx_state_changed(). There is an event though, with a body
that holds some message data.
Unfortunately the callback is actually called only with events that have a
PJSIP_EVENT_TX_MSG type in the body->tsx_state member. When stepping
through the code I can see the PJSIP_EVENT_RX_MSG I would be interested
in, but literally the line before on_call_tsx_state() would be called with
the "received" event in pjsua_call_on_tsx_state_changed() "fails" - if
that is a failure at all. ;)
if (call->inv == NULL) {
/* Shouldn't happen. It happens only when we don't terminate the
* server subscription caused by REFER after the call has been
* transfered (and this call has been disconnected), and we
* receive another REFER for this call.
*/
PJSUA_UNLOCK();
return;
}
/* Notify application callback first */
if (pjsua_var.ua_cfg.cb.on_call_tsx_state) {
(*pjsua_var.ua_cfg.cb.on_call_tsx_state)(call->index, tsx, e);
It does happen. call->inv *is* NULL at that time. I have no idea if that
really is a failure or not. Fact is, on_call_tsx_state() is not called
with a received packet somewhere in its arguments when the CANCEL comes
in.
Nevertheless, thanks for taking part in my problem. :)
Regards,
Sebastian.
| You could parse Header "Reason" for incoming CANCEL at your callback
| on_tsx_state_change if using pjsip-ua API.
|
| /* Get Reason Header */
| const pj_str_t str_reason = { "Reason", 6 };
| pjsip_generic_string_hdr *reason =
| (pjsip_generic_string_hdr*)pjsip_msg_find_hdr_by_name
| (rdata->msg_info.msg,
| &str_reason, NULL);
|
| regards,
| Gang
|
| >
| > Hello everyone,
| >
| > the other day I was having a look at the sources in the
pjsip/src/pjsip
| > folder in order to evaluate the Reason: header on an incoming CANCEL.
The
| > RFC behind the idea is RFC 3326. To make things clear: we're not
talking
| > about the reason string within the status line. RFC 3326 talks about a
| > seperate header line named Reason.
| >
| > Apart from Reason not having a specific handler in sip_parser.c it
seems
| > to me, that up to inv_respond_incoming_cancel() in sip_inv.c I have
access
| > to the received data through rdata with the Reason header somewhere
inside
| > rdata->msg_info. But my on_call_state() handler is called later, after
| > PJSIP has responded to the CANCEL message. As far as I can see, I
don't
| > have access to the received headers at that point anymore.
| >
| > I don't have enough insight to provide a patch, so forgive me this
shot in
| > the dark: pjsip_endpt_create_response() in sip_util.c does copy some
| > things over from rdata->msg_info to tdata. That might be a starting
point
| > to save the received Reason header into the tx_data struct and start
to
| > support RFC 3326? That way my on_call_state() callback might have
access
| > to the Reason header through the body of the event struct given to it?
| >
| > Or does PJSIP support RFC 3326 already and I was just too ignorant to
find
| > the right spots? I'm working with a pretty current (2 weeks old)
version
| > of the 1.8.10 branch.
| >
| > Any other thoughts on that matter?
| >
| > Thanks in advance,
| > Sebastian.
