Subject: RE: [Sip] Changes to the INVITE transaction to address bug 769

From: "Bohaty David" <[email-masked]>
Date: Tue, 3 Jul 2007 11:30:00 +0200

Hello,

just my though about the draft, related to the requirement 
	"The client transaction SHOULD start timer D when it enters the
"Completed" state for any reason, with a value of at least 32 seconds
for unreliable transports, and a value of zero seconds for reliable
transports": 

For client transactions, wouldn't it be better that the timer D is set
to 32s even for reliable transport after receiving 200-299 response, so
the transaction can collect also responses to a forked INVITE? This
would align the INVITE transaction with the UAC Core behaviour, which
according to "RFC3261 13.2.2.4 2xx Responses" considers the INVITE
transaction completed 64*T1 seconds after the reception of the first 2xx
response.
Also the 200-299 is retransmitted end-to-end, so the reliability of the
transport to the first hop does not really mean that the response or ACK
is sent reliably all the way from UAS to UAC, respectivelly from UAC to
UAS.

David Bohaty
System Architect
 
SITRONICS Telecom Solutions, Czech Republic a.s. 
Tel.: +420 226 532 578, Fax: +420 241 480 899
BB Centrum - Beta, Vyskocilova 1481/4, 140 00  Praha 4, Czech Republic
www.sitronicsts.com

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: 28 June 2007 04:35
To: SIP IETF
Subject: [Sip] Changes to the INVITE transaction to address bug 769

Everyone -

I've put together a proposal for addressing the spec bug captured at
http://bugs.sipit.net/show_bug.cgi?id=769

Please read through
http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-00.txt
and comment.

RjS

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Robert Sparks <[email-masked]>
Date: Tue, 3 Jul 2007 09:03:40 -0500

Hrmm. I think you're right, and the place where it makes a big  
difference is at
proxies in the path of the 200 that have a TCP hop on either side of  
them - we want
that client transaction to still be there for retransmissions of the  
200.

Whether the fix is as simple as setting timer D will take more  
thinking (and I want
to wait for more feedback on the rest of the draft before cracking  
this open).

I've started a list of things to work through with this item.

Thanks,

RjS

---

From: "Bohaty David" <[email-masked]>
Date: Tue, 10 Jul 2007 12:45:31 +0200

Hello,
I have 2 more thoughts on the draft:

First comment is related to the state machine for INVITE server transaction in which I would say is missing treatment for the transport error in the "Accepted" state. On transport error there could be new transition from "Accepted" to "Terminated" with label "Transport Error Inform TU".

Second comment is related to treatment of responses to INVITEs forked by a proxy further downstream. In that case multiple dialogs can be established and we should not just accept from or deliver to TU different 200-299 responses after the first one have been received, but also 101-199 which can related to the other early dialogs and depending on the timing can arrive even after the 200-299 for the first dialog. So for client transaction in the "Completed" state the label "2xx 2xx to TU" could be changed to "101-299 101-299 to TU". For the server transaction in the "Accepted" state the label could be changed from "2xx from TU send response" to "101-299 from TU send response". The TU should submit 101-199 to the server transaction in the "Accepted" state only if it is proxy and only when it is related to different dialog than the already confirmed one (if it is dialog-stateful proxy).

David Bohatý
System Architect

DISCLAIMER
This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: 28 June 2007 04:35
To: SIP IETF
Subject: [Sip] Changes to the INVITE transaction to address bug 769

Everyone -

Please read through

RjS

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use [email-masked] for questions on current sip Use [email-masked] for new developments on the application of sip

---

From: "Nasir Khan" <[email-masked]>
Date: Mon, 16 Jul 2007 23:42:21 -0700

Hi Robert,

I have 3 comments / suggestions w.r.t this ID.

Comment-1
----------------
Should there be any change with respect to receiving CANCEL in Accepted
state? Hitherto the UAC was getting a 481/CANCEL in such cases. Now we will
get 200/CANCEL with no effect on IST.
The reason for this question is backwards compatibility, however I can
myself argue both ways on this one. What do you think?

