Alex Balashov wrote:
> SIP wrote:
>
>
>
> What is your citation for this qualification? RFC 3261 does not seem to
> me to say that, as in 13.1:
>
> Because of the protracted amount of time it can take to receive final
> responses to INVITE, the reliability mechanisms for INVITE
> transactions differ from those of other requests (like OPTIONS).
> Once it receives a final response, the UAC needs to send an ACK for
> every final response it receives.
>
> Or 13.2.2.4 ("2xx Responses"):
>
> The UAC core MUST generate an ACK request for each 2xx received from
> the transaction layer.
>
>
>
I think, perhaps, I am misremembering the difference between sec. 17
ACKs and sec. 13 ACKs. I'm pretty sure one has somewhat less stringent
requirements when sending an ACK from a TU (which a client would be, and
Asterisk is, since it's not a transactionless server).
I vaguely remember the language being softer in its requirements (which
is where the initial confusion on the Implementors list arose when we
were interpreting it).
N.
_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
AstriCon 2009 - October 13 - 15 Phoenix, Arizona
Register Now: http://www.astricon.net
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
