[Serusers] SER Nokia CANCEL Problem

List overview All Threads
Download

newer

older

[OpenSER-Users] 200 OK...

[OpenSER-Users] Pseudovariable for...

Abdul Qadir

15 Feb 2007 15 Feb '07

5:16 p.m.

Hi , I tried to call from one nokia sip (E61 and other models )phone to another nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation. I tried to capture a log of message and found that Phone A "CANCEL" message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct. Is there any way I can stop 100 Trying message and still run statefull SER, so that I can verify what nokia said. Any ideas suggestions are welcome. Thanking you all in advance. Best Regards, Abdul Qadir --------------------------------- Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.

Attachments:

attachment.html (text/html — 1.4 KB)

Show replies by thread

samuel

16 Feb 16 Feb

10:07 a.m.

The 100 Trying is hardcoded and you'll have to look for it in the code, remove it, and recompile. After that, you should send back from your config file the 100 Trying response in the convenient places to stop retransmissions. Samuel. 2007/2/15, Abdul Qadir <ablqadir(a)yahoo.com>om>:

...

Hi , I tried to call from one nokia sip (E61 and other models )phone to another nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation. I tried to capture a log of message and found that Phone A "CANCEL" message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct. Is there any way I can stop 100 Trying message and still run statefull SER, so that I can verify what nokia said. Any ideas suggestions are welcome. Thanking you all in advance. Best Regards, Abdul Qadir ________________________________ Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends. _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Abdul Qadir

11 a.m.

Hi, Thanx for the tip, I found the file and will try this way. Is there any way we can get user agent value inside the script, so that i can put some check for it and decide whether to send 100 or not. Thanks Abdul Qadir samuel <samu60(a)gmail.com> wrote: The 100 Trying is hardcoded and you'll have to look for it in the code, remove it, and recompile. After that, you should send back from your config file the 100 Trying response in the convenient places to stop retransmissions. Samuel. 2007/2/15, Abdul Qadir :

...

Hi , I tried to call from one nokia sip (E61 and other models )phone to another nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation. I tried to capture a log of message and found that Phone A "CANCEL" message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct. Is there any way I can stop 100 Trying message and still run statefull SER, so that I can verify what nokia said. Any ideas suggestions are welcome. Thanking you all in advance. Best Regards, Abdul Qadir ________________________________ Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends. _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

--------------------------------- Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.

Klaus Darilion

1:02 p.m.

Abdul Qadir wrote:

...

Hi! I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies. regards klasu

...

I tried to capture a log of message and found that Phone A "CANCEL" message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct. Is there any way I can stop 100 Trying message and still run statefull SER, so that I can verify what nokia said. Any ideas suggestions are welcome. Thanking you all in advance. Best Regards, Abdul Qadir --------------------------------- Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends. ------------------------------------------------------------------------ _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Klaus Darilion nic.at

samuel

1:12 p.m.

tectops module with search is the only way to get the User-Agent in SER version 0.9.x If you're using newer versions you can use select framework to get the value of any (?) header of the incoming SIP request. Samuel. 2007/2/16, Abdul Qadir <ablqadir(a)yahoo.com>om>:

...

A).

The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation. I tried to capture a log of message and found that Phone A "CANCEL"

message

is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct. Is there any way I can stop 100 Trying message and still run statefull

SER,

so that I can verify what nokia said. Any ideas suggestions are welcome. Thanking you all in advance. Best Regards, Abdul Qadir ________________________________ Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends. _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

________________________________ Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.

Abdul Qadir

1:34 p.m.

Hi,

...

I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.

At present I don't think its working like this, As soon as CANCEL hit SER an immediate too many hops is returned to sender and call continues....resulting in ghost call, where A party has dropped after sending cancel and B still carries on as no cancel was sent to B. Best Regards, Abdul Qadir Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote: Abdul Qadir wrote:

...

Hi! I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies. regards klasu

...

-- Klaus Darilion nic.at --------------------------------- Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A.

samuel

1:51 p.m.

That's a race condition in SER solved in newer versions. I observed always this behaviour and new versions properly matches CANCEL with INVITE transaction and the "sipiral" (ending in Too Many Hops) does not occur. Samuel. 2007/2/16, Abdul Qadir <ablqadir(a)yahoo.com>om>:

...

Hi,

I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.

Hi , I tried to call from one nokia sip (E61 and other models )phone to another

nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation.

Hi! I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies. regards klasu

I tried to capture a log of message and found that Phone A "CANCEL"

message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct.

> Is there any way I can stop 100 Trying message and still run statefull SER, so that I can verify what nokia said. Any ideas suggestions are welcome.

> Thanking you all in advance.

> Best Regards, > Abdul Qadir

> --------------------------------- > Don't be flakey. Get Yahoo! Mail for Mobile and > always stay connected to friends.

------------------------------------------------------------------------

> _______________________________________________ > Serusers mailing list > Serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers -- Klaus Darilion nic.at ________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Greger V. Teigre

1:53 p.m.

It may be that you are not handling the CANCEL correctly. An early CANCEL (no Route headers) will have to be routed as an INVITE. g-) Abdul Qadir wrote:

...

Hi,

I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.

At present I don't think its working like this, As soon as CANCEL hit SER an immediate too many hops is returned to sender and call continues....resulting in ghost call, where A party has dropped after sending cancel and B still carries on as no cancel was sent to B. Best Regards, Abdul Qadir */Klaus Darilion <klaus.mailinglists(a)pernau.at>/* wrote: Abdul Qadir wrote:

Hi , I tried to call from one nokia sip (E61 and other models )phone

to another nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation.

Hi! I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies. regards klasu

I tried to capture a log of message and found that Phone A

"CANCEL" message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct.

> Is there any way I can stop 100 Trying message and still run statefull SER, so that I can verify what nokia said. Any ideas suggestions are welcome.

> Thanking you all in advance.

> Best Regards, > Abdul Qadir

> --------------------------------- > Don't be flakey. Get Yahoo! Mail for Mobile and > always stay connected to friends.

------------------------------------------------------------------------

> _______________________________________________ > Serusers mailing list > Serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers -- Klaus Darilion nic.at ------------------------------------------------------------------------ Food fight? <http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367> Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. <http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367> ------------------------------------------------------------------------ _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

samuel

1:55 p.m.

...

It may be that you are not handling the CANCEL correctly. An early CANCEL (no Route headers) will have to be routed as an INVITE. g-) Abdul Qadir wrote: Hi,

I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.

Hi , I tried to call from one nokia sip (E61 and other models )phone to

another nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation.

Hi! I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies. regards klasu

I tried to capture a log of message and found that Phone A "CANCEL"

> Is there any way I can stop 100 Trying message and still run statefull SER, so that I can verify what nokia said. Any ideas suggestions are welcome.

> Thanking you all in advance.

> Best Regards, > Abdul Qadir

> --------------------------------- > Don't be flakey. Get Yahoo! Mail for Mobile and > always stay connected to friends.

------------------------------------------------------------------------

> _______________________________________________ > Serusers mailing list > Serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers -- Klaus Darilion nic.at ________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. ________________________________ _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

samuel

2:02 p.m.

