sorry, I am talking about pjsip-ua API.
But after a quickly review PJSUA code, I guest we still can get that
Reason data from
your own on_call_tsx_state() callback, you could follow the same way
as how pjsua handle
incoming MESSAGE/REFER at pjsua_call_on_tsx_state_changed()
the data is at
e->body.tsx_state.src.rdata
if tsx ROLE is UAS and tsx state is TRYING.
regards,
Gang
On Wed, Mar 2, 2011 at 8:44 PM, <s.marek at avm.de> wrote:
> 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.
>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
