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.105ft=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.105ft=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.105ft=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.105ft=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.105ft=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 [...]