i'm pretty sure CANCEL hits t_relay and should be matched agains INVITE transaction...the only main routing difference between CANCEL and INVITE is NAT stuff and lookupXXXX which I think it does not affect this thread's topic, or did i miss something?? Try to dial a number and immediately hang up...don't you see the Too Many Hops? Samuel. 2007/2/16, samuel <samu60(a)gmail.com>om>:

...

It may be that you are not handling the CANCEL correctly. An early CANCEL (no Route headers) will have to be routed as an INVITE. g-) Abdul Qadir wrote: Hi,

I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.

Hi , I tried to call from one nokia sip (E61 and other models )phone to

Hi! I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies. regards klasu

I tried to capture a log of message and found that Phone A "CANCEL"

> Is there any way I can stop 100 Trying message and still run statefull SER, so that I can verify what nokia said. Any ideas suggestions are welcome.

> Thanking you all in advance.

> Best Regards, > Abdul Qadir

> --------------------------------- > Don't be flakey. Get Yahoo! Mail for Mobile and > always stay connected to friends.

------------------------------------------------------------------------

> _______________________________________________ > Serusers mailing list > Serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers -- Klaus Darilion nic.at ________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. ________________________________ _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Greger V. Teigre

2:23 p.m.

My point was that such CANCEL must hit lookup. If not ser has no way of knowing where to route it (as there are no Route headers). Obviously t_relay will lookup the ruri using dns, resolve it to your ser and then you get into a loop. g-) samuel wrote:

...

It may be that you are not handling the CANCEL correctly. An early

CANCEL

(no Route headers) will have to be routed as an INVITE. g-) Abdul Qadir wrote: Hi,

I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.

At present I don't think its working like this, As soon as CANCEL

hit SER

Hi , I tried to call from one nokia sip (E61 and other models )phone to

another nokia sip phone. The call works fine. The problem comes

only when I

call from Phone A to Phone B and then immediately cancel the

call(from Phone

A). The Phone A will hangup the call as it sent CANCEL but the SER

will

ignore this CANCEL and still send INVITE to Phone B resulting in a

ghost

call situation.

Hi! I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies. regards klasu

I tried to capture a log of message and found that Phone A "CANCEL"

message is received on SER even before any provisional response

from Phone

B. Therefor SER doesnot relay this CANCEL request to Phone B. I

even checked

RFC which clearly says that UAC should not send CANCEL untill it

receives

any provisional response. I talked to Nokia expert and they said

the 100

Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct. > > Is there any way I can stop 100 Trying message and still run

statefull

SER, so that I can verify what nokia said. Any ideas suggestions are welcome.

Thanking you all in advance. Best Regards, Abdul Qadir --------------------------------- Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.

------------------------------------------------------------------------

_______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Klaus Darilion nic.at ________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A.

________________________________

_______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Greger V. Teigre

2:24 p.m.

I'm not sure, but it may be that at some point a to/from/call-id matching with INVITE was implemented, thus removing the necessity of using lookup on CANCEL. g-) samuel wrote:

...

It may be that you are not handling the CANCEL correctly. An early

CANCEL

(no Route headers) will have to be routed as an INVITE. g-) Abdul Qadir wrote: Hi,

I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.

At present I don't think its working like this, As soon as CANCEL

hit SER

Hi , I tried to call from one nokia sip (E61 and other models )phone to

another nokia sip phone. The call works fine. The problem comes

only when I

call from Phone A to Phone B and then immediately cancel the

call(from Phone

A). The Phone A will hangup the call as it sent CANCEL but the SER

will

ignore this CANCEL and still send INVITE to Phone B resulting in a

ghost

call situation.

Hi! I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies. regards klasu

I tried to capture a log of message and found that Phone A "CANCEL"

message is received on SER even before any provisional response

from Phone

B. Therefor SER doesnot relay this CANCEL request to Phone B. I

even checked

RFC which clearly says that UAC should not send CANCEL untill it

receives

any provisional response. I talked to Nokia expert and they said

the 100

Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct. > > Is there any way I can stop 100 Trying message and still run

statefull

SER, so that I can verify what nokia said. Any ideas suggestions are welcome.

Thanking you all in advance. Best Regards, Abdul Qadir --------------------------------- Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.

------------------------------------------------------------------------

_______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Klaus Darilion nic.at ________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A.

________________________________

Jiri Kuthan

2:37 p.m.

I think that's yet another issue (which then reinstatiates itself in some other issue) -- you must have a loop in your script which you have to fix first. Just ngrep loopback interface to verify this is the cause of the problem. -jiri At 13:34 16/02/2007, Abdul Qadir wrote:

...

Hi,

I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.

Hi! I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies. regards klasu

-- Klaus Darilion nic.at <http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367>Food fight? Enjoy some healthy debate in the <http://answers.yahoo.com/dir/index;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx?link=ask&sid=396545367>Yahoo! Answers Food & Drink Q&A. _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Jiri Kuthan http://iptel.org/~jiri/

Abdul Qadir

5:14 p.m.

Hi, Yes it was a loop back going on thats why i got too many hops. Based on the suggestion I put some thing like this for CANCEL method before relaying my original configuration is exactly like this. http://www.voip-info.org/wiki/view/SER+example+NAThelper if(method=="CANCEL") { if(!lookup("location")) { log(1, "Location not found\n"); } fix_nated_contact(); force_rport(); }; but it created two problems. 1. The cancel is now sent to B party. ( which sends error that the call transaction does not exist, ofcourse which is rite since we haven't sent any INVITE to B party) 2. SER goes in loop of ACK 3. later b side will get invite as well, and the ghost call still exists. This is how it looks like Caller SER Callee INVITE ---------------------------------> CANCEL ---------------------------------> CANCEL ---------------------------------> 481 (tran does not exist) <--------------------------------- Loopback OF ACK 100 Trying <--------------------------------- INVITE ---------------------------------> rest of call follows............. Best Regards, Abdul Qaidr Jiri Kuthan <jiri(a)iptel.org> wrote: I think that's yet another issue (which then reinstatiates itself in some other issue) -- you must have a loop in your script which you have to fix first. Just ngrep loopback interface to verify this is the cause of the problem. -jiri At 13:34 16/02/2007, Abdul Qadir wrote:

...

Hi,

I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies.

Hi! I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies. regards klasu

-- Klaus Darilion nic.at Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Jiri Kuthan http://iptel.org/~jiri/ --------------------------------- The fish are biting. Get more visitors on your site using Yahoo! Search Marketing.

samuel

5:53 p.m.

everyday I learn something!!!! :D I has assumed CANCEL was "magically" processed by tm module. i'll lookup() CANCEL requests... Thank you, samuel. 2007/2/16, Greger V. Teigre <greger(a)teigre.com>om>:

...

It may be that you are not handling the CANCEL correctly. An early

CANCEL

(no Route headers) will have to be routed as an INVITE. g-) Abdul Qadir wrote: Hi, >I think ser should remember canceled transactions and send CANCEL in >case of delayed provisional replies. At present I don't think its working like this, As soon as CANCEL

hit SER

an immediate too many hops is returned to sender and call continues....resulting in ghost call, where A party has dropped after sending cancel and B still carries on as no cancel was sent to B. Best Regards, Abdul Qadir Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote: Abdul Qadir wrote: > Hi , > > I tried to call from one nokia sip (E61 and other models )phone to another nokia sip phone. The call works fine. The problem comes

