Subject: Re: [Sip] Problem with bis05 state machine

From: [email-masked]
Date: Wed, 5 Dec 2001 07:57:02 +0530

Hi,

There are two points you had raised and I have attempted to clarify those:-

1>TU and the UAC Core are one and the same thing. Pl correct me if I am
wrong guys. So when the state machine says that UAC Core generates the ACK
it actually means that the 2xx response received bypassed  thru the txn
layer and went straight to the next layer, which is the TU or the UAC Core.
It is this layer that automatically generated the ACK.

2>If a 2xx is sent from the TU then the txn is terminated. According to the
bis05 in case a request is received for which no transaction exists it is
passed straight to the core. Thus even if the txn is terminated , the TU
would get to see the ACK since that is the highe entity to which the ACK
would be passed forward to.

-Regards
R.Kamath

"Chris Mills" <[email-masked]> on 12/04/2001 03:21:34 PM

To:   "[email-masked]'" <[email-masked]>
cc:    (bcc: P Raghavendra Kamath/HSSBLR)

Subject:  [Sip] Problem with bis05 state machine

I have seen a potential problem in the bis05 state machine. This problem is
specifically in the INVITE client transaction state machine. It is stated
that if a 2xx is received in the 'calling' or 'proceeding' states that the
UAC core will automatically generate an ACK in response. This causes a
problem when the session offer has been sent in the 2xx (as opposed to in
the INVITE) in such a case the TU needs to answer this offer, and therefore
it must generate the ACK. A corresponding potential problem is found in the
INVITE server transaction state machine, where if a 2xx is sent from the TU
the state machine transitions directly to the terminated state. This
suggests that the TU never sees the ACK, and consequently would never see
the answer part of any session description contained in the 2xx-ACK pair.

Chris Mills

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 5 Dec 2001 12:41:20 -0500

> -----Original Message-----
> From: Brian Quinlan [mailto:[email-masked]]
> Sent: Wednesday, December 05, 2001 6:15 AM
> To: Chris Mills; [email-masked]
> Subject: RE: [Sip] Problem with bis05 state machine
> 
> This allows for the situation you describe where "TU needs to 
> answer this
> offer, and therefore it must generate the ACK".

Correct.

> 
> As for the server, I had been assuming that an ACK received after the
> corresponding transaction had terminated would be passed 
> straight to the TU,
> though having looked I concede that I don't see this 
> explicitly stated in
> section 17. Any pointers?

Lines 2878-2881. When the server transaction sends the 2xx, the server
transaction is destroyed. As a result, when the ACK arrives, there is no
matching server transaction, so the transport passes it up to the core. Its
worth adding a note here to explicitly say that this is how ACK for 2xx are
passed up to the UAS core after the transaction is done.

> 
> Which leads neatly on to the following from section 13.4.1.4 
> in bis-05:

I think you mean 13.3.1.4.

> 
> Once the response has been constructed it is passed to the 
> INVITE server
> transaction. Note, however, that the INVITE server 
> transaction does not
> retransmit 2xx responses to an INVITE. Therefore, it is neces- 1879
> sary to pass periodically the response to the server 
> transaction until the
> ACK arrives. 1880
> 
> If a 2xx has been sent, then the server transaction state 
> would have changed
> to Terminated and the transaction would have been destroyed, 
> so there isn't
> any longer a transaction to which one can "pass periodically 
> the response".

Excellent point. It is passed directly to transport after the first. We will
fix.

-Jonathan R.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf 
> Of Chris Mills
> Sent: 04 December 2001 15:22
> To: [email-masked]'
> _______________________________________________
> Sip mailing list  http://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
> 

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://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