No Subject

When in either the “calling” or “proceeding” states, reception of a 2xx
response MUST cause the client transaction to enter the terminated state,
and the response MUST be passed up to the TU. The handling of 2599
this response depends on whether the TU is a proxy core or a UAC core. A UAC
core will handle generation 2600
of the ACK for this response, while a proxy core will always forward the 200
OK upstream. The differing 2601
treatment of 200 OK between proxy and UAC is the reason that handling of it
does not take place in the 2602
transaction layer. 2603

This allows for the situation you describe where "TU needs to answer this
offer, and therefore it must generate the ACK".

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?

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

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".

My apologies if this issue has already been pointed out on the list.

Bye,
Brian

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Chris Mills
Sent: 04 December 2001 15:22
To: 'sip@ietf.org'
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


_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip