At 15:37 12/03/2008, Maxim Sobolev wrote:
Dan Pascu wrote:
Anyway, examples are many and I'm sure people can even find more practical
ones. The main reason for all of them being possible, is the fact that a
CANCEL is no longer really canceling the call under these circumstances,
and that
On Thursday 13 March 2008, Juha Heinanen wrote:
Dan Pascu writes:
Do you have any suggestion how can this be at least addressed, if
not solved, using the current RFC framework?
i haven't followed the proposed solutions in detail, but the solution
does not need to be RFC complaint as long
On Thursday 13 March 2008, Rick van Rein wrote:
Dan,
But, to get involved with the discussion itself, what you are trying to
do is deny relativity.
I don't think I am. I'm not speaking of the race condition case where the
200 OK and the CANCEL arrive at the same time and it order of them
On Thursday 13 March 2008, Alex Hermann wrote:
I was expressing more of an idea for an alternate approach, out of
the RFC specs, because as it is the RFC seems to not be able to cover
this case. What I meant, is that if the CANCEL is sent after a 200
OK, but before the ACK, it should mean
Dan Pascu wrote:
On Thursday 13 March 2008, Alex Hermann wrote:
I was expressing more of an idea for an alternate approach, out of
the RFC specs, because as it is the RFC seems to not be able to cover
this case. What I meant, is that if the CANCEL is sent after a 200
OK, but before the
On Thursday 13 March 2008, Anatoly Pidruchny wrote:
The NACK may work, but it would be a very big and fundamental RFC
change. And it would be very disruptive, because it is not compatible
with the current RFC.
It is probably one of the simplest ways to solve the conflict. About how
disruptive
On Thursday 13 March 2008, Juha Heinanen wrote:
Dan Pascu writes:
I'm sure there is more than one way to do this. The NACK sounds the
simplest and least disruptive of all the ideas mentioned so far.
anything that requires changes in SIP UAs is a very long term solution.
That is very
Dan Pascu writes:
Do you have any suggestion how can this be at least addressed, if not
solved, using the current RFC framework?
i haven't followed the proposed solutions in detail, but the solution
does not need to be RFC complaint as long as it does not assume any
changes in rfc complaint
What it is not clear to me in this case, is what does the proxy do if
there is no 1xx reply but the 200 OK comes in directly (after the CANCEL
was received and the INVITE continued to be retransmitted). In this case
it cannot send a CANCEL, or can it? Can a CANCEL be sent after a 200 OK
but
There is no ambiguity and no B2B functionality is needed. The call is
only officially cancelled when originating UA gets final negative
reply to INVITE transaction. Sending CANCEL is not guaranteed to result
in final negative reply to INVITE, RFC is very specific on that and any
It makes sense, however I still have reservations that accounting is
handled as one would expect in this case. While all the approach you
details here makes sense from a technical point of view as per RFC
requirements, then end user experience is different.
Consider the case where I call a
Dan Pascu schrieb:
What it is not clear to me in this case, is what does the proxy do if
there is no 1xx reply but the 200 OK comes in directly (after the CANCEL
was received and the INVITE continued to be retransmitted). In this case
it cannot send a CANCEL, or can it? Can a CANCEL be
Dan Pascu schrieb:
That is not the case. If a 200 OK happens to come at the same time with
the CANCEL and there is a race condition and the call does get setup and
charged, I can explain my subscriber that he happened to put the call on
hook at the same time it was answered by the other
Dan Pascu wrote:
Anyway, examples are many and I'm sure people can even find more practical
ones. The main reason for all of them being possible, is the fact that a
CANCEL is no longer really canceling the call under these circumstances,
and that the user is stripped from it's ability to
Maxim Sobolev writes:
All this has nothing to do with the SIP, really. It just illustrates the
point that SIP proxy is bad choice for real-time VoIP accounting.
i didn't notice that someone in this discussion would have suggested to
use sip proxy for accounting. accounting in the examples
On Wednesday 12 March 2008, Maxim Sobolev wrote:
Dan Pascu wrote:
Anyway, examples are many and I'm sure people can even find more
practical ones. The main reason for all of them being possible, is
the fact that a CANCEL is no longer really canceling the call under
these circumstances,
Juha Heinanen wrote:
Maxim Sobolev writes:
All this has nothing to do with the SIP, really. It just illustrates the
point that SIP proxy is bad choice for real-time VoIP accounting.
i didn't notice that someone in this discussion would have suggested to
use sip proxy for
On Wednesday 12 March 2008, Maxim Sobolev wrote:
If you want to isolate ingress and egress dialog state and bill user
only for what he has actually sees use b2bua. Then you will be able to
end ingress call with 487 immediately upon receiving CANCEL and don't
bill user for anything that happens
On Mar 12, 2008 at 23:57, Dan Pascu [EMAIL PROTECTED] wrote:
On Wednesday 12 March 2008, Maxim Sobolev wrote:
No, it's not. Any protocol involving communication delay would have
this problem. It's just the matter of how big the window of opportunity
actually is.
And frankly I don't see
Dan Pascu wrote:
Even if a CANCEL arrives, a call may still be setup with a 200 OK + and
ACK and then immediately closed by a BYE, which is a conceptually a
completely different beast that a simple CANCEL that terminates the call
without it being setup.
No, you are incorrect, it has been a
From the sip-implementors list - looks like Maxim is right.
regards
klaus
Robert Sparks schrieb:
Part of why it does this is to deal with the case that the first
INVITE the proxy sent actually got somewhere, but its response was
lost. The retransmission will stimulate a retransmission of
Klaus Darilion wrote:
From the sip-implementors list - looks like Maxim is right.
Thanks, Klaus! Should this behavior be the default one then?
regards
klaus
Robert Sparks schrieb:
Part of why it does this is to deal with the case that the first
INVITE the proxy sent actually got
Maxim Sobolev schrieb:
Hi,
Disclamer: we discovered this issue with OpenSER 1.3, but it might be
something affecting SER as well, so that I am cross-posting it there.
Basically it looks like there is an issue with transactional CANCEL
processing, potentially related to the presence of
Dan Pascu wrote:
networks with high packet loss issues. Retransmissions deal nicely with
occasional packet loss and that's where it should end.
The TCP/IP operates just fine in networks with 5-10% packet loss. Since
it's the same 3-way handshake method, I see no reason why SIP would not.
Klaus Darilion wrote:
The correct behavior of the tm module in this case would be to continue
with INVITE re-transmits until we get provisional response and immediate
CANCEL once that response comes in.
Is this really the correct behavior? Is this behavior defined in RFC 3261?
--- RFC
Maxim Sobolev schrieb:
Klaus Darilion wrote:
The correct behavior of the tm module in this case would be to
continue with INVITE re-transmits until we get provisional response
and immediate CANCEL once that response comes in.
Is this really the correct behavior? Is this behavior defined
Hi Klaus,
Klaus Darilion wrote:
Maxim Sobolev schrieb:
Klaus Darilion wrote:
The correct behavior of the tm module in this case would be to
continue with INVITE re-transmits until we get provisional response
and immediate CANCEL once that response comes in.
Is this
On Friday 07 March 2008, Maxim Sobolev wrote:
Klaus Darilion wrote:
The correct behavior of the tm module in this case would be to
continue with INVITE re-transmits until we get provisional response
and immediate CANCEL once that response comes in.
Is this really the correct behavior?
Bogdan-Andrei Iancu schrieb:
Klaus Darilion wrote:
Maxim Sobolev schrieb:
According to my reading yes, UAC should wait either arrival of the
first provisional response or expiration of Timer B (doing due
retransmits in the meantime for unreliable transports) and send
CANCEL if
Yes, but this behaviour is not relevant - the scheme takes into account
the result of the Cancelling (487 reply), but not what the client should
do when processing the CANCEL.
Regards,
Bogdan
Klaus Darilion wrote:
Bogdan-Andrei Iancu schrieb:
Klaus Darilion wrote:
Maxim Sobolev schrieb:
On Mar 06, 2008 at 10:43, Maxim Sobolev [EMAIL PROTECTED] wrote:
Bogdan-Andrei Iancu wrote:
Hi Maxim,
You stated:
quote
The correct behavior of the tm module in this case would be to continue
with INVITE re-transmits until we get provisional response and immediate
CANCEL once
Dan Pascu wrote:
On Friday 07 March 2008, Maxim Sobolev wrote:
Klaus Darilion wrote:
The correct behavior of the tm module in this case would be to
continue with INVITE re-transmits until we get provisional response
and immediate CANCEL once that response comes in.
Is this really the correct
Andrei Pelinescu-Onciul wrote:
On Mar 06, 2008 at 10:43, Maxim Sobolev [EMAIL PROTECTED] wrote:
Bogdan-Andrei Iancu wrote:
Hi Maxim,
You stated:
quote
The correct behavior of the tm module in this case would be to continue
with INVITE re-transmits until we get provisional response and
On Mar 07, 2008 at 10:00, Maxim Sobolev [EMAIL PROTECTED] wrote:
Andrei Pelinescu-Onciul wrote:
On Mar 06, 2008 at 10:43, Maxim Sobolev [EMAIL PROTECTED] wrote:
Bogdan-Andrei Iancu wrote:
Hi Maxim,
You stated:
quote
The correct behavior of the tm module in this case would be to continue
Maxim Sobolev writes:
The TCP/IP operates just fine in networks with 5-10% packet loss. Since
it's the same 3-way handshake method, I see no reason why SIP would not.
With SIP making inroads into wireless networks, which are by nature much
more volatile when it comes to delays and
Juha Heinanen wrote:
Maxim Sobolev writes:
The TCP/IP operates just fine in networks with 5-10% packet loss. Since
it's the same 3-way handshake method, I see no reason why SIP would not.
With SIP making inroads into wireless networks, which are by nature much
more volatile when
Maxim Sobolev writes:
TCP has its own issues, with NAT for example.
is there some other NAT problems remaining if UAs keep TCP connection to
their outbound proxy open all the time and regularly issue double-CRLF
keepalive?
-- juha
___
Devel mailing
37 matches
Mail list logo
