17 Jun
2010
17 Jun
'10
10:49 p.m.
Hey,
I am using a Cisco WIP310 wifi phone. Seeing as wifi is very battery
demanding, the phone goes into a standby mode. When it's in the standby
mode, it takes a few seconds to come back on.
So I send an INVITE to the phone, statefully using TM, I send out a
CANCEL before the phone returns the "180 ringing" message.
Somehow the device is answering the CANCEL before the INVITE, so the
result is that it responds to the CANCEL with "481 Call Leg/Transaction
Does Not Exist.", after that it responds to the INVITE with a "180
Ringing", the phone than rings indefinitely because the CANCEL is not
sent out again as the transaction is completed from the 481 SIP message.
I had a look at the CANCEL, there is no Route: header or tag on the To,
so it looks like it is part of a new dialog ( I believe that's what
rfc3261 says.
As far as I can tell, my Kamailio is working properly. It is
retransmitting the messages at the proper intervals, and it is passing
along the messages as it receives them.
The trouble is that the device answers the initial CANCEL before it
answers any of the retransmitted INVITEs.
Is there something that I can do in Kamailio to resolve this issue ? Is
there an option that I can set that will cause Kamailio to relay the
CANCEL only to devices that have already returned a 100 Trying or 180
Trying ?
What information do you need to know about my config? What parts of the
SIP trace do you need ?
Thanks,
David
17 Jun
17 Jun
11:39 p.m.
Hello,
I had a look at RFC 3261, section 9.1. The trouble is that Kamailio is
answering "100 Trying" to the caller, so the it is ok for the caller to
send back a CANCEL request. Trouble is Kamailio forwards the request to
the called user even though the called user never sent a provisional
response.
Since the Kamailio server never received a provisional request, it is
therefore incorrect for it to forward the CANCEL request to the called
user. ( correct me if I am wrong ).
I added this code :
if ( is_method("INVITE") )
{
t_newtran();
}
The problem is gone. Is this the correct solution ?
David
On 2010-06-17 15:49, David wrote:
Hey,
I am using a Cisco WIP310 wifi phone. Seeing as wifi is very battery
demanding, the phone goes into a standby mode. When it's in the
standby mode, it takes a few seconds to come back on.
So I send an INVITE to the phone, statefully using TM, I send out a
CANCEL before the phone returns the "180 ringing" message.
Somehow the device is answering the CANCEL before the INVITE, so the
result is that it responds to the CANCEL with "481 Call
Leg/Transaction Does Not Exist.", after that it responds to the INVITE
with a "180 Ringing", the phone than rings indefinitely because the
CANCEL is not sent out again as the transaction is completed from the
481 SIP message.
I had a look at the CANCEL, there is no Route: header or tag on the
To, so it looks like it is part of a new dialog ( I believe that's
what rfc3261 says.
As far as I can tell, my Kamailio is working properly. It is
retransmitting the messages at the proper intervals, and it is passing
along the messages as it receives them.
The trouble is that the device answers the initial CANCEL before it
answers any of the retransmitted INVITEs.
Is there something that I can do in Kamailio to resolve this issue ?
Is there an option that I can set that will cause Kamailio to relay
the CANCEL only to devices that have already returned a 100 Trying or
180 Trying ?
What information do you need to know about my config? What parts of
the SIP trace do you need ?
Thanks,
David
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
11:43 p.m.
David,
You can suppress forwarding 100 Trying to the caller with the 0x01
flag to t_relay(). The problem is that then the caller will never
receive 100 Trying, as it is a "hop-by-hop" message; in other words,
when received from the callee, the proxy will not forward it.
Instead, the expectation is that every network element in the call
path originates its own.
A transaction is not established by the receipt of a provisional
message. It is created when the INVITE is received. As a result, it
is acceptable for Kamailio to forward the CANCEL request as long as it
has received the INVITE beforehand, even if it never got a proximate
response.
Why is it a problem for Kamailio to forward the CANCEL? It will just
not be responded to, and the transaction will time out eventually. No
harm.
On 06/17/2010 04:39 PM, David wrote:
Hello,
I had a look at RFC 3261, section 9.1. The trouble is that Kamailio is
answering "100 Trying" to the caller, so the it is ok for the caller to
send back a CANCEL request. Trouble is Kamailio forwards the request to
the called user even though the called user never sent a provisional
response.
Since the Kamailio server never received a provisional request, it is
therefore incorrect for it to forward the CANCEL request to the called
user. ( correct me if I am wrong ).
I added this code :
if ( is_method("INVITE") )
{
t_newtran();
}
The problem is gone. Is this the correct solution ?
David
On 2010-06-17 15:49, David wrote:
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
Hey,
I am using a Cisco WIP310 wifi phone. Seeing as wifi is very battery
demanding, the phone goes into a standby mode. When it's in the
standby mode, it takes a few seconds to come back on.
So I send an INVITE to the phone, statefully using TM, I send out a
CANCEL before the phone returns the "180 ringing" message.
Somehow the device is answering the CANCEL before the INVITE, so the
result is that it responds to the CANCEL with "481 Call
Leg/Transaction Does Not Exist.", after that it responds to the INVITE
with a "180 Ringing", the phone than rings indefinitely because the
CANCEL is not sent out again as the transaction is completed from the
481 SIP message.
I had a look at the CANCEL, there is no Route: header or tag on the
To, so it looks like it is part of a new dialog ( I believe that's
what rfc3261 says.
As far as I can tell, my Kamailio is working properly. It is
retransmitting the messages at the proper intervals, and it is passing
along the messages as it receives them.
The trouble is that the device answers the initial CANCEL before it
answers any of the retransmitted INVITEs.
Is there something that I can do in Kamailio to resolve this issue ?
Is there an option that I can set that will cause Kamailio to relay
the CANCEL only to devices that have already returned a 100 Trying or
180 Trying ?
What information do you need to know about my config? What parts of
the SIP trace do you need ?
Thanks,
David
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
11:46 p.m.
Hey,
With my Cisco WIP310, what is happening is it is replying 481 Call
Leg/transaction unknown. After that it processes the INVITE
retransmission at which point it rings for 240 seconds. Which is a wee
bit annoying.
David
On 2010-06-17 16:43, Alex Balashov wrote:
David,
You can suppress forwarding 100 Trying to the caller with the 0x01
flag to t_relay(). The problem is that then the caller will never
receive 100 Trying, as it is a "hop-by-hop" message; in other words,
when received from the callee, the proxy will not forward it. Instead,
the expectation is that every network element in the call path
originates its own.
A transaction is not established by the receipt of a provisional
message. It is created when the INVITE is received. As a result, it
is acceptable for Kamailio to forward the CANCEL request as long as it
has received the INVITE beforehand, even if it never got a proximate
response.
Why is it a problem for Kamailio to forward the CANCEL? It will just
not be responded to, and the transaction will time out eventually. No
harm.
On 06/17/2010 04:39 PM, David wrote:
Hello,
I had a look at RFC 3261, section 9.1. The trouble is that Kamailio is
answering "100 Trying" to the caller, so the it is ok for the caller to
send back a CANCEL request. Trouble is Kamailio forwards the request to
the called user even though the called user never sent a provisional
response.
Since the Kamailio server never received a provisional request, it is
therefore incorrect for it to forward the CANCEL request to the called
user. ( correct me if I am wrong ).
I added this code :
if ( is_method("INVITE") )
{
t_newtran();
}
The problem is gone. Is this the correct solution ?
David
On 2010-06-17 15:49, David wrote:
Hey,
I am using a Cisco WIP310 wifi phone. Seeing as wifi is very battery
demanding, the phone goes into a standby mode. When it's in the
standby mode, it takes a few seconds to come back on.
So I send an INVITE to the phone, statefully using TM, I send out a
CANCEL before the phone returns the "180 ringing" message.
Somehow the device is answering the CANCEL before the INVITE, so the
result is that it responds to the CANCEL with "481 Call
Leg/Transaction Does Not Exist.", after that it responds to the INVITE
with a "180 Ringing", the phone than rings indefinitely because the
CANCEL is not sent out again as the transaction is completed from the
481 SIP message.
I had a look at the CANCEL, there is no Route: header or tag on the
To, so it looks like it is part of a new dialog ( I believe that's
what rfc3261 says.
As far as I can tell, my Kamailio is working properly. It is
retransmitting the messages at the proper intervals, and it is passing
along the messages as it receives them.
The trouble is that the device answers the initial CANCEL before it
answers any of the retransmitted INVITEs.
Is there something that I can do in Kamailio to resolve this issue ?
Is there an option that I can set that will cause Kamailio to relay
the CANCEL only to devices that have already returned a 100 Trying or
180 Trying ?
What information do you need to know about my config? What parts of
the SIP trace do you need ?
Thanks,
David
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
11:47 p.m.
On 06/17/2010 04:46 PM, David wrote:
With my Cisco WIP310, what is happening is it is
replying 481 Call
Leg/transaction unknown. After that it processes the INVITE
retransmission at which point it rings for 240 seconds. Which is a wee
bit annoying.
This is a very strange flow. If the caller sent a CANCEL, it should
not be sending any INVITE retransmissions. If the proxy received a
CANCEL, it should not be sending any INVITE retransmissions.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
11:59 p.m.
On Jun 17, 2010 at 16:39, David <kamailio.org(a)spam.lublink.net> wrote:
Hello,
I had a look at RFC 3261, section 9.1. The trouble is that Kamailio
is answering "100 Trying" to the caller, so the it is ok for the
caller to send back a CANCEL request. Trouble is Kamailio forwards
the request to the called user even though the called user never
sent a provisional response.
Since the Kamailio server never received a provisional request, it
is therefore incorrect for it to forward the CANCEL request to the
called user. ( correct me if I am wrong ).
Try 3.0 (kamailio or sip-router). You can control how unreplied branches
are canceled, see
http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#c…
Andrei
23 Jun
23 Jun
9:50 p.m.
Hello,
Still using Kamailio 1.5.4.
What behaviour should the tm module be doing? Is it doing the RFC
behaviour where the CANCEL is only sent after a provisional reply is
received or is it doing some other non standard action ?
David
On 2010-06-17 16:59, Andrei Pelinescu-Onciul wrote:
On Jun 17, 2010 at 16:39,
David<kamailio.org(a)spam.lublink.net> wrote:
Hello,
I had a look at RFC 3261, section 9.1. The trouble is that Kamailio
is answering "100 Trying" to the caller, so the it is ok for the
caller to send back a CANCEL request. Trouble is Kamailio forwards
the request to the called user even though the called user never
sent a provisional response.
Since the Kamailio server never received a provisional request, it
is therefore incorrect for it to forward the CANCEL request to the
called user. ( correct me if I am wrong ).
Try 3.0 (kamailio or sip-router). You can control how unreplied branches
are canceled, see
http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#c…
Andrei
24 Jun
24 Jun
1:06 p.m.
2010/6/17 Andrei Pelinescu-Onciul <andrei(a)iptel.org>rg>:
Try 3.0 (kamailio or sip-router). You can control how
unreplied branches
are canceled, see
http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#c…
A question about case 2:
-----------
2 will send and retransmit CANCEL even on unreplied branches, stopping
the request retransmissions. This has the same advantages as 1 and
also avoids the extra roundtrip in the case of the provisional reply,
but it's not RFC 3261 conforming (the RFC allows sending CANCELs only
on pending branches).
------------
What about if the UAS replies a 200 before the CANCEL arrives to it?
Would TM route the 200 upstream to the UAC? or would TM absorb it?
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
1:17 p.m.
On Jun 24, 2010 at 12:06, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
2010/6/17 Andrei Pelinescu-Onciul
<andrei(a)iptel.org>rg>:
It will route it to the UAC (tm does not reply anything to the orig. INV
when it gets the CANCEL, it still waits for some reply, hopefiully a
487, or timeout).
There is the INV-CANCEL reordered race risk, but it's not so bad. If
CANCEL arrives first => discarded and INV replied with 200 OK and 200 OK
gets back to the UAC (nothing bad should happen unless the UAC is
broken).
Andrei
Try 3.0 (kamailio or sip-router). You can control
how unreplied branches
are canceled, see
http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#c…
A question about case 2:
-----------
2 will send and retransmit CANCEL even on unreplied branches, stopping
the request retransmissions. This has the same advantages as 1 and
also avoids the extra roundtrip in the case of the provisional reply,
but it's not RFC 3261 conforming (the RFC allows sending CANCELs only
on pending branches).
------------
What about if the UAS replies a 200 before the CANCEL arrives to it?
Would TM route the 200 upstream to the UAC? or would TM absorb it? 
3:06 p.m.
Obiously the device is buggy.
But there is also on strange thing at Kamailio: it retransmits the
CANCEL although it has already received 481 response on the CANCEL request.
regards
klaus
Am 06.07.2010 00:06, schrieb David:
Hello,
Here are the corrected attachments, I sent the email from Window's
wordpad which set it to RTF by default.
Here are proper txt logs.
David
On 2010-07-05 17:47, David wrote:
Hello,
I upgraded to Kamailio 3.0 and the CANCEL is being sent after it
receives a 100 Trying, as mentioned in RFC3261 section 9.
I stripped down the config file to the bare minimum so that it is
easier to debug ( see attached kamailio.cfg )
I have included my config file as well as a packet sniff that was done
with ngrep.
As you can see, the packets are in the correct order, but the Linksys
is crying "Call leg Transaction does not exist" despite the fact that
the CANCEL has ( as far as I can tell ) responded according to
RFC3261. I compared the headers that are required by RFC ( The
Request-URI, Call-ID, To, the numeric part of CSeq, and From header
fields in the CANCEL request MUST be identical to those in the request
being cancelled, including tags. ) but it still says Call Leg
Transaction does not exist. ( see ngrep-sip-wip-310.log ).
If I send the CANCEL once the device is ringing, it works fine ( see
sip-trace-good.log ).
If I send the CANCEL after the 100 Trying but before the 180 Ringing (
which is acceptable according to RFC3261 ), the device returns call
leg incorrect.
This looks suspiciously like a bug in the WIP310, but I am not sure.
Can someone please shed some light on my situation?
Thanks,
David
On 2010-06-17 16:59, Andrei Pelinescu-Onciul wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users On Jun 17, 2010 at 16:39,
David<kamailio.org(a)spam.lublink.net> wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello,
I had a look at RFC 3261, section 9.1. The trouble is that Kamailio
is answering "100 Trying" to the caller, so the it is ok for the
caller to send back a CANCEL request. Trouble is Kamailio forwards
the request to the called user even though the called user never
sent a provisional response.
Since the Kamailio server never received a provisional request, it
is therefore incorrect for it to forward the CANCEL request to the
called user. ( correct me if I am wrong ).
Try 3.0 (kamailio or sip-router). You can control how unreplied branches
are canceled, see
http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#c…
Andrei
5:36 p.m.
On Jul 06, 2010 at 14:06, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Obiously the device is buggy.
But there is also on strange thing at Kamailio: it retransmits the
CANCEL although it has already received 481 response on the CANCEL
request.
The first 481 stops the CANCEL retransmissions, however each additional
provisional reply received after that will trigger a one-time CANCEL
retransmission. That's why you see another retransmission after the 481,
it's the "response" to the 180...
Andrei
regards
klaus
Am 06.07.2010 00:06, schrieb David:
Hello,
Here are the corrected attachments, I sent the email from Window's
wordpad which set it to RTF by default.
Here are proper txt logs.
David
On 2010-07-05 17:47, David wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users Hello,
I upgraded to Kamailio 3.0 and the CANCEL is being sent after it
receives a 100 Trying, as mentioned in RFC3261 section 9.
I stripped down the config file to the bare minimum so that it is
easier to debug ( see attached kamailio.cfg )
I have included my config file as well as a packet sniff that was done
with ngrep.
As you can see, the packets are in the correct order, but the Linksys
is crying "Call leg Transaction does not exist" despite the fact that
the CANCEL has ( as far as I can tell ) responded according to
RFC3261. I compared the headers that are required by RFC ( The
Request-URI, Call-ID, To, the numeric part of CSeq, and From header
fields in the CANCEL request MUST be identical to those in the request
being cancelled, including tags. ) but it still says Call Leg
Transaction does not exist. ( see ngrep-sip-wip-310.log ).
If I send the CANCEL once the device is ringing, it works fine ( see
sip-trace-good.log ).
If I send the CANCEL after the 100 Trying but before the 180 Ringing (
which is acceptable according to RFC3261 ), the device returns call
leg incorrect.
This looks suspiciously like a bug in the WIP310, but I am not sure.
Can someone please shed some light on my situation?
Thanks,
David
On 2010-06-17 16:59, Andrei Pelinescu-Onciul wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users On Jun 17, 2010 at 16:39,
David<kamailio.org(a)spam.lublink.net> wrote:
>Hello,
>
>I had a look at RFC 3261, section 9.1. The trouble is that Kamailio
>is answering "100 Trying" to the caller, so the it is ok for the
>caller to send back a CANCEL request. Trouble is Kamailio forwards
>the request to the called user even though the called user never
>sent a provisional response.
>
>Since the Kamailio server never received a provisional request, it
>is therefore incorrect for it to forward the CANCEL request to the
>called user. ( correct me if I am wrong ).
>
Try 3.0 (kamailio or sip-router). You can control how unreplied branches
are canceled, see
http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#c…
Andrei
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
5:55 p.m.
Am 06.07.2010 16:36, schrieb Andrei Pelinescu-Onciul:
On Jul 06, 2010 at 14:06, Klaus
Darilion<klaus.mailinglists(a)pernau.at> wrote:
Cool, nice feature.
Unfortunately it doesn't help with David's problem, as the phone
obviously does not see the additional CANCEL - probably the phone's
transaction layer responds again with 481.
regards
Klaus
Obiously the device is buggy.
But there is also on strange thing at Kamailio: it retransmits the
CANCEL although it has already received 481 response on the CANCEL
request.
The first 481 stops the CANCEL retransmissions, however each additional
provisional reply received after that will trigger a one-time CANCEL
retransmission. That's why you see another retransmission after the 481,
it's the "response" to the 180...
Andrei
>
> regards
> klaus
>
> Am 06.07.2010 00:06, schrieb David:
>> Hello,
>>
>> Here are the corrected attachments, I sent the email from Window's
>> wordpad which set it to RTF by default.
>>
>> Here are proper txt logs.
>>
>> David
>>
>> On 2010-07-05 17:47, David wrote:
>>> Hello,
>>>
>>> I upgraded to Kamailio 3.0 and the CANCEL is being sent after it
>>> receives a 100 Trying, as mentioned in RFC3261 section 9.
>>>
>>> I stripped down the config file to the bare minimum so that it is
>>> easier to debug ( see attached kamailio.cfg )
>>>
>>> I have included my config file as well as a packet sniff that was done
>>> with ngrep.
>>>
>>> As you can see, the packets are in the correct order, but the Linksys
>>> is crying "Call leg Transaction does not exist" despite the fact
that
>>> the CANCEL has ( as far as I can tell ) responded according to
>>> RFC3261. I compared the headers that are required by RFC ( The
>>> Request-URI, Call-ID, To, the numeric part of CSeq, and From header
>>> fields in the CANCEL request MUST be identical to those in the request
>>> being cancelled, including tags. ) but it still says Call Leg
>>> Transaction does not exist. ( see ngrep-sip-wip-310.log ).
>>>
>>> If I send the CANCEL once the device is ringing, it works fine ( see
>>> sip-trace-good.log ).
>>>
>>> If I send the CANCEL after the 100 Trying but before the 180 Ringing (
>>> which is acceptable according to RFC3261 ), the device returns call
>>> leg incorrect.
>>>
>>> This looks suspiciously like a bug in the WIP310, but I am not sure.
>>>
>>> Can someone please shed some light on my situation?
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> On 2010-06-17 16:59, Andrei Pelinescu-Onciul wrote:
>>>> On Jun 17, 2010 at 16:39, David<kamailio.org(a)spam.lublink.net>
wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I had a look at RFC 3261, section 9.1. The trouble is that Kamailio
>>>>> is answering "100 Trying" to the caller, so the it is ok
for the
>>>>> caller to send back a CANCEL request. Trouble is Kamailio forwards
>>>>> the request to the called user even though the called user never
>>>>> sent a provisional response.
>>>>>
>>>>> Since the Kamailio server never received a provisional request, it
>>>>> is therefore incorrect for it to forward the CANCEL request to the
>>>>> called user. ( correct me if I am wrong ).
>>>>>
>>>> Try 3.0 (kamailio or sip-router). You can control how unreplied branches
>>>> are canceled, see
>>>>
http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#c…
>>>>
>>>>
>>>> Andrei
>>>>
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users(a)lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users(a)lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
6:04 p.m.
On Jul 06, 2010 at 16:55, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Am 06.07.2010 16:36, schrieb Andrei Pelinescu-Onciul:
What's strange is that according to the dump it does finally reply with
a 487, but 8s after it sent a 481 to the last CANCEL:
<- 100
CANCEL ->
<- 481
<- 180
CANCEL
<-481
[8s]
<-487
Andrei
On Jul 06, 2010 at 14:06, Klaus
Darilion<klaus.mailinglists(a)pernau.at> wrote:
Cool, nice feature.
Unfortunately it doesn't help with David's problem, as the phone
obviously does not see the additional CANCEL - probably the phone's
transaction layer responds again with 481. Obiously the device is buggy.
But there is also on strange thing at Kamailio: it retransmits the
CANCEL although it has already received 481 response on the CANCEL
request.
The first 481 stops the CANCEL retransmissions, however each additional
provisional reply received after that will trigger a one-time CANCEL
retransmission. That's why you see another retransmission after the 481,
it's the "response" to the 180...
regards
Klaus
Andrei
>
>regards
>klaus
>
>Am 06.07.2010 00:06, schrieb David:
>>Hello,
>>
>>Here are the corrected attachments, I sent the email from Window's
>>wordpad which set it to RTF by default.
>>
>>Here are proper txt logs.
>>
>>David
>>
>>On 2010-07-05 17:47, David wrote:
>>>Hello,
>>>
>>>I upgraded to Kamailio 3.0 and the CANCEL is being sent after it
>>>receives a 100 Trying, as mentioned in RFC3261 section 9.
>>>
>>>I stripped down the config file to the bare minimum so that it is
>>>easier to debug ( see attached kamailio.cfg )
>>>
>>>I have included my config file as well as a packet sniff that was done
>>>with ngrep.
>>>
>>>As you can see, the packets are in the correct order, but the Linksys
>>>is crying "Call leg Transaction does not exist" despite the fact
that
>>>the CANCEL has ( as far as I can tell ) responded according to
>>>RFC3261. I compared the headers that are required by RFC ( The
>>>Request-URI, Call-ID, To, the numeric part of CSeq, and From header
>>>fields in the CANCEL request MUST be identical to those in the request
>>>being cancelled, including tags. ) but it still says Call Leg
>>>Transaction does not exist. ( see ngrep-sip-wip-310.log ).
>>>
>>>If I send the CANCEL once the device is ringing, it works fine ( see
>>>sip-trace-good.log ).
>>>
>>>If I send the CANCEL after the 100 Trying but before the 180 Ringing (
>>>which is acceptable according to RFC3261 ), the device returns call
>>>leg incorrect.
>>>
>>>This looks suspiciously like a bug in the WIP310, but I am not sure.
>>>
>>>Can someone please shed some light on my situation?
>>>
>>>Thanks,
>>>
>>>David
>>>
>>>On 2010-06-17 16:59, Andrei Pelinescu-Onciul wrote:
>>>>On Jun 17, 2010 at 16:39, David<kamailio.org(a)spam.lublink.net>
wrote:
>>>>
>>>>>Hello,
>>>>>
>>>>>I had a look at RFC 3261, section 9.1. The trouble is that Kamailio
>>>>>is answering "100 Trying" to the caller, so the it is ok for
the
>>>>>caller to send back a CANCEL request. Trouble is Kamailio forwards
>>>>>the request to the called user even though the called user never
>>>>>sent a provisional response.
>>>>>
>>>>>Since the Kamailio server never received a provisional request, it
>>>>>is therefore incorrect for it to forward the CANCEL request to the
>>>>>called user. ( correct me if I am wrong ).
>>>>>
>>>>Try 3.0 (kamailio or sip-router). You can control how unreplied branches
>>>>are canceled, see
>>>>http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#cancel_b_method
>>>>
>>>>
>>>>Andrei
>>>>
>>>
>>>
>>>_______________________________________________
>>>SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>sr-users(a)lists.sip-router.org
>>>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>
>>
>>
>>
>>_______________________________________________
>>SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>sr-users(a)lists.sip-router.org
>>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>_______________________________________________
>SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>sr-users(a)lists.sip-router.org
>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
6:39 p.m.
Am 06.07.2010 17:04, schrieb Andrei Pelinescu-Onciul:
On Jul 06, 2010 at 16:55, Klaus
Darilion<klaus.mailinglists(a)pernau.at> wrote:
True. David, is the 47 sent by the phone autonomously or due to some
user interaction (e.g. rejecting the call)
regards
klaus
Am 06.07.2010 16:36, schrieb Andrei Pelinescu-Onciul:
What's strange is that according to the dump it does finally reply with
a 487, but 8s after it sent a 481 to the last CANCEL:
<- 100
CANCEL ->
<- 481
<- 180
CANCEL
<-481
[8s]
<-487 On Jul 06, 2010 at 14:06, Klaus
Darilion<klaus.mailinglists(a)pernau.at> wrote:
Cool, nice feature.
Unfortunately it doesn't help with David's problem, as the phone
obviously does not see the additional CANCEL - probably the phone's
transaction layer responds again with 481. Obiously the device is buggy.
But there is also on strange thing at Kamailio: it retransmits the
CANCEL although it has already received 481 response on the CANCEL
request.
The first 481 stops the CANCEL retransmissions, however each additional
provisional reply received after that will trigger a one-time CANCEL
retransmission. That's why you see another retransmission after the 481,
it's the "response" to the 180... 
7:46 p.m.
Hey,
It's sent when I hit the red button on the phone ( hang up ). It's not
automated.
David
On 2010-07-06 11:39, Klaus Darilion wrote:
Am 06.07.2010 17:04, schrieb Andrei Pelinescu-Onciul:
On Jul 06, 2010 at 16:55, Klaus
Darilion<klaus.mailinglists(a)pernau.at> wrote:
True. David, is the 47 sent by the phone autonomously or due to some
user interaction (e.g. rejecting the call)
regards
klaus
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Am 06.07.2010 16:36, schrieb Andrei Pelinescu-Onciul:
What's strange is that according to the dump it does finally reply with
a 487, but 8s after it sent a 481 to the last CANCEL:
<- 100
CANCEL ->
<- 481
<- 180
CANCEL
<-481
[8s]
<-487 On Jul 06, 2010 at 14:06, Klaus
Darilion<klaus.mailinglists(a)pernau.at> wrote:
> Obiously the device is buggy.
>
> But there is also on strange thing at Kamailio: it retransmits the
> CANCEL although it has already received 481 response on the CANCEL
> request.
The first 481 stops the CANCEL retransmissions, however each
additional
provisional reply received after that will trigger a one-time CANCEL
retransmission. That's why you see another retransmission after the
481,
it's the "response" to the 180...
Cool, nice feature.
Unfortunately it doesn't help with David's problem, as the phone
obviously does not see the additional CANCEL - probably the phone's
transaction layer responds again with 481.
7:47 p.m.
Hey,
It's sent when I hit the red button on the phone ( hang up ). It's not
automated.
David
On 2010-07-06 11:39, Klaus Darilion wrote:
Am 06.07.2010 17:04, schrieb Andrei Pelinescu-Onciul:
On Jul 06, 2010 at 16:55, Klaus
Darilion<klaus.mailinglists(a)pernau.at> wrote:
True. David, is the 47 sent by the phone autonomously or due to some
user interaction (e.g. rejecting the call)
regards
klaus
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Am 06.07.2010 16:36, schrieb Andrei Pelinescu-Onciul:
What's strange is that according to the dump it does finally reply with
a 487, but 8s after it sent a 481 to the last CANCEL:
<- 100
CANCEL ->
<- 481
<- 180
CANCEL
<-481
[8s]
<-487 On Jul 06, 2010 at 14:06, Klaus
Darilion<klaus.mailinglists(a)pernau.at> wrote:
> Obiously the device is buggy.
>
> But there is also on strange thing at Kamailio: it retransmits the
> CANCEL although it has already received 481 response on the CANCEL
> request.
The first 481 stops the CANCEL retransmissions, however each
additional
provisional reply received after that will trigger a one-time CANCEL
retransmission. That's why you see another retransmission after the
481,
it's the "response" to the 180...
Cool, nice feature.
Unfortunately it doesn't help with David's problem, as the phone
obviously does not see the additional CANCEL - probably the phone's
transaction layer responds again with 481.
7 Jul
7 Jul
10:14 a.m.
Am 06.07.2010 18:47, schrieb David:
Hey,
It's sent when I hit the red button on the phone ( hang up ). It's not
automated.
So I think there is no solution within Kamailio to work around the bug
in the phone. You would need to modify tm module to send delayed CANCEL
not after 100 trying, but only after 101-199 response.
regards
Klaus
David
On 2010-07-06 11:39, Klaus Darilion wrote:
Am 06.07.2010 17:04, schrieb Andrei Pelinescu-Onciul:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users On Jul 06, 2010 at 16:55, Klaus
Darilion<klaus.mailinglists(a)pernau.at> wrote:
True. David, is the 47 sent by the phone autonomously or due to some
user interaction (e.g. rejecting the call)
regards
klaus
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Am 06.07.2010 16:36, schrieb Andrei Pelinescu-Onciul:
> On Jul 06, 2010 at 14:06, Klaus
> Darilion<klaus.mailinglists(a)pernau.at> wrote:
>> Obiously the device is buggy.
>>
>> But there is also on strange thing at Kamailio: it retransmits the
>> CANCEL although it has already received 481 response on the CANCEL
>> request.
>
> The first 481 stops the CANCEL retransmissions, however each
> additional
> provisional reply received after that will trigger a one-time CANCEL
> retransmission. That's why you see another retransmission after the
> 481,
> it's the "response" to the 180...
Cool, nice feature.
Unfortunately it doesn't help with David's problem, as the phone
obviously does not see the additional CANCEL - probably the phone's
transaction layer responds again with 481.
What's strange is that according to the dump it does finally reply with
a 487, but 8s after it sent a 481 to the last CANCEL:
<- 100
CANCEL ->
<- 481
<- 180
CANCEL
<-481
[8s]
<-487
18 Jun
18 Jun
2:15 p.m.
Just the theory.
The proxy - if stateful forwarding is used, e.g. by using t_relay() -
must not forward the CANCEL unless a provisional reply is received from
the cisco phone.
regards
klaus
Am 17.06.2010 21:49, schrieb David:
Hey,
I am using a Cisco WIP310 wifi phone. Seeing as wifi is very battery
demanding, the phone goes into a standby mode. When it's in the standby
mode, it takes a few seconds to come back on.
So I send an INVITE to the phone, statefully using TM, I send out a
CANCEL before the phone returns the "180 ringing" message.
Somehow the device is answering the CANCEL before the INVITE, so the
result is that it responds to the CANCEL with "481 Call Leg/Transaction
Does Not Exist.", after that it responds to the INVITE with a "180
Ringing", the phone than rings indefinitely because the CANCEL is not
sent out again as the transaction is completed from the 481 SIP message.
I had a look at the CANCEL, there is no Route: header or tag on the To,
so it looks like it is part of a new dialog ( I believe that's what
rfc3261 says.
As far as I can tell, my Kamailio is working properly. It is
retransmitting the messages at the proper intervals, and it is passing
along the messages as it receives them.
The trouble is that the device answers the initial CANCEL before it
answers any of the retransmitted INVITEs.
Is there something that I can do in Kamailio to resolve this issue ? Is
there an option that I can set that will cause Kamailio to relay the
CANCEL only to devices that have already returned a 100 Trying or 180
Trying ?
What information do you need to know about my config? What parts of the
SIP trace do you need ?
Thanks,
David
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
5281
days inactive
5301
days old
19 comments
6 participants
participants (6)
-
Alex Balashov -
Andrei Pelinescu-Onciul -
David -
David -
Iñaki Baz Castillo -
Klaus Darilion