only when I

call from Phone A to Phone B and then immediately cancel the

call(from Phone

A). The Phone A will hangup the call as it sent CANCEL but the SER

will

ignore this CANCEL and still send INVITE to Phone B resulting in a

ghost

call situation. > Hi! I think ser should remember canceled transactions and send CANCEL in case of delayed provisional replies. regards klasu > I tried to capture a log of message and found that Phone A "CANCEL" message is received on SER even before any provisional response

from Phone

B. Therefor SER doesnot relay this CANCEL request to Phone B. I

even checked

RFC which clearly says that UAC should not send CANCEL untill it

receives

any provisional response. I talked to Nokia expert and they said

the 100

Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct. > > Is there any way I can stop 100 Trying message and still run

statefull

SER, so that I can verify what nokia said. Any ideas suggestions are welcome. > > Thanking you all in advance. > > Best Regards, > Abdul Qadir > > > --------------------------------- > Don't be flakey. Get Yahoo! Mail for Mobile and > always stay connected to friends. > > >

------------------------------------------------------------------------

> > _______________________________________________ > Serusers mailing list > Serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers -- Klaus Darilion nic.at ________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A.

________________________________

samuel

6:21 p.m.

confirmed: after lookingup() CANCELs no more spirals around!!!! no "race condition", no "failure"... simply my mistake, apologies :P waiting for delayed CANCELs.... Samuel. 2007/2/16, samuel <samu60(a)gmail.com>om>:

...

mmm i'll take a look at the config... maybe i just had a wrong config after all...if that's the case, apologies for the false "race condition" :P samuel. 2007/2/16, Greger V. Teigre <greger(a)teigre.com>om>: > > It may be that you are not handling the CANCEL correctly. An early CANCEL > (no Route headers) will have to be routed as an INVITE. > g-) > > Abdul Qadir wrote: > Hi, > > >I think ser should remember canceled transactions and send CANCEL in > >case of delayed provisional replies. > > At present I don't think its working like this, As soon as CANCEL hit SER > an immediate too many hops is returned to sender and call > continues....resulting in ghost call, where A party has dropped after > sending cancel and B still carries on as no cancel was sent to B. > > Best Regards, > Abdul Qadir > > Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote: > Abdul Qadir wrote: > > Hi , > > > > I tried to call from one nokia sip (E61 and other models )phone to > another nokia sip phone. The call works fine. The problem comes only when I > call from Phone A to Phone B and then immediately cancel the call(from Phone > A). The Phone A will hangup the call as it sent CANCEL but the SER will > ignore this CANCEL and still send INVITE to Phone B resulting in a ghost > call situation. > > > > Hi! > > I think ser should remember canceled transactions and send CANCEL in > case of delayed provisional replies. > > regards > klasu > > > I tried to capture a log of message and found that Phone A "CANCEL" > message is received on SER even before any provisional response from Phone > B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked > RFC which clearly says that UAC should not send CANCEL untill it receives > any provisional response. I talked to Nokia expert and they said the 100 > Trying message from your server is considered as provisional response, > therefor behaviour of client is absolutely correct. > > > > Is there any way I can stop 100 Trying message and still run statefull > SER, so that I can verify what nokia said. Any ideas suggestions are > welcome. > > > > Thanking you all in advance. > > > > Best Regards, > > Abdul Qadir > > > > > > --------------------------------- > > Don't be flakey. Get Yahoo! Mail for Mobile and > > always stay connected to friends. > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Serusers mailing list > > Serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > > > -- > Klaus Darilion > nic.at > > > > > ________________________________ > Food fight? Enjoy some healthy debate > in the Yahoo! Answers Food & Drink Q&A. ________________________________ > > _______________________________________________ > Serusers mailing list > Serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > > > _______________________________________________ > Serusers mailing list > Serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > >

Greger V. Teigre

26 Feb 26 Feb

11:23 a.m.

New subject: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

I forward this from the serusers list: A CANCEL is being sent from a UAC before having established a route set, thus the CANCEL has no Route header and is not caught by loose routing. The below thread shows that this case is difficult to understand. Jiri and Bogdan had a discussion on serusers regarding the race condition where the provisional reply from UAS and the CANCEL cross each other. Q1: This situation can be handled in 0.9.x by sending CANCEL through handling the CANCEL as an INVITE. Has this changed in SER 2.0? Q2: At what point will t_reply be able to match the CANCEL against the state in tm? I assume only when the provisional reply has been received from UAS. Q3: Jiri and Bogdans' discussion seems to conclude that the proxy should not do anything, but is the responsibility of the UAC. This seems strange to me as a missing CANCEL (that in fact could have been routed correctly) is likely to result in an OK, then a BYE, and (as the thread below suggest) is often not handled properly by UACs. So: What is the best way to practically handle this? (i.e. sysop's perspective) Q4: From a user's perspective, sending all CANCELs to t_relay() would be very appealing. It is natural to assume that tm could match the dialog and appropriate routing. Is this possible for 2.0? If not, is this feasible? g-) samuel wrote:

...

My point was that such CANCEL must hit lookup. If not ser has no

way of

knowing where to route it (as there are no Route headers). Obviously t_relay will lookup the ruri using dns, resolve it to

your ser

and then you get into a loop. g-) samuel wrote: > i'm pretty sure CANCEL hits t_relay and should be matched agains > INVITE transaction...the only main routing difference between CANCEL > and INVITE is NAT stuff and lookupXXXX which I think it does not > affect this thread's topic, or did i miss something?? > > Try to dial a number and immediately hang up...don't you see the Too > Many Hops? > > Samuel. > > 2007/2/16, samuel <samu60(a)gmail.com>om>: >> mmm >> >> i'll take a look at the config... >> >> maybe i just had a wrong config after all...if that's the case, >> apologies for the false "race condition" :P >> samuel. >> >> 2007/2/16, Greger V. Teigre <greger(a)teigre.com>om>: >> > >> > It may be that you are not handling the CANCEL correctly. An

early

>> CANCEL >> > (no Route headers) will have to be routed as an INVITE. >> > g-) >> > >> > Abdul Qadir wrote: >> > Hi, >> > >> > >I think ser should remember canceled transactions and send

CANCEL in

>> > >case of delayed provisional replies. >> > >> > At present I don't think its working like this, As soon as

CANCEL

>> hit SER >> > an immediate too many hops is returned to sender and call >> > continues....resulting in ghost call, where A party has

dropped after

>> > sending cancel and B still carries on as no cancel was sent to B. >> > >> > Best Regards, >> > Abdul Qadir >> > >> > Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote: >> > Abdul Qadir wrote: >> > > Hi , >> > > >> > > I tried to call from one nokia sip (E61 and other models

)phone to

>> > another nokia sip phone. The call works fine. The problem comes >> only when I >> > call from Phone A to Phone B and then immediately cancel the >> call(from Phone >> > A). The Phone A will hangup the call as it sent CANCEL but the

SER

>> will >> > ignore this CANCEL and still send INVITE to Phone B resulting

in a

