gt; Subject: Re: [Sip-implementors] About CANCEL in a proxy (no changes to
> server/client transaction)
>
> 2011/6/10 Bob Penfield :
> > Except for 100 (Trying), a 1xx should always be forwarded upstream
> toward the UAC. Remember, all transactions complete independently.
> There ma
2011/6/11 Joegen E. Baclor :
> My point is, 16.10 has this implied by not mentioning that the response
> context will change in state or not. Having not mentioned it, perhaps it
> implies no change in state is the correct interpretation.
If the proxy should chante the server/client transaction s
On 06/11/2011 01:18 PM, Iñaki Baz Castillo wrote:
> 2011/6/11 Joegen E. Baclor:
>> I agree with this. Yes I followed this thread closely from the start. The
>> question was a "why" (not where it is stated in the RFC) for the sake of
>> those, including myself, understand how a very basic scenario
2011/6/11 Joegen E. Baclor :
> I agree with this. Yes I followed this thread closely from the start. The
> question was a "why" (not where it is stated in the RFC) for the sake of
> those, including myself, understand how a very basic scenario such as call
> cancellation gets this very lengthy di
On 06/11/2011 12:48 PM, Iñaki Baz Castillo wrote:
> 2011/6/11 Joegen E. Baclor:
>> Which begs the question why then do we accept CANCEL UAC rules to apply to
>> proxy transactions and not UAS rules? Shouldn't they always be a pair to
>> ensure end-to-end transaction states are synchronized?
> In c
On 06/11/2011 09:48 AM, Joegen E. Baclor wrote:
> On 06/10/2011 11:09 PM, Iñaki Baz Castillo wrote:
>> 2011/6/10 Brez Borland:
>>> Not clear to me though. If proxy has received a CANCEL from Alice it should
>>> terminate the transaction.
>> This is incorrect. The proxy does not terminate an INVITE
2011/6/11 Joegen E. Baclor :
> Which begs the question why then do we accept CANCEL UAC rules to apply to
> proxy transactions and not UAS rules? Shouldn't they always be a pair to
> ensure end-to-end transaction states are synchronized?
In case of CANCEL, if the proxy forwarded the INVITE, then
On 06/10/2011 11:09 PM, Iñaki Baz Castillo wrote:
> 2011/6/10 Brez Borland:
>> Not clear to me though. If proxy has received a CANCEL from Alice it should
>> terminate the transaction.
> This is incorrect. The proxy does not terminate an INVITE server
> transaction when it receives a CANCEL. It jus
2011/6/10 Brez Borland :
> Not clear to me though. If proxy has received a CANCEL from Alice it should
> terminate the transaction.
This is incorrect. The proxy does not terminate an INVITE server
transaction when it receives a CANCEL. It just cancels pending
branches and UAS's are supposed to ter
On Fri, Jun 10, 2011 at 1:46 PM, Iñaki Baz Castillo wrote:
> 2011/6/10 Bob Penfield :
> > Except for 100 (Trying), a 1xx should always be forwarded upstream toward
> the UAC. Remember, all transactions complete independently. There may be a
> 2xx final response right behind the 1xx response. The
2011/6/10 Bob Penfield :
> Except for 100 (Trying), a 1xx should always be forwarded upstream toward the
> UAC. Remember, all transactions complete independently. There may be a 2xx
> final response right behind the 1xx response. The CANCEL can only change the
> state of an INVITE transaction in
: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
Castillo
Sent: Friday, June 10, 2011 8:35 AM
To: Bob Penfield
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] About CANCEL in a proxy (no
2011/6/10 Iñaki Baz Castillo :
> 2011/6/10 Bob Penfield :
>> Yes, in this case, a transaction stateful proxy should send a CANCEL to Bob
>> when the 1xx is received. Yes, you do need to save "state", but that can be
>> as simple as a flag in the client transaction that indicates a CANCEL should
2011/6/10 Bob Penfield :
> Yes, in this case, a transaction stateful proxy should send a CANCEL to Bob
> when the 1xx is received. Yes, you do need to save "state", but that can be
> as simple as a flag in the client transaction that indicates a CANCEL should
> be sent when a 1xx arrives.
I did
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
Castillo
Sent: Thursday, June 09, 2011 7:15 PM
To: Bob Penfield
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] About CANCEL in a proxy (
2011/6/10 Brez Borland :
> In your case Proxy acts as a UAC for Bob, so Client Behavior applies.
Sorry, I missed your mail. So ok, thanks a lot.
--
Iñaki Baz Castillo
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://li
2011/6/10 Iñaki Baz Castillo :
> - Alice calls Bob through a proxy.
> - Proxy sends the INVITE to Bob and replies 100 to Alice.
> - Proxy gets no provisional response fmo Bob.
> - Alice sends CANCEL after a while.
> - Proxy replies 200 for CANCEL.
> - Proxy doesn't send CANCEL to Bob as there is no
2011/6/9 Bob Penfield :
> The requirement for having received a 1xx response does apply to transaction
> stateful proxies. If the proxy does not wait, you have the same issue as you
> have with the UA in that the CANCEL could potentially arrive at a downstream
> proxy or the UAS before the INVIT
On Thu, Jun 9, 2011 at 10:32 PM, Iñaki Baz Castillo wrote:
> 2011/5/11 Bob Penfield :
> > You have it correct. The proxy's job is to pass the CANCEL on each branch
> of the matching transaction. The basic rule of SIP is that all transactions
> complete independently. The state of the transactions
-Original Message-
From: Iñaki Baz Castillo [mailto:i...@aliax.net]
Sent: Thursday, June 09, 2011 5:33 PM
To: Bob Penfield
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] About CANCEL in a proxy (no changes to
server/client transaction)
2011/5/11 Bob Penfield :
>
2011/5/11 Bob Penfield :
> You have it correct. The proxy's job is to pass the CANCEL on each branch of
> the matching transaction. The basic rule of SIP is that all transactions
> complete independently. The state of the transactions is dependant only on
> the response(s) for the request and th
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
Castillo [i...@aliax.net]
This is, basically the CANCEL processing in the proxy changes nothing
in the proxy itself. Do I miss som
2011/5/11 Bob Penfield :
> You have it correct. The proxy's job is to pass the CANCEL on each branch of
> the matching transaction. The basic rule of SIP is that all transactions
> complete independently. The state of the transactions is dependant only on
> the response(s) for the request and th
: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
Castillo
Sent: Wednesday, May 11, 2011 9:56 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] About CANCEL in a proxy (no changes to
server/c
Hi, when a stateful proxy receives a CANCEL and generates a CANCEL for
the pending client transactions (those in Proceeding state so have
replied at least a 1XX response), the state of the server transaction
and clients transaction is not modified in the proxy itself.
So, after processing the CANC
25 matches
Mail list logo
