17 Jun
2010
17 Jun
'10
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