>> ghost >> > call situation. >> > > >> > >> > Hi! >> > >> > I think ser should remember canceled transactions and send

CANCEL in

>> > case of delayed provisional replies. >> > >> > regards >> > klasu >> > >> > > I tried to capture a log of message and found that Phone A

"CANCEL"

>> > message is received on SER even before any provisional response >> from Phone >> > B. Therefor SER doesnot relay this CANCEL request to Phone B. I >> even checked >> > RFC which clearly says that UAC should not send CANCEL untill it >> receives >> > any provisional response. I talked to Nokia expert and they said >> the 100 >> > Trying message from your server is considered as provisional

response,

>> > therefor behaviour of client is absolutely correct. >> > > >> > > Is there any way I can stop 100 Trying message and still run >> statefull >> > SER, so that I can verify what nokia said. Any ideas

suggestions are

>> > welcome. >> > > >> > > Thanking you all in advance. >> > > >> > > Best Regards, >> > > Abdul Qadir >> > > >> > > >> > > --------------------------------- >> > > Don't be flakey. Get Yahoo! Mail for Mobile and >> > > always stay connected to friends. >> > > >> > > >> > > >> > >>

------------------------------------------------------------------------

> > > > > > _______________________________________________ > > > Serusers mailing list > > > Serusers(a)lists.iptel.org > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > -- > > Klaus Darilion > > nic.at > > > > > > > > > > ________________________________ > > Food fight? Enjoy some healthy debate > > in the Yahoo! Answers Food & Drink Q&A. > ________________________________ > > > > _______________________________________________ > > Serusers mailing list > > Serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > _______________________________________________ > > Serusers mailing list > > Serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > > > > >

Martin Hoffmann

12:09 p.m.

New subject: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

Greger V. Teigre wrote:

...

I seem to have missed this discussion, but shouldn't the race be between the final reply and the CANCEL? In SER, there is a race between the INVITE and the CANCEL: If the INVITE processing hasn't been finished and the transaction for it has not yet been established through t_relay() before the CANCEL arrives, things go wonky.

...

Q1: This situation can be handled in 0.9.x by sending CANCEL through handling the CANCEL as an INVITE. Has this changed in SER 2.0?

If you already have a transaction for the INVITE, you should be fine by simply passing the CANCEL to tm by calling t_relay(). Don't remember what tm does with a CANCEL it doesn't have a transaction for. IMHO it should do nothing and give an error back.

...

Q2: At what point will t_reply be able to match the CANCEL against the state in tm? I assume only when the provisional reply has been received from UAS.

The state is there the moment a transaction is established. The problem here is that SER doesn't CANCEL branches that have not yet received a 100 Trying since The Standard doesn't allow you to.

...

As usual: Ignore. It's a borderline case, anyways. Most likely, it will fix itself anyways because the person that receives the false call will hang up and thus their UA will generate a BYE.

...

Q4: From a user's perspective, sending all CANCELs to t_relay() would be very appealing. It is natural to assume that tm could match the dialog and appropriate routing. Is this possible for 2.0? If not, is this feasible?

This depends on what tm is doing with a CANCEL it can't find a transaction for. If I understand the code right, it currently treats such a CANCEL as if it were nothing special. This would actually be in violation of 3261 which states that you MUST forward the CANCEL statelessly. However, the reasoning is that this is because the proxy may have forwarded the INVITE statelessly earlier. Since I never do that, I would happily violate that MUST. Regards, Martin

Klaus Darilion

2:58 p.m.

New subject: [Serdev] Re: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

