[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] draft-sparks-sip-invfix-02 (was Re:draft-sparks-sip-invfix-01: comments and questions)
I agree, a change of reaction to transport error is a "game" with edge-conditions. I also agree that issuing of a new special and only transport error fixing RFC makes no sense - but what about in situation when a new fixing RFC is in progress to address another error? I think it makes sense to think about it in INV server transaction case.
As you responded, the change of reaction to transport error in Completed and Accepted states (saving current states) solves possible different final response(s) and due to this it may be important accept this change. I have tried to think about it also for Proceeding state, but I don't see any important reason for this change. I have found out only these (just improving) minor reasons:
1) if the TU receives transport error notification, and the TU successfully initiate repair of transport layer, how the TU may send a response when the transaction layer is in the Terminated state? Note there is no sure that retransmission(s) of INV request will happen (especially in case when a 1xx response has been already successfully received by a UAC and there is no NAT between UAC and UAS).
2) I am not sure (it is not clearly specified) who (transaction layer or TU) behaves according to RFC 3263, section 5, page 12, paragraph 1. If this is the job of TU, and a transport error happens, and the transaction layer is destroyed, how the TU can send a response to a new IP:port pair?
Kolomaz
-----Original Message-----
From: Robert Sparks [mailto:rjsparks at nostrum.com]
Sent: 8. září 2008 22:31
To: Kolomaznik Jan
Cc: SIP at ietf.org List
Subject: Re: [Sip] draft-sparks-sip-invfix-02 (was Re:draft-sparks-sip-invfix-01: comments and questions)
Inline.
On Sep 8, 2008, at 3:05 AM, Kolomaznik Jan wrote:
> OK, but if we want to receive and mask all request retransmissions
> on transaction layer, this problem is more general. Than we probably
> need to inform TU about transport error
the next version of the draft (hopefully out later today) will do this.
> , create a new state,
I don't see the need fo rthis
> and stay there enough time to absorb all retransmissions of INVITE
> request.
The existing Accepted state does this.
> And this is needed for transport error reaction not only in
> Accepted state, but also for transport error in Proceeding and
> Completed states.
Those states already transition to Terminated on transport error -
(they did so in 3261).
I think I see what you're getting at on keeping state after this
transport error is noticed though - I don't know about Proceeding, but
if you're in Completed, throwing away the state when you try to send
your final response and the transport complains may not be the right
thing to do. Let me poke at that for a little while.
> There also may be a question whether to inform TU about transport
> error in Proceeding and Completed states while there is probably no
> state of TU in these states of transaction layer.
That TU has decided to send a provisional or failure-final response in
those cases. There's a chance there is application state being
maintained as a result (or precondition) to those decisions, so
letting the TU know is important. Again, this was 3261 behavior already.
>
>
> Please note that if we accept that the SIP transaction layer has to
> receive and mask all request retransmissions when it detects a
> transport error, then also non-INVITE server transaction should be
> changed - reaction to transport error in Proceeding and Completed
> states.
Will look.
Its probably worth pulling up and asking if trying to address this
kind of edge-condition failure is worth the effort.
The changes we're talking about here won't make something succeed
later - its not going to help the network or application repair/
recover from whatever transport error is being reported. What it will
do is help prevent an application from re-performing some work based
on a retransmission (possibly causing different resulting end-states).
That might be enough justification on its own, but its worth asking if
this is really a big enough problem to take on the fix?
>
>
> Kolomaz
>
>
> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks at nostrum.com]
> Sent: 5. září 2008 22:17
> To: Kolomaznik Jan
> Cc: SIP at ietf.org List
> Subject: Re: [Sip] draft-sparks-sip-invfix-02 (was Re:draft-sparks-
> sip-invfix-01: comments and questions)
>
> Nits fixed.
>
> For your suggestion 4 below:
>
> It would not be the right thing to transition to Terminated - we want
> the transaction state to still be around to receive any
> retransmissions of the INVITE, but it might make sense to tell the TU
> that its 2xx's aren't going anywhere. I'll work that into the figure
> and text unless someone objects here quickly.
>
> RjS
>
> On Jul 23, 2008, at 10:27 AM, Kolomaznik Jan wrote:
>
>> I have just a couple of nits:
>>
>> 1. State labeled Completed on Figure 2 should be labeled Accepted
>>
>> 2. section 7.3 paragraph 1 contains "... receiving any response SIP
>> response ..."
>>
>> 3. While whole section 18 in RFC 3261 deals with SIP transport layer
>> regardless transaction stateful or stateless behavior, it could be
>> explicitly clarified that suggested change of section 18.1.2 (in
>> invfix
>> section 8.8) tells just about stateful behavior.
>>
>> 4. INVITE server state machine doesn't react to transport error in
>> Accepted state. It could contain transition from Accepted to
>> Terminated
>> state conditioned by transport error - analogy to transitions from
>> Proceeding and Completed states.
>>
>> Jan
>>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip