2010/5/4 Alex Hermann :
> On Friday 30 April 2010 13:25:13 Iñaki Baz Castillo wrote:
>> Yes, I agree. In fact draft invfix solves it by adding a new state
>> "Accepted" so when a 200 is sent the server transaction remains in
>> memory for a while (to absorbe INVITE retransmissions).
>>
>> But anywa
On Friday 30 April 2010 13:25:13 Iñaki Baz Castillo wrote:
> Yes, I agree. In fact draft invfix solves it by adding a new state
> "Accepted" so when a 200 is sent the server transaction remains in
> memory for a while (to absorbe INVITE retransmissions).
>
> But anyway the transaction is in "Accep
On Monday 03 May 2010, Iñaki Baz Castillo wrote:
> > We just drop them. In the sr configuration i think there is also a
> > similar method implemented (etc/sip-router.cfg, route[CATCH_CANCEL]). In
> > the past on our systems we've tried to forward them stateless, but this
> > created some loop cond
2010/5/3 Henning Westerholt :
>> 16.10 CANCEL Processing
>> [...]
>> If a response context is not found, the element does not have any
>> knowledge of the request to apply the CANCEL to. It MUST statelessly
>> forward the CANCEL request (it may have statelessly forwarded the
>> asso
On Friday 30 April 2010, Iñaki Baz Castillo wrote:
> [..]
> Not exactly, sorry, the proxy should forward the CANCEL stateless:
>
> 16.10 CANCEL Processing
>[...]
>If a response context is not found, the element does not have any
>knowledge of the request to apply the CANCEL to. It MUS
2010/4/30 Jiri Kuthan :
>> I don't agree. As per RFC 3261 when a proxy receives a 200 for an
>> INVITE the transaction is terminated so a CANCEL after the 200 should
>> not match such transaction.
>
> That's a bug in the RFC and we shall not better projects RFC bugs in
> implementations :) A well b
Iñaki Baz Castillo wrote:
2010/4/30 Klaus Darilion :
200 OK seems correct as long as the transaction is still in memory.
http://tools.ietf.org/html/rfc3261#section-9.2
I don't agree. As per RFC 3261 when a proxy receives a 200 for an
INVITE the transaction is terminated so a CANCEL after the
2010/4/30 Iñaki Baz Castillo :
> But anyway, if the INVITE has been replied with a 200 it makes no
> sense at all to send a CANCEL so the proxy shouldn't reply 200 to the
> CANCEL, but a 481.
Not exactly, sorry, the proxy should forward the CANCEL stateless:
16.10 CANCEL Processing
[...]
If
2010/4/30 Klaus Darilion :
>> I don't agree. As per RFC 3261 when a proxy receives a 200 for an
>> INVITE the transaction is terminated so a CANCEL after the 200 should
>> not match such transaction. Then the proxy should reply 481 to the
>> CANCEL rather than a 200.
>
>
> If the transaction
>
Am 30.04.2010 11:37, schrieb Iñaki Baz Castillo:
2010/4/30 Klaus Darilion:
200 OK seems correct as long as the transaction is still in memory.
http://tools.ietf.org/html/rfc3261#section-9.2
I don't agree. As per RFC 3261 when a proxy receives a 200 for an
INVITE the transaction is terminate
2010/4/30 Klaus Darilion :
> 200 OK seems correct as long as the transaction is still in memory.
>
> http://tools.ietf.org/html/rfc3261#section-9.2
I don't agree. As per RFC 3261 when a proxy receives a 200 for an
INVITE the transaction is terminated so a CANCEL after the 200 should
not match such
200 OK seems correct as long as the transaction is still in memory.
http://tools.ietf.org/html/rfc3261#section-9.2
regards
klaus
Am 30.04.2010 10:22, schrieb Iñaki Baz Castillo:
2010/4/29 pars3c:
Hi, i have a problem about the handling of the “cancel” message.
The B side answer with OK, af
2010/4/29 pars3c :
> Hi, i have a problem about the handling of the “cancel” message.
> The B side answer with OK, after a while , a send a CANCEL. I don’t know why
> Kamailio don’t forward this message to the B side.
Because Kamailio already received a 200 for the INVITE transaction so
it's term
Hi, i have a problem about the handling of the "cancel" message.
The call flow is this:
A -> (Invite)Proxy (P)
B
(100 Tryng) <---
->(Invite) B
(100 Try
14 matches
Mail list logo