FYI: This is the pragmatic approach how openser users handle the problem: 1. drop the CANCEL if there is no corresponding INVITE transaction. The UAC must retransmit the CANCEL and meanwhile there should be the INVITE transaction. (since 1.0) if ( is_method("CANCEL") && !t_check_trans() ) { # CANCEL without matching INVITE transaction, ignore! # May happen if the INVITE is slower than the CANCEL. # Ignore the CANCEL, as the client will retransmit it, and maybe # the INVITE transaction is already created for the next CANCEL xlog("L_WARN","$ci CANCEL without matching transaction ... ignore\n"); exit; } 2. delayed CANCEL. If openser hasn't forward a CANCEL because of missing provisional response, it remembers this branch and sends a CANCEL of there is a delayed provisional response from the caller (at least in CVS=1.2) regards klaus Martin Hoffmann wrote:

...

Greger V. Teigre wrote:

Q1: This situation can be handled in 0.9.x by sending CANCEL through handling the CANCEL as an INVITE. Has this changed in SER 2.0?

Q2: At what point will t_reply be able to match the CANCEL against the state in tm? I assume only when the provisional reply has been received from UAS.

The state is there the moment a transaction is established. The problem here is that SER doesn't CANCEL branches that have not yet received a 100 Trying since The Standard doesn't allow you to.

As usual: Ignore. It's a borderline case, anyways. Most likely, it will fix itself anyways because the person that receives the false call will hang up and thus their UA will generate a BYE.

-- Klaus Darilion nic.at

Bogdan Pintea

5:04 p.m.

New subject: [Serdev] Re: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

Hi, Klaus Darilion wrote:

...

FYI: This is the pragmatic approach how openser users handle the problem: 1. drop the CANCEL if there is no corresponding INVITE transaction.

Why not politely return an error?

...

The UAC must retransmit the CANCEL and meanwhile there should be the INVITE transaction. (since 1.0)

Wouldn't it be easier to only provisionally reply after the transaction is already created (="visible" also from the other processes)?

...

if ( is_method("CANCEL") && !t_check_trans() ) { # CANCEL without matching INVITE transaction, ignore! # May happen if the INVITE is slower than the CANCEL. # Ignore the CANCEL, as the client will retransmit it, and maybe # the INVITE transaction is already created for the next CANCEL xlog("L_WARN","$ci CANCEL without matching transaction ... ignore\n"); exit; }

I guess the protocol might have to be checked, as well (at least to reply with an error, rather than drop): for reliable transports you won't see any retransmission and it seems that a client is allowed to open a second connection for the CANCEL[*]; given the fact that INVITEs usually go through multiple checks, the probability of a CANCEL being run against the "transaction table" before the INVITE might not be that low, after all (especially on loaded servers). [*]: " If a request is destined to an IP address, port, and transport to which an existing connection is open, it is RECOMMENDED that this connection be used to send the request, but another connection MAY be opened and used." (RFC3261)

...

2. delayed CANCEL. If openser hasn't forward a CANCEL because of missing provisional response, it remembers this branch and sends a CANCEL of there is a delayed provisional response from the caller (at least in CVS=1.2)

Yes, there is a pending feature request for this issue, which will probably make to next release. Cheers, Bogdan.

...

regards klaus Martin Hoffmann wrote:

Greger V. Teigre wrote:

Q1: This situation can be handled in 0.9.x by sending CANCEL through handling the CANCEL as an INVITE. Has this changed in SER 2.0?

Q2: At what point will t_reply be able to match the CANCEL against the state in tm? I assume only when the provisional reply has been received from UAS.

The state is there the moment a transaction is established. The problem here is that SER doesn't CANCEL branches that have not yet received a 100 Trying since The Standard doesn't allow you to.

As usual: Ignore. It's a borderline case, anyways. Most likely, it will fix itself anyways because the person that receives the false call will hang up and thus their UA will generate a BYE.

-- Bogdan Pintea iptego GmbH - VoIP Security http://www.iptego.de

Martin Hoffmann

5:45 p.m.

New subject: [Serdev] Re: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

Bogdan Pintea wrote:

...

Klaus Darilion wrote:

FYI: This is the pragmatic approach how openser users handle the problem: 1. drop the CANCEL if there is no corresponding INVITE transaction.

Why not politely return an error?

The assumption is that there is a race and that there will be a transaction soon and all is fine with the re-transmit.

...

The UAC must retransmit the CANCEL and meanwhile there should be the INVITE transaction. (since 1.0)

Wouldn't it be easier to only provisionally reply after the transaction is already created (="visible" also from the other processes)?

When does the "100 Trying" happen in SER. You are, of course, right that this fixes the race (and explains why the rule not to cancel transactions without provisional responses exists in the first place). Which makes it all the more apparent that t_relay() should never relay a CANCEL. Ever. It should return with an error and I then can decide whether I have a stateless proxy or not to statelessly forward the CANCEL or just error it away. Regards, Martin

Andrei Pelinescu-Onciul

27 Feb 27 Feb

10:53 p.m.

New subject: [Serdev] Re: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

On Feb 26, 2007 at 12:09, Martin Hoffmann <hn(a)nvnc.de> wrote:

...

Greger V. Teigre wrote:

It's mostly fixed in Ottendorf. There is still some race potential if the CANCEL arrives after t_relay() started but before the message being forwarded (e.g. during branch adding inside t_relay()).

...

Q1: This situation can be handled in 0.9.x by sending CANCEL through handling the CANCEL as an INVITE. Has this changed in SER 2.0?

It forwards it statefully.

...

Q2: At what point will t_reply be able to match the CANCEL against the state in tm? I assume only when the provisional reply has been received from UAS.

The state is there the moment a transaction is established. The problem here is that SER doesn't CANCEL branches that have not yet received a 100 Trying since The Standard doesn't allow you to.

As usual: Ignore. It's a borderline case, anyways. Most likely, it will fix itself anyways because the person that receives the false call will hang up and thus their UA will generate a BYE.

Andrei

Andrei Pelinescu-Onciul

11:16 p.m.

New subject: [Serdev] Re: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

On Feb 26, 2007 at 17:45, Martin Hoffmann <hn(a)nvnc.de> wrote:

...

Bogdan Pintea wrote:

Klaus Darilion wrote:

FYI: This is the pragmatic approach how openser users handle the problem: 1. drop the CANCEL if there is no corresponding INVITE transaction.

Why not politely return an error?

The assumption is that there is a race and that there will be a transaction soon and all is fine with the re-transmit.

The UAC must retransmit the CANCEL and meanwhile there should be the INVITE transaction. (since 1.0)

Wouldn't it be easier to only provisionally reply after the transaction is already created (="visible" also from the other processes)?

I think it should relay the CANCEL and if an INVITE comes and the CANCEL transaction is still alive, it should reply w/ 487 (Ottendorf does this). Andrei

Bogdan Pintea

11:33 p.m.

New subject: [Serdev] Re: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

Andrei Pelinescu-Onciul wrote:

...

On Feb 26, 2007 at 17:45, Martin Hoffmann <hn(a)nvnc.de> wrote:

Which makes it all the more apparent that t_relay() should never relay a CANCEL. Ever. It should return with an error and I then can decide whether I have a stateless proxy or not to statelessly forward the CANCEL or just error it away.

I think it should relay the CANCEL and if an INVITE comes and the CANCEL transaction is still alive, it should reply w/ 487 (Ottendorf does this).

But isn't there a potential for DOS? Since CANCELs can only be accepted (no auth*), sending CANCELs to nowhere (from anonymous.invalid :) ) seems the easiest solution to eat fast the shm. Bogdan.

...

Andrei

-- Bogdan Pintea iptego GmbH - VoIP Security http://www.iptego.de

Jan Janak

28 Feb 28 Feb

11:42 a.m.

New subject: [Serdev] Re: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

Martin Hoffmann wrote:

...

SER/tm forwards the CANCEL statefuly if the corresponding INVITE transaction does not exist in tm. The reason for this measure (as far as I can remember) was improved robustness in the rare cases when no matching INVITE transaction could be found (such as after SER restarts or transaction timeouts). The idea here was that in such cases SER should try to execute exactly the same routing logic for the CANCEL as it did for the INVITE, to increase the chance that the CANCEL would reach the correct final destination. SER can be configured (and is by default) to drop long-lasting INVITE transaction _silently_, i.e. without terminating it explicitly (see the noisy_ctimer parameter of tm module). If this happened and SER did not forward the CANCEL (although the corresponding INVITE transaction did not exist anymore) then you could end up having a phone ringing indefinitely (or until the first hammer hit by your roommate, it is unbelievable but there are people that can't stand phones ringing for hours). This is also the reason, by the way, why most SER configuration files do not contain just if (method=="INVITE") but: if (method=="INVITE" || method=="CANCEL"). This is to ensure that CANCELs will go down the same path in the configuration files as INVITEs and that they hit the same destination as the INVITE did. This, of course, does not work when parallel or sequential forking takes place, or when you have a very complex configuration file in place. This is my recap what is SER doing with CANCELs that have no matching INVITE transaction in tm and why. I am not sure whether this logic is still relevant today, given the complexity of most configuration files and frequent use of forking. Jan.

Jan Janak

11:53 a.m.

New subject: [Serdev] Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

Greger V. Teigre wrote:

...

No.

...

Q2: At what point will t_reply be able to match the CANCEL against the state in tm? I assume only when the provisional reply has been received from UAS.

TM will be able to match the CANCEL agains the state created by INVITE even if no provisional reply has been received from downstream. It's just that it will not forward it down the branch.

...

Q3: Jiri and Bogdans' discussion seems to conclude that the proxy should not do anything, but is the responsibility of the UAC. This seems strange to me as a missing CANCEL (that in fact could have been routed correctly) is likely to result in an OK, then a BYE, and (as the thread below suggest) is often not handled properly by UACs. So: What is the best way to practically handle this? (i.e. sysop's perspective) Q4: From a user's perspective, sending all CANCELs to t_relay() would be very appealing. It is natural to assume that tm could match the dialog and appropriate routing. Is this possible for 2.0? If not, is this feasible?

Yes, it would be possible, you could have a catch-all-CANCELs code at the very beginning of your configuration file, but it won't cover the cases when no INVITE transaction exist. In such a case t_relay will relay the CANCEL which would enter a forwarding loop because the Request-URI does not change. Jan.

Andrei Pelinescu-Onciul

6:59 p.m.

New subject: [Serdev] Re: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

On Feb 27, 2007 at 23:33, Bogdan Pintea <pintea(a)iptego.de> wrote:

...

Andrei Pelinescu-Onciul wrote:

On Feb 26, 2007 at 17:45, Martin Hoffmann <hn(a)nvnc.de> wrote:

I think it should relay the CANCEL and if an INVITE comes and the CANCEL transaction is still alive, it should reply w/ 487 (Ottendorf does this).

But isn't there a potential for DOS? Since CANCELs can only be accepted (no auth*), sending CANCELs to nowhere (from anonymous.invalid :) ) seems the easiest solution to eat fast the shm.

Good point. I guess the choice is between a potential CANCEL DOS and more reliability in sending CANCELs. You could workaround the potential CANCEL DOS using ratelimit, pike or something similar. The big problems that statefull CANCELs solve are: - it's not so uncommon to have an INVITE quickly followed by a CANCEL and the INVITE processing delayed due to auth/db lookups/a.s.o. In this case the CANCEL could reach tm before the INVITE. If you would drop or forward the CANCEL statlessly, you won't be able to match it to the INVITE and so you'll have an INVITE after CANCEL (and the phone will ring). If you forward the CANCEL statefully in the worst case you'll get an error reply from the destination (no transaction), but when tm gets to the INVITE it can see that's already canceled and stop its processing (if the delay is no longer then wt_timer - 5 s by default). - if you missed the INVITE (e.g. restart, failover to another server, INVITE silently terminated) it's important to forward the CANCEL exactly in the same way as the INVITE. If we would forward it statelessly you won't have any failure routes for it so it won't be forwarded in the same way as an INVITE that (for example) could be forwarded on timeout to some other host (in the failure route). Same goes for dns (e.g. foo resolves to several ips and the first ips returns 503 => the INVITE will be forwarded to the next one, but if you forward the CANCEL statelessly it will go only to the first ip). OTOH if it makes everybody happy I will make CANCEL handling a tm option (with the current behaviour as default) so that everyone can choose between: forward statefully (and solve also the CANCEL arrived in tm before the INVITE), forward statelessly (RFC) or drop (for Martin :-)). Andrei

Klaus Darilion

12 Mar 12 Mar

11:49 a.m.

New subject: [Serdev] Re: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

Bogdan Pintea wrote:

...

Hi, Klaus Darilion wrote:

FYI: This is the pragmatic approach how openser users handle the problem: 1. drop the CANCEL if there is no corresponding INVITE transaction.

Why not politely return an error?

Because an error reply does not trigger a retransmission.

...

The UAC must retransmit the CANCEL and meanwhile there should be the INVITE transaction. (since 1.0)

Wouldn't it be easier to only provisionally reply after the transaction is already created (="visible" also from the other processes)?

In case of openser we need a retransmission, thus the CANCEL is dropped. Probably with Ottendorf, which "remembers" the CANCEL, it should work.

...

You are right - dropping the CANCEL which was received over a reliable transport is a bad idea - regardless if the same connection is used or the request comes in via a new connection. Thus my workaround only works with UDP. regards klaus -- Klaus Darilion nic.at

Jiri Kuthan

29 Mar 29 Mar

8:14 p.m.

New subject: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

At 13:09 26/02/2007, Martin Hoffmann wrote:

...

IMO, it used to create a kind of special (or crippled) transaction to allow CANCEL forwarding after a SER reboot. Not really 100% sure what it does now. (For potential TM redesigners: this is why it pays off to produce branch parameters in a way which can be derived from the original request --> then even rebooted SER generates branches consistently) -jiri -- Jiri Kuthan http://iptel.org/~jiri/

Jiri Kuthan

8:19 p.m.

New subject: [Serdev] Re: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

At 15:58 26/02/2007, Klaus Darilion wrote:

...

Jiri Kuthan

8:31 p.m.

New subject: [Serdev] Re: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

At 18:45 26/02/2007, Martin Hoffmann wrote:

...

Wouldn't it be easier to only provisionally reply after the transaction is already created (="visible" also from the other processes)?

It is a kind of trad-off. You could do it immediatelly after receipt of a message. Downside: if SER reboots a nanosecond after that, UAC is led in belief everything is okay and stops retransmitting and elicit the striven-for action. The other extreme way is sending after SER processing is finished, which may take such a while, that UAC unnecesssarily retransmits. Personally, none of these two alternatives seems dramatically worse to me than the other.

...

not sure if dropping it is too nice -- particularly because of SER reboots which may lead tis way to for-ever ringing UASs. I would say rather not. For the forwarding case, I'm kind of twisted on if it is okay to do it statelessly. I would say it is roughly okay. (forking for example should be stateful to avoid UAC confused by an unexpected variaty of asnswers, but I think it is not sooo bad .. UACs have to deal with multiple OKs for INVITEs anyhow, and who cares about answers for CANCELs.....) -jiri

Nuno Ribeiro

6 Mar 6 Mar

6:45 p.m.

New subject: [Serusers] [Serdev] Re: Handling of early CANCELs - was Re: SER Nokia CANCEL Problem

Hi all, I'm facing a problem with "early CANCEL's" such the one described in this thread. The scenario is the following one: A PSTN call to a SIP phone. When the PSTN decides to cancel the call only a right after initiating, the PSTN will send the CANCEL message to the SER but this is discarded and not forwarded to the correct path to the SIP Phone. So what happens is that we have a ghost call.... The PSTN has already canceled the call but the SIP phone continues to ring. The code that I have in the SER script is really simple and the behavior to a CANCEL is the same as to a INVITE: if(subst_uri('/^sip:(\+[0-9]+)@ 192.168.20.69.*user=phone$/sip:\1@xlab.com/i')){ record_route(); loose_route(); t_relay_to_udp("192.168.20.5", "5060"); break; } In the log file I see that: RFC3261 transaction matching failed t_lookup_request: no transaction found e2e_cancel: e2e cancel proceeding During this thread I saw that a CANCEL handling tm option was decided to be created. Maybe this option can help me to solve the ghost call issue. How can I change the default behavior ? this feature is available from which SER release ? Any idea how I can solve this isse? Thanks in advance. Best Regards On Thu, Mar 29, 2007 at 6:19 PM, Jiri Kuthan <jiri(a)iptel.org> wrote:

...

At 15:58 26/02/2007, Klaus Darilion wrote:

FYI: This is the pragmatic approach how openser users handle the problem: 1. drop the CANCEL if there is no corresponding INVITE transaction. The

UAC must retransmit the CANCEL and meanwhile there should be the INVITE transaction. (since 1.0)

which does not appear really reboot-safe to me. What it can lead to that ser reboot affects pending calls in that cancels are never forwarded and ringing phones will never stop ringing -- not very pleasant indeed, is it. -jiri -- Jiri Kuthan http://iptel.org/~jiri/ <http://iptel.org/%7Ejiri/> _______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Nuno Ribeiro

Andrei Pelinescu-Onciul

8 Mar 8 Mar

1:39 a.m.

New subject: [Serusers] [Serdev] Re: Handling of early CANCELs - was Re: SER Nokia CANCEL Problem

On Mar 06, 2008 at 17:45, Nuno Ribeiro <nribeiro82(a)gmail.com> wrote:

...

The option is unmatched_cancel and is present for ser 2.1 (cvs head). However what this does is select between dropping unmatched cancels, forwarding them statelessly or statefully. Older ser versions always forward the cancel statefully, which is what you want in most cases (including yours). It's strage that the cancel doesn't seem to match the invite transaction in your case. If you would send me some networks dumps with the invite and the cancel I could tell you more. Andrei

...

Any idea how I can solve this isse? Thanks in advance. Best Regards On Thu, Mar 29, 2007 at 6:19 PM, Jiri Kuthan <jiri(a)iptel.org> wrote:

At 15:58 26/02/2007, Klaus Darilion wrote:

FYI: This is the pragmatic approach how openser users handle the problem: 1. drop the CANCEL if there is no corresponding INVITE transaction. The

UAC must retransmit the CANCEL and meanwhile there should be the INVITE transaction. (since 1.0)

-- Nuno Ribeiro

Nuno Ribeiro

10 Mar 10 Mar

1:14 p.m.

New subject: [Serusers] [Serdev] Re: Handling of early CANCELs - was Re: SER Nokia CANCEL Problem

Hi Andrei, Thanks for your availability to help me... Note that this situation only occurs if the CANCEL message is originated a few moments after the INVITE. I think that the transaction from the INVITE is not yet completely created so when the CANCEL is received it doesn't match any transaction (t_lookup_request: no transaction found). I send in attachment the wireshark log where you can the network traces that you referred. PS: the first message was rejected by the list as the message was to big.... Best Regards, On Sat, Mar 8, 2008 at 12:39 AM, Andrei Pelinescu-Onciul <andrei(a)iptel.org> wrote:

...

On Mar 06, 2008 at 17:45, Nuno Ribeiro <nribeiro82(a)gmail.com> wrote:

Hi all, I'm facing a problem with "early CANCEL's" such the one described in

this

thread. The scenario is the following one: A PSTN call to a SIP phone. When the PSTN decides to cancel the call

only a

right after initiating, the PSTN will send the CANCEL message to the SER

but

this is discarded and not forwarded to the correct path to the SIP

Phone. So

what happens is that we have a ghost call.... The PSTN has already

canceled

the call but the SIP phone continues to ring. The code that I have in the SER script is really simple and the behavior

a CANCEL is the same as to a INVITE: if(subst_uri('/^sip:(\+[0-9]+)@ 192.168.20.69.*user=phone$/sip:\1@xlab.com/i')){<http://192.168.20.69.*user=phone$/sip:%5C1@xlab.com/i%27%29%29%7B> record_route(); loose_route(); t_relay_to_udp("192.168.20.5", "5060"); break; } In the log file I see that: RFC3261 transaction matching failed t_lookup_request: no transaction found e2e_cancel: e2e cancel proceeding During this thread I saw that a CANCEL handling tm option was decided

to be

created. Maybe this option can help me to solve the ghost call issue.

How

can I change the default behavior ? this feature is available from

which

SER release ?

Any idea how I can solve this isse? Thanks in advance. Best Regards On Thu, Mar 29, 2007 at 6:19 PM, Jiri Kuthan <jiri(a)iptel.org> wrote: > At 15:58 26/02/2007, Klaus Darilion wrote: > >FYI: This is the pragmatic approach how openser users handle the

problem:

> > > >1. drop the CANCEL if there is no corresponding INVITE transaction.

The

> UAC must retransmit the CANCEL and meanwhile there should be the

INVITE

> transaction. (since 1.0) > > > >if ( is_method("CANCEL") && !t_check_trans() ) { > > # CANCEL without matching INVITE transaction, ignore! > > # May happen if the INVITE is slower than the CANCEL. > > # Ignore the CANCEL, as the client will retransmit it, and maybe > > # the INVITE transaction is already created for the next CANCEL > > xlog("L_WARN","$ci CANCEL without matching transaction ...

ignore\n");

> > exit; > >} > > which does not appear really reboot-safe to me. What it can lead to

that

> ser reboot > affects pending calls in that cancels are never forwarded and ringing > phones will > never stop ringing -- not very pleasant indeed, is it. > > -jiri > > > > -- > Jiri Kuthan http://iptel.org/~jiri/<http://iptel.org/%7Ejiri/><

http://iptel.org/%7Ejiri/>

_______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Nuno Ribeiro

Andrei Pelinescu-Onciul

5:14 p.m.

New subject: [Serusers] [Serdev] Re: Handling of early CANCELs - was Re: SER Nokia CANCEL Problem

On Mar 10, 2008 at 12:14, Nuno Ribeiro <nribeiro82(a)gmail.com> wrote:

...

No, in fact the CANCEL matches and terminates the transaction (you go INVITE, 100 Trying, INVITE forwarded, CANCEL, 487 to the orig. INVITE due to the CANCEL and the 200 to the CANCEL). The problem is when the CANCEL arrives the INVITE transaction has not received any reply yet (if you look in the dump you'll see an 100 trying from .5 long after the CANCEL is received). In ser in this case (CANCEL received and no response yet on a branch) the branch is dropped immediately and a "fake" 487 is sent back (the ideea is that most likely the UA to which the INVITE was forwarded is dead and it saves a lot of resources if we quickly kill the transaction -- unfortunately this backfires in your case). The CANCEL is also not forwarded downstream (the rfc says that CANCEL should be sent only on replied branches). So to make a long story short, upgrade to the latest cvs version and set modparam("tm", "cancel_b_method", 1). This will keep retransmitting the INVITE if no reply was received, even after the CANCEL arrives and it will avoid all the above problems (see modules/tm/README |grep cancel_b_method for a more detailed description). If you still have problem, drop me another mail. I'm very interested if the cancel fix works properly, not only in my testbed. I'm starting to think that making this the default behaviour might be a good ideea (since it seems that it causes problems quite frequently). It might even become a candidate for a backport to stable. Andrei

...

PS: the first message was rejected by the list as the message was to big.... Best Regards, On Sat, Mar 8, 2008 at 12:39 AM, Andrei Pelinescu-Onciul <andrei(a)iptel.org> wrote:

On Mar 06, 2008 at 17:45, Nuno Ribeiro <nribeiro82(a)gmail.com> wrote:

Hi all, I'm facing a problem with "early CANCEL's" such the one described in

this

thread. The scenario is the following one: A PSTN call to a SIP phone. When the PSTN decides to cancel the call

only a

right after initiating, the PSTN will send the CANCEL message to the SER

but

this is discarded and not forwarded to the correct path to the SIP

Phone. So

what happens is that we have a ghost call.... The PSTN has already

canceled

the call but the SIP phone continues to ring. The code that I have in the SER script is really simple and the behavior

to be

created. Maybe this option can help me to solve the ghost call issue.

How

can I change the default behavior ? this feature is available from

which

SER release ?

problem:

> > > >1. drop the CANCEL if there is no corresponding INVITE transaction.

The

> UAC must retransmit the CANCEL and meanwhile there should be the

INVITE

ignore\n");

> > exit; > >} > > which does not appear really reboot-safe to me. What it can lead to

that

http://iptel.org/%7Ejiri/>

_______________________________________________ Serusers mailing list Serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Nuno Ribeiro

Nuno Ribeiro

12 Mar 12 Mar

10:48 a.m.

New subject: [Serusers] [Serdev] Re: Handling of early CANCELs - was Re: SER Nokia CANCEL Problem

I will follow your indications and after that I will give you feedback about this solution. Thanks, On Mon, Mar 10, 2008 at 4:14 PM, Andrei Pelinescu-Onciul <andrei(a)iptel.org> wrote:

...

On Mar 10, 2008 at 12:14, Nuno Ribeiro <nribeiro82(a)gmail.com> wrote:

Hi Andrei, Thanks for your availability to help me... Note that this situation only occurs if the CANCEL message is originated

few moments after the INVITE. I think that the transaction from the

INVITE

is not yet completely created so when the CANCEL is received it doesn't match any transaction (t_lookup_request: no transaction found). I send in attachment the wireshark log where you can the network traces

that

you referred.

PS: the first message was rejected by the list as the message was to

big....

Best Regards, On Sat, Mar 8, 2008 at 12:39 AM, Andrei Pelinescu-Onciul <

andrei(a)iptel.org>

wrote: > On Mar 06, 2008 at 17:45, Nuno Ribeiro <nribeiro82(a)gmail.com> wrote: > > Hi all, > > > > I'm facing a problem with "early CANCEL's" such the one described

> this > > thread. The scenario is the following one: > > > > A PSTN call to a SIP phone. When the PSTN decides to cancel the call > only a > > right after initiating, the PSTN will send the CANCEL message to the

SER

> but > > this is discarded and not forwarded to the correct path to the SIP > Phone. So > > what happens is that we have a ghost call.... The PSTN has already > canceled > > the call but the SIP phone continues to ring. > > > > The code that I have in the SER script is really simple and the

behavior

> to > > a CANCEL is the same as to a INVITE: > > > > if(subst_uri('/^sip:(\+[0-9]+)@ > > 192.168.20.69.*user=phone$/sip:\1@xlab.com/i')){<http://192.168.20.69.*user=phone$/sip:%5C1@xlab.com/i%27%29%29%7B>

<http://192.168.20.69.*user=phone$/sip:%5C1@xlab.com/i%27%29%29%7B>

> > record_route(); > > loose_route(); > > t_relay_to_udp("192.168.20.5", "5060"); > > break; > > } > > In the log file I see that: > > RFC3261 transaction matching failed > > t_lookup_request: no transaction found > > e2e_cancel: e2e cancel proceeding > > > > > > During this thread I saw that a CANCEL handling tm option was

decided

> to be > > created. Maybe this option can help me to solve the ghost call

issue.

> How > > can I change the default behavior ? this feature is available from > which > > SER release ? > > The option is unmatched_cancel and is present for ser 2.1 (cvs head). > However what this does is select between dropping unmatched cancels, > forwarding them statelessly or statefully. > Older ser versions always forward the cancel statefully, which is what > you want in most cases (including yours). > > It's strage that the cancel doesn't seem to match the invite

transaction

> in your case. > If you would send me some networks dumps with the invite and the

cancel

> I could tell you more. > > > Andrei > > > > > > Any idea how I can solve this isse? > > > > Thanks in advance. > > > > Best Regards > > > > On Thu, Mar 29, 2007 at 6:19 PM, Jiri Kuthan <jiri(a)iptel.org> wrote: > > > > > At 15:58 26/02/2007, Klaus Darilion wrote: > > > >FYI: This is the pragmatic approach how openser users handle the > problem: > > > > > > > >1. drop the CANCEL if there is no corresponding INVITE

transaction.

> The > > > UAC must retransmit the CANCEL and meanwhile there should be the > INVITE > > > transaction. (since 1.0) > > > > > > > >if ( is_method("CANCEL") && !t_check_trans() ) { > > > > # CANCEL without matching INVITE transaction, ignore! > > > > # May happen if the INVITE is slower than the CANCEL. > > > > # Ignore the CANCEL, as the client will retransmit it, and

maybe

> > > > # the INVITE transaction is already created for the next CANCEL > > > > xlog("L_WARN","$ci CANCEL without matching transaction ... > ignore\n"); > > > > exit; > > > >} > > > > > > which does not appear really reboot-safe to me. What it can lead

> that > > > ser reboot > > > affects pending calls in that cancels are never forwarded and

ringing

> > > phones will > > > never stop ringing -- not very pleasant indeed, is it. > > > > > > -jiri > > > > > > > > > > > > -- > > > Jiri Kuthan http://iptel.org/~jiri/<http://iptel.org/%7Ejiri/>

<http://iptel.org/%7Ejiri/><

http://iptel.org/%7Ejiri/>

> > _______________________________________________ > Serusers mailing list > Serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > -- Nuno Ribeiro

-- Nuno Ribeiro

Nuno Ribeiro

7 May 7 May

4:59 p.m.

New subject: [Serusers] [Serdev] Re: Handling of early CANCELs - was Re: SER Nokia CANCEL Problem

Hi Andrei and all, Sorry by the late answer. I had other tasks in my hands that were more important than this one. I have made the migration of the code that you added in that version to my own testbed and it solved the issue. I think that this solution would be great if you put on the stable version as it solves an issue that In my opinion is view is very important : ghost calls. Best Regards, Nuno Ribeiro On Mon, Mar 10, 2008 at 5:14 PM, Andrei Pelinescu-Onciul <andrei(a)iptel.org> wrote:

...

On Mar 10, 2008 at 12:14, Nuno Ribeiro <nribeiro82(a)gmail.com> wrote:

Hi Andrei, Thanks for your availability to help me... Note that this situation only occurs if the CANCEL message is originated

few moments after the INVITE. I think that the transaction from the

INVITE

that

you referred.

PS: the first message was rejected by the list as the message was to

big....

Best Regards, On Sat, Mar 8, 2008 at 12:39 AM, Andrei Pelinescu-Onciul <

andrei(a)iptel.org>

wrote: > On Mar 06, 2008 at 17:45, Nuno Ribeiro <nribeiro82(a)gmail.com> wrote: > > Hi all, > > > > I'm facing a problem with "early CANCEL's" such the one described

SER

behavior

> to > > a CANCEL is the same as to a INVITE: > > > > if(subst_uri('/^sip:(\+[0-9]+)@ > > 192.168.20.69.*user=phone$/sip:\1@xlab.com/i')){<http://1@xlab.com/i%27%29%29%7B>

<http://192.168.20.69.*user=phone$/sip:%5C1@xlab.com/i%27%29%29%7B>

decided

> to be > > created. Maybe this option can help me to solve the ghost call

issue.

transaction

> in your case. > If you would send me some networks dumps with the invite and the

cancel

transaction.

maybe

> that > > > ser reboot > > > affects pending calls in that cancels are never forwarded and

ringing

> > > phones will > > > never stop ringing -- not very pleasant indeed, is it. > > > > > > -jiri > > > > > > > > > > > > -- > > > Jiri Kuthan http://iptel.org/~jiri/<http://iptel.org/%7Ejiri/>

<http://iptel.org/%7Ejiri/><

http://iptel.org/%7Ejiri/>

> > _______________________________________________ > Serusers mailing list > Serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > -- Nuno Ribeiro

-- Nuno Ribeiro

5831

days inactive

6278

days old

sr-users@lists.kamailio.org

Manage subscription

36 comments

10 participants

tags (0)

participants (10)

Abdul Qadir
Andrei Pelinescu-Onciul
Bogdan Pintea
Greger V. Teigre
Jan Janak
Jiri Kuthan
Klaus Darilion
Martin Hoffmann
Nuno Ribeiro
samuel