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, bu
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 wrote:
Am 06.07.2010 16:36, schrieb Andrei Pelinescu-O
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 wrote:
Am 06.07.2010 16:36, schrieb Andrei Pelinescu-O
Am 06.07.2010 17:04, schrieb Andrei Pelinescu-Onciul:
On Jul 06, 2010 at 16:55, Klaus Darilion wrote:
Am 06.07.2010 16:36, schrieb Andrei Pelinescu-Onciul:
On Jul 06, 2010 at 14:06, Klaus Darilion wrote:
Obiously the device is buggy.
But there is also on strange thing at Kamailio: it r
On Jul 06, 2010 at 16:55, Klaus Darilion wrote:
>
>
> Am 06.07.2010 16:36, schrieb Andrei Pelinescu-Onciul:
> >On Jul 06, 2010 at 14:06, Klaus Darilion
> >wrote:
> >>Obiously the device is buggy.
> >>
> >>But there is also on strange thing at Kamailio: it retransmits the
> >>CANCEL although it
Am 06.07.2010 16:36, schrieb Andrei Pelinescu-Onciul:
On Jul 06, 2010 at 14:06, Klaus Darilion 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 s
On Jul 06, 2010 at 14:06, Klaus Darilion 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 addi
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 Win
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 mentio
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
On Jun 24, 2010 at 12:06, Iñaki Baz Castillo wrote:
> 2010/6/17 Andrei Pelinescu-Onciul :
> > 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
>
>
> A quest
2010/6/17 Andrei Pelinescu-Onciul :
> 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
A question about case 2:
---
2 will send and retransmit CANCEL ev
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
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 ver
On Jun 17, 2010 at 16:39, 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 tho
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 s
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
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 expecta
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
re
19 matches
Mail list logo
