16 Jul
2003
16 Jul
'03
3:14 a.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers