Chris Mills wrote:
> 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.
The TU is anything that resides above the transaction layer. One type of
TU is the UAC core (another is UAS core, and another is proxy core). If
you substitute UA core for TU in your concern above, there is no longer
any issue.
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,
No; the transport layer will pass the ACK right up to the TU (UAS core
in this case). Quoting lines 2878+ in section 19.2.1:
Next, the client transport attempts to match the request to the client
transaction. It does so using the matching rules described in Section
17.2.3. If a matching server transaction is found, the request is passed
2879
to that transaction for processing. If no match is found, the request is
passed to the core, which may decide 2880
to construct a new server transaction for that request. 2881
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PH: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
