Hello,
I have attached the tcpdump log, and a call flow diagram, I hope it will be useful.
Maybe the problem is that the cancel request uri does not match the
invite request uri. But I tried putting modparam("tm", "ruri_matching",
0) and it didn't work.
This is the openser.cfg:
route{
# initial sanity checks -- messages with
# max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
};
if (msg:len >= 2048 ) {
sl_send_reply("513", "Message too big");
exit;
};
xlog("L_INFO", "$rm: ci=$ci ft=$ft tt=$tt
cseq=$cs ruri:$ru received from: $si:$sp \n");
# we record-route all messages -- to make sure that
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
if (!is_method("REGISTER|ACK|CANCEL")) {
record_route();
}
if (is_method("CANCEL")) {
xlog ("L_INFO", "$rm: cseq:$cs $ru: RELAYING CANCEL to $du (flags: $mF) ...\n");
t_relay();
exit();
}
# subsequent messages withing a dialog should take the
# path determined by record-routing
if (loose_route()) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
route(1);
exit;
};
# if the request is for other domain use UsrLoc
# (in case, it does not work, use the following command
# with proper names and addresses in it)
if (uri==myself) {
if (method=="REGISTER") {
# Uncomment this if you want to use digest authentication
#if (!www_authorize("openser.org", "subscriber")) {
# www_challenge("openser.org", "0");
# exit;
#};
save("location");
exit;
};
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
exit;
};
append_hf("P-hint: usrloc applied\r\n");
route(1);
};
route(1);
}
route[1] {
xlog ("L_INFO", "$rm: cseq:$cs $ru: RELAYING to $du (flags: $mF) ...\n");
if (!t_relay()) {
sl_reply_error();
};
}
This is the log of the openser:
Jan 31 11:43:36 minilab07 ./openser[15342]: INVITE:
ci=1-17070@10.161.14.105 ft=6661 tt=<null> cseq=1
ruri:sip:user4@home2.jagarvayo.dev received from:
10.161.14.59:5060
Jan 31 11:43:36 minilab07 ./openser[15342]: INVITE: cseq:1
sip:user4@home2.jagarvayo.dev: RELAYING to
sip:csm002_9a7fa601f073fb780fec6551d45facc8@10.161.14.59;lr (flags:
00000000) ...
Jan 31 11:43:38 minilab07 ./openser[15342]: CANCEL:
ci=1-17070@10.161.14.105 ft=6661 tt=<null> cseq=1
ruri:sip:10.161.14.105:6030 received from:
10.161.14.59:5060
Jan 31 11:43:38 minilab07 ./openser[15342]: CANCEL: cseq:1
sip:10.161.14.105:6030: RELAYING CANCEL to (flags: 00000000) ...
Jan 31 11:43:39 minilab07 ./openser[15341]: CANCEL:
ci=1-17070@10.161.14.105 ft=6661 tt=<null> cseq=1
ruri:sip:10.161.14.105:6030 received from:
10.161.14.59:5060
Jan 31 11:43:39 minilab07 ./openser[15341]: CANCEL: cseq:1
sip:10.161.14.105:6030: RELAYING CANCEL to (flags: 00000000) ...
Jan 31 11:43:40 minilab07 ./openser[15341]: CANCEL:
ci=1-17070@10.161.14.105 ft=6661 tt=<null> cseq=1
ruri:sip:10.161.14.105:6030 received from:
10.161.14.59:5060
Jan 31 11:43:40 minilab07 ./openser[15341]: CANCEL: cseq:1
sip:10.161.14.105:6030: RELAYING CANCEL to (flags: 00000000) ...
Jan 31 11:43:42 minilab07 ./openser[15341]: CANCEL:
ci=1-17070@10.161.14.105 ft=6661 tt=<null> cseq=1
ruri:sip:10.161.14.105:6030 received from:
10.161.14.59:50
Thanks a lot
On 1/29/06, Daniel-Constantin Mierla <
daniel@voice-system.ro> wrote:
Hello,
it is hard to watch the content of the SIP messages from the debug logs.
Could you please post the network trace for this situation? Use:
ngrep -qt port 5060
on the openser machine. That will show us the content of the SIP requests.
Cheers,
Daniel
On 01/27/06 13:03, Jose Antonio Garvayo wrote:
> *Hi,
>
> I am experiencing a problem regarding CANCEL processing, I have the
> normal config file plus the following (I got that in a previous mail)
>
> *
> if (is_method("CANCEL")) {
> t_relay();
> break;
> }
>
>
> The problem is that openserver is relaying the CANCEL, but putting a
> completely new branch tag in the Via header, instead of the same
> branch than in the INVITE that is to be cancel. I have debug dump,
> that shows that the CANCEL message is matched with the INVITE, but it
> still put a new branch in the relayed cancel, and also in the 200 OK
> response.
>
> If somebody could help me it would be great
> [...]