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
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:
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:
On 06/17/2010 04:46 PM, David wrote:
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.
On Jun 17, 2010 at 16:39, David kamailio.org@spam.lublink.net wrote:
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#ca...
Andrei
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:
2010/6/17 Andrei Pelinescu-Onciul andrei@iptel.org:
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?
On Jun 24, 2010 at 12:06, Iñaki Baz Castillo ibc@aliax.net wrote:
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
On Jul 06, 2010 at 14:06, Klaus Darilion klaus.mailinglists@pernau.at wrote:
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
On Jul 06, 2010 at 16:55, Klaus Darilion klaus.mailinglists@pernau.at wrote:
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
-
Alex Balashov -
Andrei Pelinescu-Onciul -
David -
David -
Iñaki Baz Castillo -
Klaus Darilion