Hi,
1. ACK request for 2xx response of INVITE request is not part of client
transaction.
2. ACK request for 2xx response of INVITE request is send by UAC (means User
Agent Client) and re-transmission of ACK request is also done by UAC.
Please refer to section 17 of RFC 3261 for more clarity.
If the response was a 2xx, the ACK is not considered
part of the transaction.
The reason for this separation is rooted in the importance of
delivering all 200 (OK) responses to an INVITE to the UAC. To
deliver them all to the UAC, the UAS alone takes responsibility
for retransmitting them (see Section 13.3.1.4), and the UAC alone
takes responsibility for acknowledging them with ACK (see Section
13.2.2.4). Since this ACK is retransmitted only by the UAC, it is
effectively considered its own transaction.
Thanks & Regards,
Ravi Kumar
****************************************************************************
****************************
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Leo Leo
Sent: Friday, May 27, 2011 8:55 PM
To: [email protected]
Subject: Re: [Sip-implementors] Is it a wrong statement about SIP
clienttransaction in RFC 3261?
Hi,
As far as I understand section 17 from RFC 3261, the invite client
transaction must to send an ACK for any final response received after
sending the INVITE. This client transaction still stays alive for 64*T1 and
it should re-send with an ACK for any final response retransmited by UAS.
After 64*T1, with timeout, this client transaction should be setted to
TERMINATED state.
Into an ideal environment, no final response will be received. Into a
pratical one, once receiving some final response referenced for an
transaction already terminated, the response shall be sent by core. The
core, by the way, shall check if the dialog exists and decides what to do.
For example, only sends an ACK, send an ACK followed by a BYE, send an ACK
and modify the RTP connection, or any other implemmentation issue.
Please, understand "final response" as any response from 2xx to 6xx.
Leonardo
________________________________
De: yan wang <[email protected]>
Para: [email protected]
Enviadas: Sexta-feira, 27 de Maio de 2011 5:01
Assunto: [Sip-implementors] Is it a wrong statement about SIP client
transaction in RFC 3261?
Hi,
Recently, I was reading the SIP fundamental RFC 3261. Regarding
Chapter 17 Transactions, I found there may be a wrong statement for client
transaction in the following excerpt:
The client transaction is also responsible for
receiving responses
and delivering them to the TU, filtering out any
response
retransmissions or disallowed responses (such as a
response to ACK).
Additionally, in the case of an INVITE request, the client transaction is
responsible for generating the ACK
request for any final response accepting a 2xx response.
I highlight it with RED and GREEN. With my
understanding, it should be: the client transaction is responsible for
generating the ACK request for any final response EXCEPTING (not
accepting) a
2xx response since the generation of the ACK for the 2xx is handled by the
UA
core but not the client transaction.
Is it a wrong statement for SIP client transaction definition in RFC 3261?
Thanks,Spencer Wang
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
