15 Feb
2007
15 Feb
'07
6: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.
16 Feb
16 Feb
11: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
noon
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.
2: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>:
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.
2:02 p.m.
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
2: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 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.
2: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,
Hi!
I think ser should remember canceled transactions and send CANCEL in
case of delayed provisional replies.
regards
klasu
> 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
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.
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.
2: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,
Hi!
I think ser should remember canceled transactions and send CANCEL in
case of delayed provisional replies.
regards
klasu
> 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
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.
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.
2:55 p.m.
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,
Hi!
I think ser should remember canceled transactions and send CANCEL in
case of delayed provisional replies.
regards
klasu
> 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
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.
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.
3: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>:
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,
Hi!
I think ser should remember canceled transactions and send CANCEL in
case of delayed provisional replies.
regards
klasu
> 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
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.
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.
3: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:
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,
hit SER
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 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:
only when I
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 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
from Phone
I tried to capture a log of message and found
that Phone A "CANCEL"
message is received on SER even before any
provisional response 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
6: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>:
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
7: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>:
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>:
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
>
>
26 Feb
26 Feb
12:23 p.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:
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>:
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>:
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
> >
> >
>
1:09 p.m.
New subject: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem
Greger V. Teigre wrote:
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.
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.
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)
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
3: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:
--
Klaus Darilion
nic.at
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.
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.
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)
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
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev 
6: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:
--
Bogdan Pintea
iptego GmbH - VoIP Security
http://www.iptego.de
Greger V. Teigre wrote:
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.
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.
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)
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
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
6:45 p.m.
New subject: [Serdev] Re: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem
Bogdan Pintea wrote:
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
Klaus Darilion wrote:
The assumption is that there is a race and that there will be a
transaction soon and all is fine with the re-transmit.
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)? 
28 Feb
28 Feb
12:16 a.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:
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.
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
Klaus Darilion wrote:
The assumption is that there is a race and that there will be a
transaction soon and all is fine with the re-transmit.
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)?
12:33 a.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:
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.
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).
Andrei
--
Bogdan Pintea
iptego GmbH - VoIP Security
http://www.iptego.de
7: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:
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
On Feb 26, 2007 at 17:45, Martin Hoffmann
<hn(a)nvnc.de> wrote:
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. 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).
29 Mar
29 Mar
9: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:
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.
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.
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
12 Mar
12 Mar
12:49 p.m.
New subject: [Serdev] Re: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem
Bogdan Pintea wrote:
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
Hi,
Klaus Darilion wrote:
Because an error reply does not trigger a retransmission.
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).
29 Mar
29 Mar
9: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:
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/
6 Mar
6 Mar
7: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:
--
Nuno Ribeiro
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/>
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
8 Mar
8 Mar
2: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:
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 ?
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:
--
Nuno Ribeiro 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/>
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
10 Mar
10 Mar
2: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:
--
Nuno Ribeiro
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')){<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 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
6: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:
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.
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:
--
Nuno Ribeiro 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')){<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 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
12 Mar
12 Mar
11: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:
--
Nuno Ribeiro
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.
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
> > 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
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/><
http://iptel.org/%7Ejiri/>
--
Nuno Ribeiro >
> _______________________________________________
> Serusers mailing list
> Serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
--
Nuno Ribeiro
7 May
7 May
5: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:
--
Nuno Ribeiro
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.
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
> > 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>
> > 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
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/><
http://iptel.org/%7Ejiri/>
--
Nuno Ribeiro >
> _______________________________________________
> Serusers mailing list
> Serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
--
Nuno Ribeiro
27 Feb
27 Feb
11: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:
It forwards it statefully.
Andrei
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()).
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.
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.
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)
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 
28 Feb
28 Feb
12:42 p.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.
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.
29 Mar
29 Mar
9: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:
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.
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/
28 Feb
28 Feb
12:53 p.m.
New subject: [Serdev] Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem
Greger V. Teigre wrote:
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?
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.
16 Feb
16 Feb
3: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:
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,
hit SER
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 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:
only when I
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 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
from Phone
I tried to capture a log of message and found
that Phone A "CANCEL"
message is received on SER even before any
provisional response 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
3: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,
--
Jiri Kuthan http://iptel.org/~jiri/
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
<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
6: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,
--
Jiri Kuthan http://iptel.org/~jiri/
---------------------------------
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
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 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
6043
days inactive
6490
days old
36 comments
10 participants
participants (10)
-
Abdul Qadir -
Andrei Pelinescu-Onciul -
Bogdan Pintea -
Greger V. Teigre -
Jan Janak -
Jiri Kuthan -
Klaus Darilion -
Martin Hoffmann -
Nuno Ribeiro -
samuel