Comment-2
-----------------
In section 6.7 of the ID about the Timer-L you say - "and the amount of time
this (or any downstream) UAS core might be retransmitting the 2xx while
waiting for an ACK. "

How does 2xx retransmission timer affect the choice of Timer L?

Comment-3
-----------------
Shouldnt the Timer L be set to T4 which represents the amount of time the
network will take to clear messages between client and server transactions?
Since 2xx is sent reliably anyway, IMHO we do not need to link Timer L to
Timer B.

Thanks

Nasir Khan
BEA Systems Inc.

-- 
Discuss SIP Servlets at http://groups.google.com/group/sipservlets/

---

From: Robert Sparks <[email-masked]>
Date: Tue, 17 Jul 2007 09:38:40 -0500

On Jul 17, 2007, at 1:42 AM, Nasir Khan wrote:

> Should there be any change with respect to receiving CANCEL in  
> Accepted state? Hitherto the UAC was getting a 481/CANCEL in such  
> cases. Now we will get 200/CANCEL with no effect on IST.
> The reason for this question is backwards compatibility, however I  
> can myself argue both ways on this one. What do you think?

I don't see any issue here. The UAC already has to be prepared for  
either response.

>
>
> Comment-2
> -----------------
> In section 6.7 of the ID about the Timer-L you say - "and the  
> amount of time this (or any downstream) UAS core might be  
> retransmitting the 2xx while waiting for an ACK. "
>
> Shouldnt the Timer L be set to T4 which represents the amount of  
> time the network will take to clear messages between client and  
> server transactions?
> Since 2xx is sent reliably anyway, IMHO we do not need to link  
> Timer L to Timer B.

For both of these comments - Timer L is keeping the transaction in  
place while the TU on top of this server transaction finishes its
job of retrasmitting 200s until it gets an ACK. It's not just  
clearing messages that are already in the network. Remember that those
200s might get lost, and timers on the UAC's side will cause the  
INVITE request to be retransmitted. This Timer makes sure the
server transaction is still there to receive that retransmitted  
INVITE.  Does this clear up the questions you had?

---

From: "Nasir Khan" <[email-masked]>
Date: Mon, 23 Jul 2007 21:32:32 -0700

Should there be one more change to 3261 for invfix?

Section 14.1 para 6 point # 2 should include the Accepted state?

"If there is an ongoing INVITE server transaction, the TU MUST wait until
the transaction reaches the confirmed, *accepted* or terminated state before
initiating the new INVITE"

Thanks

Nasir Khan

BEA Systems Inc.

On 7/17/07, Robert Sparks <[email-masked]> wrote:
> I don't see any issue here. The UAC already has to be prepared for either
> response.
>
>
>
>
> Comment-2
> -----------------
> In section 6.7 of the ID about the Timer-L you say - "and the amount of
> time this (or any downstream) UAS core might be retransmitting the 2xx while
> waiting for an ACK. "
>
> For both of these comments - Timer L is keeping the transaction in place
> while the TU on top of this server transaction finishes its
> job of retrasmitting 200s until it gets an ACK. It's not just clearing
> messages that are already in the network. Remember that those
> 200s might get lost, and timers on the UAC's side will cause the INVITE
> request to be retransmitted. This Timer makes sure the
> server transaction is still there to receive that retransmitted INVITE.
> Does this clear up the questions you had?
>
>
>
> Thanks
>
> Nasir Khan
> BEA Systems Inc.
>
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 24 Jul 2007 08:36:20 -0500

Yes - thanks! I'll comb for related text.

RjS

On Jul 23, 2007, at 11:32 PM, Nasir Khan wrote:

> "If there is an ongoing INVITE server transaction, the TU MUST wait  
> until the transaction reaches the confirmed, *accepted* or  
> terminated state before initiating the new INVITE"
>
> Thanks
>
> Nasir Khan
>
> BEA Systems Inc.
>