[Serusers] sending a request within transaction

[Jan Janak]

Hello,

I am now travelling. I will check the logs next week when I am back in
the office. Please be patient.

  Jan.

On 15-07 18:11, 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