Hello,
I found something that I believe is problem with CANCEL processing in tm module. I'm using openser 0.10.x today's cvs. If openser forwards an INVITE and then it receives CANCEL before it receives a provisional reply from INVITE recipient, it never forwards CANCEL to its destination. CANCEL is handled the same way as INVITE and I'm sure it hits t_relay(). Here's relevant part of the config:
xlog("L_INFO","$rm: cseq=$cs: ruri=$ru received from $si:$sp\n"); if (allow_trusted()) { if (!lookup("location")) { xlog("L_INFO","$rm: cseq=$cs: $ru: not found\n"); sl_send_reply("404","Not found"); exit; } xlog("L_INFO","$rm: cseq=$cs: lookup: $ru flags: $mF\n");; route(1); exit; } if (uri==myself) { rewritehost("192.168.80.26"); route(1); }
route[1] { xlog("L_INFO","$rm: cseq=$cs: $ru: RELAYING to $du (flags: $mF)...\n"); if (!t_relay()) { xlog("L_NOTICE","$rm: cseq=$cs: ERROR: t_relay failed\n");; if (!is_method("ACK")) { sl_reply_error(); } }; }
Here's ser log: 0(1015) INVITE: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(1015) INVITE: cseq=102: lookup: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(1015) INVITE: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1058 (flags: 00000040) 0(1015) CANCEL: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(1015) CANCEL: cseq=102: lookup: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(1015) CANCEL: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1058 (flags: 00000040) 0(1015) ACK: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(1015) <null>: cseq=102: onreply_route_log: received: 100 Trying from 192.168.76.250:1058 0(1015) <null>: cseq=102: onreply_route_log: received: 180 Ringing from 192.168.76.250:1058
I've replaced ip addresses with 192.168.x.x, but recipient is behind NAT. As you can see according to this log CANCEL is getting relayed, but ngrep actually shows that it's not sent and invited client sends "Trying", then "Ringing". It happens only if INVITE is already forwarded and CANCEL is received before any provisional reply. If CANCEL happens after openser received "100 Trying", everything works fine and call is cancelled. It looks to me as a bug or some kind of race. Any clues?
Thanks, Michael
What is the correct behavior in this scenario?
As the proxy didn't received a "100.." yet, it must not send the CANCEL. IMO it should withhold the CANCEL unless a provisional response is received, but should stop sending INVITE retransmission.
Of course this rises the problem that the callee reponses with a 200 OK instead of a provisional response and then the call can't be cancelled anymore.
regards, klaus
btw: I think this should be fixe in openser (in opposite to ser) http://openser.org/diffs-0.8.14.php (TM module)
Michael Ulitskiy wrote:
Hello,
I found something that I believe is problem with CANCEL processing in tm module. I'm using openser 0.10.x today's cvs. If openser forwards an INVITE and then it receives CANCEL before it receives a provisional reply from INVITE recipient, it never forwards CANCEL to its destination. CANCEL is handled the same way as INVITE and I'm sure it hits t_relay(). Here's relevant part of the config:
xlog("L_INFO","$rm: cseq=$cs: ruri=$ru received from $si:$sp\n"); if (allow_trusted()) { if (!lookup("location")) { xlog("L_INFO","$rm: cseq=$cs: $ru: not found\n"); sl_send_reply("404","Not found"); exit; } xlog("L_INFO","$rm: cseq=$cs: lookup: $ru flags: $mF\n");; route(1); exit; } if (uri==myself) { rewritehost("192.168.80.26"); route(1); }
route[1] { xlog("L_INFO","$rm: cseq=$cs: $ru: RELAYING to $du (flags: $mF)...\n"); if (!t_relay()) { xlog("L_NOTICE","$rm: cseq=$cs: ERROR: t_relay failed\n");; if (!is_method("ACK")) { sl_reply_error(); } }; }
Here's ser log: 0(1015) INVITE: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(1015) INVITE: cseq=102: lookup: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(1015) INVITE: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1058 (flags: 00000040) 0(1015) CANCEL: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(1015) CANCEL: cseq=102: lookup: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(1015) CANCEL: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1058 (flags: 00000040) 0(1015) ACK: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(1015) <null>: cseq=102: onreply_route_log: received: 100 Trying from 192.168.76.250:1058 0(1015) <null>: cseq=102: onreply_route_log: received: 180 Ringing from 192.168.76.250:1058
I've replaced ip addresses with 192.168.x.x, but recipient is behind NAT. As you can see according to this log CANCEL is getting relayed, but ngrep actually shows that it's not sent and invited client sends "Trying", then "Ringing". It happens only if INVITE is already forwarded and CANCEL is received before any provisional reply. If CANCEL happens after openser received "100 Trying", everything works fine and call is cancelled. It looks to me as a bug or some kind of race. Any clues?
Thanks, Michael
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
On Tuesday 02 August 2005 06:25 pm, you wrote:
What is the correct behavior in this scenario?
As the proxy didn't received a "100.." yet, it must not send the CANCEL. IMO it should withhold the CANCEL unless a provisional response is received, but should stop sending INVITE retransmission.
I must confess, I didn't read RFC specifically on this subject, but behavior you described makes no sense to me. If proxy didn't cancel the call the callee keeps ringing forever.
Of course this rises the problem that the callee reponses with a 200 OK instead of a provisional response and then the call can't be cancelled anymore.
it's not the case here. UA replies correctly with 100, but a little too late. It was my understanding that CANCEL should be forwarded to cancel a call regardless of receiving any response. Please correct me if I'm wrong.
regards, klaus
btw: I think this should be fixe in openser (in opposite to ser) http://openser.org/diffs-0.8.14.php (TM module)
Michael Ulitskiy wrote:
Hello,
I found something that I believe is problem with CANCEL processing in tm module. I'm using openser 0.10.x today's cvs. If openser forwards an INVITE and then it receives CANCEL before it receives a provisional reply from INVITE recipient, it never forwards CANCEL to its destination. CANCEL is handled the same way as INVITE and I'm sure it hits t_relay(). Here's relevant part of the config:
xlog("L_INFO","$rm: cseq=$cs: ruri=$ru received from $si:$sp\n"); if (allow_trusted()) { if (!lookup("location")) { xlog("L_INFO","$rm: cseq=$cs: $ru: not found\n"); sl_send_reply("404","Not found"); exit; } xlog("L_INFO","$rm: cseq=$cs: lookup: $ru flags: $mF\n");; route(1); exit; } if (uri==myself) { rewritehost("192.168.80.26"); route(1); }
route[1] { xlog("L_INFO","$rm: cseq=$cs: $ru: RELAYING to $du (flags: $mF)...\n"); if (!t_relay()) { xlog("L_NOTICE","$rm: cseq=$cs: ERROR: t_relay failed\n");; if (!is_method("ACK")) { sl_reply_error(); } }; }
Here's ser log: 0(1015) INVITE: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(1015) INVITE: cseq=102: lookup: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(1015) INVITE: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1058 (flags: 00000040) 0(1015) CANCEL: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(1015) CANCEL: cseq=102: lookup: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(1015) CANCEL: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1058 (flags: 00000040) 0(1015) ACK: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(1015) <null>: cseq=102: onreply_route_log: received: 100 Trying from 192.168.76.250:1058 0(1015) <null>: cseq=102: onreply_route_log: received: 180 Ringing from 192.168.76.250:1058
I've replaced ip addresses with 192.168.x.x, but recipient is behind NAT. As you can see according to this log CANCEL is getting relayed, but ngrep actually shows that it's not sent and invited client sends "Trying", then "Ringing". It happens only if INVITE is already forwarded and CANCEL is received before any provisional reply. If CANCEL happens after openser received "100 Trying", everything works fine and call is cancelled. It looks to me as a bug or some kind of race. Any clues?
Thanks, Michael
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Michael!
RFC3261 page 54: If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request.
Thus, the proxy should withhold the CANCEL until a provisional response is received. If no provisional response is received for a certain time, the proxy may discard the whole transaction.
Also take a look at section 16.10 and section 16.7 step 10.
regards klaus
Michael Ulitskiy wrote:
On Tuesday 02 August 2005 06:25 pm, you wrote:
What is the correct behavior in this scenario?
As the proxy didn't received a "100.." yet, it must not send the CANCEL. IMO it should withhold the CANCEL unless a provisional response is received, but should stop sending INVITE retransmission.
I must confess, I didn't read RFC specifically on this subject, but behavior you described makes no sense to me. If proxy didn't cancel the call the callee keeps ringing forever.
Of course this rises the problem that the callee reponses with a 200 OK instead of a provisional response and then the call can't be cancelled anymore.
it's not the case here. UA replies correctly with 100, but a little too late. It was my understanding that CANCEL should be forwarded to cancel a call regardless of receiving any response. Please correct me if I'm wrong.
regards, klaus
btw: I think this should be fixe in openser (in opposite to ser) http://openser.org/diffs-0.8.14.php (TM module)
Michael Ulitskiy wrote:
Hello,
I found something that I believe is problem with CANCEL processing in tm module. I'm using openser 0.10.x today's cvs. If openser forwards an INVITE and then it receives CANCEL before it receives a provisional reply from INVITE recipient, it never forwards CANCEL to its destination. CANCEL is handled the same way as INVITE and I'm sure it hits t_relay(). Here's relevant part of the config:
xlog("L_INFO","$rm: cseq=$cs: ruri=$ru received from $si:$sp\n"); if (allow_trusted()) { if (!lookup("location")) { xlog("L_INFO","$rm: cseq=$cs: $ru: not found\n"); sl_send_reply("404","Not found"); exit; } xlog("L_INFO","$rm: cseq=$cs: lookup: $ru flags: $mF\n");; route(1); exit; } if (uri==myself) { rewritehost("192.168.80.26"); route(1); }
route[1] { xlog("L_INFO","$rm: cseq=$cs: $ru: RELAYING to $du (flags: $mF)...\n"); if (!t_relay()) { xlog("L_NOTICE","$rm: cseq=$cs: ERROR: t_relay failed\n");; if (!is_method("ACK")) { sl_reply_error(); } }; }
Here's ser log: 0(1015) INVITE: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(1015) INVITE: cseq=102: lookup: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(1015) INVITE: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1058 (flags: 00000040) 0(1015) CANCEL: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(1015) CANCEL: cseq=102: lookup: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(1015) CANCEL: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1058 (flags: 00000040) 0(1015) ACK: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(1015) <null>: cseq=102: onreply_route_log: received: 100 Trying from 192.168.76.250:1058 0(1015) <null>: cseq=102: onreply_route_log: received: 180 Ringing from 192.168.76.250:1058
I've replaced ip addresses with 192.168.x.x, but recipient is behind NAT. As you can see according to this log CANCEL is getting relayed, but ngrep actually shows that it's not sent and invited client sends "Trying", then "Ringing". It happens only if INVITE is already forwarded and CANCEL is received before any provisional reply. If CANCEL happens after openser received "100 Trying", everything works fine and call is cancelled. It looks to me as a bug or some kind of race. Any clues?
Thanks, Michael
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Klaus,
I guess, you're right. I didn't know that. Then openser should keep CANCEL in transaction context until transaction expires (probably until wt_timer expires) and transmit it if provisional response is received during that time. Thanks for clarification.
Michael
On Tuesday 02 August 2005 07:52 pm, you wrote:
Hi Michael!
RFC3261 page 54: If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request.
Thus, the proxy should withhold the CANCEL until a provisional response is received. If no provisional response is received for a certain time, the proxy may discard the whole transaction.
Also take a look at section 16.10 and section 16.7 step 10.
regards klaus
Michael Ulitskiy wrote:
On Tuesday 02 August 2005 06:25 pm, you wrote:
What is the correct behavior in this scenario?
As the proxy didn't received a "100.." yet, it must not send the CANCEL. IMO it should withhold the CANCEL unless a provisional response is received, but should stop sending INVITE retransmission.
I must confess, I didn't read RFC specifically on this subject, but behavior you described makes no sense to me. If proxy didn't cancel the call the callee keeps ringing forever.
Of course this rises the problem that the callee reponses with a 200 OK instead of a provisional response and then the call can't be cancelled anymore.
it's not the case here. UA replies correctly with 100, but a little too late. It was my understanding that CANCEL should be forwarded to cancel a call regardless of receiving any response. Please correct me if I'm wrong.
regards, klaus
btw: I think this should be fixe in openser (in opposite to ser) http://openser.org/diffs-0.8.14.php (TM module)
Michael Ulitskiy wrote:
Hello,
I found something that I believe is problem with CANCEL processing in tm module. I'm using openser 0.10.x today's cvs. If openser forwards an INVITE and then it receives CANCEL before it receives a provisional reply from INVITE recipient, it never forwards CANCEL to its destination. CANCEL is handled the same way as INVITE and I'm sure it hits t_relay(). Here's relevant part of the config:
xlog("L_INFO","$rm: cseq=$cs: ruri=$ru received from $si:$sp\n"); if (allow_trusted()) { if (!lookup("location")) { xlog("L_INFO","$rm: cseq=$cs: $ru: not found\n"); sl_send_reply("404","Not found"); exit; } xlog("L_INFO","$rm: cseq=$cs: lookup: $ru flags: $mF\n");; route(1); exit; } if (uri==myself) { rewritehost("192.168.80.26"); route(1); }
route[1] { xlog("L_INFO","$rm: cseq=$cs: $ru: RELAYING to $du (flags: $mF)...\n"); if (!t_relay()) { xlog("L_NOTICE","$rm: cseq=$cs: ERROR: t_relay failed\n");; if (!is_method("ACK")) { sl_reply_error(); } }; }
Here's ser log: 0(1015) INVITE: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(1015) INVITE: cseq=102: lookup: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(1015) INVITE: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1058 (flags: 00000040) 0(1015) CANCEL: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(1015) CANCEL: cseq=102: lookup: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(1015) CANCEL: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1058 (flags: 00000040) 0(1015) ACK: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(1015) <null>: cseq=102: onreply_route_log: received: 100 Trying from 192.168.76.250:1058 0(1015) <null>: cseq=102: onreply_route_log: received: 180 Ringing from 192.168.76.250:1058
I've replaced ip addresses with 192.168.x.x, but recipient is behind NAT. As you can see according to this log CANCEL is getting relayed, but ngrep actually shows that it's not sent and invited client sends "Trying", then "Ringing". It happens only if INVITE is already forwarded and CANCEL is received before any provisional reply. If CANCEL happens after openser received "100 Trying", everything works fine and call is cancelled. It looks to me as a bug or some kind of race. Any clues?
Thanks, Michael
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Michael,
that's exactly the trick I wanted to try to solve this issue (see my previous email)...but I will have to dig to see how difficult is to implement.
regards, bogdan
Michael Ulitskiy wrote:
Hi Klaus,
I guess, you're right. I didn't know that. Then openser should keep CANCEL in transaction context until transaction expires (probably until wt_timer expires) and transmit it if provisional response is received during that time. Thanks for clarification.
Michael
On Tuesday 02 August 2005 07:52 pm, you wrote:
Hi Michael!
RFC3261 page 54: If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request.
Thus, the proxy should withhold the CANCEL until a provisional response is received. If no provisional response is received for a certain time, the proxy may discard the whole transaction.
Also take a look at section 16.10 and section 16.7 step 10.
regards klaus
Great! Thanks Bogdan! I'll be the first to test it. I just wanted to point out that it's really amusing how responsive openser developers are and how impressive openser development pace is. Very good experience so far. Thanks a lot.
Michael
On Wednesday 03 August 2005 11:32 am, Bogdan-Andrei Iancu wrote:
Hi Michael,
that's exactly the trick I wanted to try to solve this issue (see my previous email)...but I will have to dig to see how difficult is to implement.
regards, bogdan
Michael Ulitskiy wrote:
Hi Klaus,
I guess, you're right. I didn't know that. Then openser should keep CANCEL in transaction context until transaction expires (probably until wt_timer expires) and transmit it if provisional response is received during that time. Thanks for clarification.
Michael
On Tuesday 02 August 2005 07:52 pm, you wrote:
Hi Michael!
RFC3261 page 54: If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request.
Thus, the proxy should withhold the CANCEL until a provisional response is received. If no provisional response is received for a certain time, the proxy may discard the whole transaction.
Also take a look at section 16.10 and section 16.7 step 10.
regards klaus
Hi Michael,
I added in TM some code which should solve this problem - unfortunately is not tested yet since the scenario is quite difficult to reproduce. Can you please give it a try a report de output - crash, the same or success?
thanks and regards, bogdan
Michael Ulitskiy wrote:
Great! Thanks Bogdan! I'll be the first to test it. I just wanted to point out that it's really amusing how responsive openser developers are and how impressive openser development pace is. Very good experience so far. Thanks a lot.
Michael
On Wednesday 03 August 2005 11:32 am, Bogdan-Andrei Iancu wrote:
Hi Michael,
that's exactly the trick I wanted to try to solve this issue (see my previous email)...but I will have to dig to see how difficult is to implement.
regards, bogdan
Michael Ulitskiy wrote:
Hi Klaus,
I guess, you're right. I didn't know that. Then openser should keep CANCEL in transaction context until transaction expires (probably until wt_timer expires) and transmit it if provisional response is received during that time. Thanks for clarification.
Michael
On Tuesday 02 August 2005 07:52 pm, you wrote:
Hi Michael!
RFC3261 page 54: If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request.
Thus, the proxy should withhold the CANCEL until a provisional response is received. If no provisional response is received for a certain time, the proxy may discard the whole transaction.
Also take a look at section 16.10 and section 16.7 step 10.
regards klaus
Hi Bogdan,
Sure. Will do as soon as it available via CVS. Thanks,
Michael
On Monday 15 August 2005 01:03 pm, Bogdan-Andrei Iancu wrote:
Hi Michael,
I added in TM some code which should solve this problem - unfortunately is not tested yet since the scenario is quite difficult to reproduce. Can you please give it a try a report de output - crash, the same or success?
thanks and regards, bogdan
Michael Ulitskiy wrote:
Great! Thanks Bogdan! I'll be the first to test it. I just wanted to point out that it's really amusing how responsive openser developers are and how impressive openser development pace is. Very good experience so far. Thanks a lot.
Michael
On Wednesday 03 August 2005 11:32 am, Bogdan-Andrei Iancu wrote:
Hi Michael,
that's exactly the trick I wanted to try to solve this issue (see my previous email)...but I will have to dig to see how difficult is to implement.
regards, bogdan
Michael Ulitskiy wrote:
Hi Klaus,
I guess, you're right. I didn't know that. Then openser should keep CANCEL in transaction context until transaction expires (probably until wt_timer expires) and transmit it if provisional response is received during that time. Thanks for clarification.
Michael
On Tuesday 02 August 2005 07:52 pm, you wrote:
Hi Michael!
RFC3261 page 54: If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request.
Thus, the proxy should withhold the CANCEL until a provisional response is received. If no provisional response is received for a certain time, the proxy may discard the whole transaction.
Also take a look at section 16.10 and section 16.7 step 10.
regards klaus
Bogdan,
The problem is still there and actually I can't see any difference.
0(14899) INVITE: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(14899) INVITE: cseq=102: looked up: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(14899) INVITE: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1083 (flags: 00000040)... 0(14899) CANCEL: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(14899) CANCEL: cseq=102: looked up: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(14899) CANCEL: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1083 (flags: 00000040)... 0(14899) ACK: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(14899) <null>: cseq=102: onreply_route_log: received: 100 Trying from 192.168.76.250:1083 0(14899) <null>: cseq=102: onreply_route_log: received: 180 Ringing from 192.168.76.250:1083
ngrep shows that CANCEL is never get sent to the user xyz_100_1_st2 at 192.168.76.250:1083
Michael
On Monday 15 August 2005 01:03 pm, Bogdan-Andrei Iancu wrote:
Hi Michael,
I added in TM some code which should solve this problem - unfortunately is not tested yet since the scenario is quite difficult to reproduce. Can you please give it a try a report de output - crash, the same or success?
thanks and regards, bogdan
Michael Ulitskiy wrote:
Great! Thanks Bogdan! I'll be the first to test it. I just wanted to point out that it's really amusing how responsive openser developers are and how impressive openser development pace is. Very good experience so far. Thanks a lot.
Michael
On Wednesday 03 August 2005 11:32 am, Bogdan-Andrei Iancu wrote:
Hi Michael,
that's exactly the trick I wanted to try to solve this issue (see my previous email)...but I will have to dig to see how difficult is to implement.
regards, bogdan
Michael Ulitskiy wrote:
Hi Klaus,
I guess, you're right. I didn't know that. Then openser should keep CANCEL in transaction context until transaction expires (probably until wt_timer expires) and transmit it if provisional response is received during that time. Thanks for clarification.
Michael
On Tuesday 02 August 2005 07:52 pm, you wrote:
Hi Michael!
RFC3261 page 54: If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request.
Thus, the proxy should withhold the CANCEL until a provisional response is received. If no provisional response is received for a certain time, the proxy may discard the whole transaction.
Also take a look at section 16.10 and section 16.7 step 10.
regards klaus
Hi Michael,
I found and fixed the problem - I was able to reproduce in a testbed the scenario and to properly test it. Let me know if it work ok for you also.
regards, bogdan
Michael Ulitskiy wrote:
Bogdan,
The problem is still there and actually I can't see any difference.
0(14899) INVITE: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(14899) INVITE: cseq=102: looked up: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(14899) INVITE: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1083 (flags: 00000040)... 0(14899) CANCEL: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(14899) CANCEL: cseq=102: looked up: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(14899) CANCEL: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1083 (flags: 00000040)... 0(14899) ACK: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(14899) <null>: cseq=102: onreply_route_log: received: 100 Trying from 192.168.76.250:1083 0(14899) <null>: cseq=102: onreply_route_log: received: 180 Ringing from 192.168.76.250:1083
ngrep shows that CANCEL is never get sent to the user xyz_100_1_st2 at 192.168.76.250:1083
Michael
On Monday 15 August 2005 01:03 pm, Bogdan-Andrei Iancu wrote:
Hi Michael,
I added in TM some code which should solve this problem - unfortunately is not tested yet since the scenario is quite difficult to reproduce. Can you please give it a try a report de output - crash, the same or success?
thanks and regards, bogdan
Michael Ulitskiy wrote:
Great! Thanks Bogdan! I'll be the first to test it. I just wanted to point out that it's really amusing how responsive openser developers are and how impressive openser development pace is. Very good experience so far. Thanks a lot.
Michael
On Wednesday 03 August 2005 11:32 am, Bogdan-Andrei Iancu wrote:
Hi Michael,
that's exactly the trick I wanted to try to solve this issue (see my previous email)...but I will have to dig to see how difficult is to implement.
regards, bogdan
Hi Bogdan,
It seems to work perfect now. Thanks a lot. I've given it a limited testing so far, but I'll definitely let you know if I notice any problems with it. Thanks again,
Michael
On Tuesday 16 August 2005 11:17 am, Bogdan-Andrei Iancu wrote:
Hi Michael,
I found and fixed the problem - I was able to reproduce in a testbed the scenario and to properly test it. Let me know if it work ok for you also.
regards, bogdan
Michael Ulitskiy wrote:
Bogdan,
The problem is still there and actually I can't see any difference.
0(14899) INVITE: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(14899) INVITE: cseq=102: looked up: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(14899) INVITE: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1083 (flags: 00000040)... 0(14899) CANCEL: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(14899) CANCEL: cseq=102: looked up: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(14899) CANCEL: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1083 (flags: 00000040)... 0(14899) ACK: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(14899) <null>: cseq=102: onreply_route_log: received: 100 Trying from 192.168.76.250:1083 0(14899) <null>: cseq=102: onreply_route_log: received: 180 Ringing from 192.168.76.250:1083
ngrep shows that CANCEL is never get sent to the user xyz_100_1_st2 at 192.168.76.250:1083
Michael
On Monday 15 August 2005 01:03 pm, Bogdan-Andrei Iancu wrote:
Hi Michael,
I added in TM some code which should solve this problem - unfortunately is not tested yet since the scenario is quite difficult to reproduce. Can you please give it a try a report de output - crash, the same or success?
thanks and regards, bogdan
Michael Ulitskiy wrote:
Great! Thanks Bogdan! I'll be the first to test it. I just wanted to point out that it's really amusing how responsive openser developers are and how impressive openser development pace is. Very good experience so far. Thanks a lot.
Michael
On Wednesday 03 August 2005 11:32 am, Bogdan-Andrei Iancu wrote:
Hi Michael,
that's exactly the trick I wanted to try to solve this issue (see my previous email)...but I will have to dig to see how difficult is to implement.
regards, bogdan
Hi Michael,
the UAS must notify ASAP the upstream parties when the INVITE was received. Of course, network delays may interfere :(.
If I get it right, you are experience a *FAST* cancel from the UAC (since the proxy haven't received the 100 -even if delayed- from UAC). Is this the case?
If so, since it's not the fault of any parties, I will try to see if there is a way to solve this kind of race.
regards, Bogdan
Michael Ulitskiy wrote:
On Tuesday 02 August 2005 06:25 pm, you wrote:
What is the correct behavior in this scenario?
As the proxy didn't received a "100.." yet, it must not send the CANCEL. IMO it should withhold the CANCEL unless a provisional response is received, but should stop sending INVITE retransmission.
I must confess, I didn't read RFC specifically on this subject, but behavior you described makes no sense to me. If proxy didn't cancel the call the callee keeps ringing forever.
Of course this rises the problem that the callee reponses with a 200 OK instead of a provisional response and then the call can't be cancelled anymore.
it's not the case here. UA replies correctly with 100, but a little too late. It was my understanding that CANCEL should be forwarded to cancel a call regardless of receiving any response. Please correct me if I'm wrong.
On Wednesday 03 August 2005 05:29 am, you wrote:
Hi Michael,
the UAS must notify ASAP the upstream parties when the INVITE was received. Of course, network delays may interfere :(.
If I get it right, you are experience a *FAST* cancel from the UAC (since the proxy haven't received the 100 -even if delayed- from UAC). Is this the case?
Well, the caller sends INVITE to the proxy and then almost immediately it sends CANCEL, but CANCEL happens at the short period of time while INVITE has already been forwarded to callee, but no provisional response from callee has yet been received. "100" and "180" are arriving almost immediately after CANCEL has been processed by openser. I guess this situation is legitimate and in my observations is not quite rare.
If so, since it's not the fault of any parties, I will try to see if there is a way to solve this kind of race.
I don't think it's a fault of caller or callee UACs. I guess, as it's been pointed out by Klaus, openser should keep CANCEL in transaction context until transaction expires (probably until wt_timer expires) and transmit it if provisional response is received during that time.
regards, Bogdan
Michael Ulitskiy wrote:
On Tuesday 02 August 2005 06:25 pm, you wrote:
What is the correct behavior in this scenario?
As the proxy didn't received a "100.." yet, it must not send the CANCEL. IMO it should withhold the CANCEL unless a provisional response is received, but should stop sending INVITE retransmission.
I must confess, I didn't read RFC specifically on this subject, but behavior you described makes no sense to me. If proxy didn't cancel the call the callee keeps ringing forever.
Of course this rises the problem that the callee reponses with a 200 OK instead of a provisional response and then the call can't be cancelled anymore.
it's not the case here. UA replies correctly with 100, but a little too late. It was my understanding that CANCEL should be forwarded to cancel a call regardless of receiving any response. Please correct me if I'm wrong.
Hi guys,
Klaus Darilion wrote:
What is the correct behavior in this scenario?
As the proxy didn't received a "100.." yet, it must not send the CANCEL. IMO it should withhold the CANCEL unless a provisional response is received, but should stop sending INVITE retransmission.
Of course this rises the problem that the callee reponses with a 200 OK instead of a provisional response and then the call can't be cancelled anymore.
This is a well known race which may happen in SIP flows even in direct UAC to UAS configuration (without any middle entity). The 200 OK (from UAS) and the CANCEL (from UAC) may cross one the way.... This kind of race can be detected and solved only by the end points (UAs): if a UAC sent CANCEL and receives 200 OK -> it should generate a BYE if a UAS sent 200 OK and received a CANCEL -> it should also generate a BYE. basically the race may be detected only by on of the end-points (which will also trigger the BYE), but for safety reason (since the "intelligence" of other party is not known), both parties should try to BYE the call if race was detected.
This is not RFC specified, but IMHO, it's the way it should be solved.
regards, bogdan
regards, klaus
btw: I think this should be fixe in openser (in opposite to ser) http://openser.org/diffs-0.8.14.php (TM module)
Michael Ulitskiy wrote:
Hello,
I found something that I believe is problem with CANCEL processing in tm module. I'm using openser 0.10.x today's cvs. If openser forwards an INVITE and then it receives CANCEL before it receives a provisional reply from INVITE recipient, it never forwards CANCEL to its destination. CANCEL is handled the same way as INVITE and I'm sure it hits t_relay(). Here's relevant part of the config:
xlog("L_INFO","$rm: cseq=$cs: ruri=$ru received from $si:$sp\n"); if (allow_trusted()) { if (!lookup("location")) { xlog("L_INFO","$rm: cseq=$cs: $ru: not found\n"); sl_send_reply("404","Not found"); exit; } xlog("L_INFO","$rm: cseq=$cs: lookup: $ru flags: $mF\n");; route(1); exit; } if (uri==myself) { rewritehost("192.168.80.26"); route(1); }
route[1] { xlog("L_INFO","$rm: cseq=$cs: $ru: RELAYING to $du (flags: $mF)...\n"); if (!t_relay()) { xlog("L_NOTICE","$rm: cseq=$cs: ERROR: t_relay failed\n");; if (!is_method("ACK")) { sl_reply_error(); } }; }
Here's ser log: 0(1015) INVITE: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(1015) INVITE: cseq=102: lookup: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(1015) INVITE: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1058 (flags: 00000040) 0(1015) CANCEL: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(1015) CANCEL: cseq=102: lookup: sip:xyz_100_1_st2@192.168.0.249:5060 flags: 00000040 0(1015) CANCEL: cseq=102: sip:xyz_100_1_st2@192.168.0.249:5060: RELAYING to sip:192.168.76.250:1058 (flags: 00000040) 0(1015) ACK: cseq=102: ruri=sip:xyz_100_1_st2@192.168.83.61 received from 192.168.80.26:5060 0(1015) <null>: cseq=102: onreply_route_log: received: 100 Trying from 192.168.76.250:1058 0(1015) <null>: cseq=102: onreply_route_log: received: 180 Ringing from 192.168.76.250:1058
I've replaced ip addresses with 192.168.x.x, but recipient is behind NAT. As you can see according to this log CANCEL is getting relayed, but ngrep actually shows that it's not sent and invited client sends "Trying", then "Ringing". It happens only if INVITE is already forwarded and CANCEL is received before any provisional reply. If CANCEL happens after openser received "100 Trying", everything works fine and call is cancelled. It looks to me as a bug or some kind of race. Any clues?
Thanks, Michael
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-
Bogdan-Andrei Iancu -
Klaus Darilion -
Michael Ulitskiy