[Serdev] Re: sending a request within transaction
Mario Kolberg
mko at cs.stir.ac.uk
Thu Jul 17 08:33:40 UTC 2003
Jiri,
thanks - sending a BYE worked!
Thanks,
Mario
Jiri Kuthan wrote:
> /* diverted to serdev -- we don't want to burden the user community with
> development, see "More help" at www.iptel.org/ser/ */
>
> If you wish to cancel pending transactions, I suggest you to look at
> the function 'cancel_uacs' -- it takes a bitmap if branches you would like
> to cancel and does exactly that job.
>
> As for the idea of doing so after receipt of 200/INVs, I suspect that has
> potential of transaction breaking. Sending a CANCEL after 200/INV is too late, many
> UASs will certainly not like it, ignore it, think they are in a call and
> keep resending 200s in a hope to get an ACK.
>
> To get around transaction/dialog state cleanly, you would need to dive in
> dialog processing, and generate a proper BYE if you want to tear down an
> existing call. That's actually a construct called "back-to-back UA".
>
> -Jiri
>
> At 07:11 PM 7/15/2003, Mario Kolberg wrote:
>
>>Hi,
>>
>>I'm trying to sent a CANCEL request within a transaction.
>>
>>User A invites user B and the messaeges are sent via proxy P. In the scenario, A sends an INVITE to B, and B replies with an 200OK. Depending on some conditions, the proxy may decide that this 200OK should not be forwarded to A. And P will send a CANCEL request to B (using request_within from the tm module). This causes two problems:
>>
>>1) Sending this request fails !sometimes! and I have no idea why. According to the log, it appears to be crashing within the request_within call. Is this because I have not filled the dialog (dlg) data structure correctly? I have attached the relevant code. Have I overlooked a data field? The log (compressed) can e obtained from http://www.cs.stir.ac.uk/~mko/crash_log.gz (search for ' BUG' in the log). Can you see anything obvious wrong? From the log it looks like the RR hooks in dlg may be incomplete???
>>
>>2) However, !sometimes! for some reason, the CANCEL actually is sent and reaches B. B then answers with a 487 Request Cancelled message and also with a 200 OK for the Cancel itself. But P when forwards the reply messages on to A, which is not aware of the CANCEL at all! I see that B has put in an extra via header with A's address into the replies. This via header is not in the CANCEL request.
>>
>>Is request_within actually the best way of doing this?
>>
>>Thanks very much for your help.
>>
>>Regards,
>>Mario
>>--
>>The University of Stirling is a university established in Scotland by
>>charter at Stirling, FK9 4LA. Privileged/Confidential Information may
>>be contained in this message. If you are not the addressee indicated
>>in this message (or responsible for delivery of the message to such
>>person), you may not disclose, copy or deliver this message to anyone
>>and any action taken or omitted to be taken in reliance on it, is
>>prohibited and may be unlawful. In such case, you should destroy this
>>message and kindly notify the sender by reply email. Please advise
>>immediately if you or your employer do not consent to Internet email
>>for messages of this kind. Opinions, conclusions and other
>>information in this message that do not relate to the official
>>business of the University of Stirling shall be understood as neither
>>given nor endorsed by it.
>>
>>
>>dlg_t* dlg;
>>
>>dlg=pkg_malloc(sizeof(dlg_t));
>>dlg->state = DLG_NEW;
>>dlg->id.loc_tag.len=0;
>>dlg->id.loc_tag.s=NULL;
>>
>>if(tmb.dlg_response_uac(dlg, msg) < 0)
>> LOG(L_ERR, "error in dlg_response_uac\n");
>> else {
>> LOG(L_ERR, "OCS reply dlg created\n");
>> dlg->loc_uri.len=from_uri.len;
>> dlg->loc_uri.s= from_uri.s;
>> dlg->rem_uri.s= to_uri.s;
>> dlg->rem_uri.len=to_uri.len;
>> dlg->id.call_id.s=callid.s;
>> dlg->id.call_id.len=callid.len;
>> dlg->loc_seq.value = cseq_int;
>>
>> cancelm.s="CANCEL";
>> cancelm.len = 6;
>>
>> LOG(L_ERR,"just before printing ...\n");
>> tmb.print_dlg(stderr, dlg);
>>
>> if(tmb.t_request_within(&cancelm, NULL, NULL, dlg, NULL, NULL) < 0)
>> LOG(L_ERR, "ocs: sending of cancel request failed!\n");
>> else {
>> LOG(L_ERR, "OCS CANCEL sent\n");
>> }
>>
>>_______________________________________________
>>Serusers mailing list
>>serusers at lists.iptel.org
>>http://lists.iptel.org/mailman/listinfo/serusers
>
>
> --
> Jiri Kuthan http://iptel.org/~jiri/
>
--
Mario Kolberg phone: +44 (0)1786 46 7440
Lecturer in Computing Science fax : +44 (0)1786 46 4551
email: mko at cs.stir.ac.uk
Department of Computing Science and Mathematics
University of Stirling
Stirling FK9 4LA
Scotland, UK
More information about the Serdev
mailing list