[SIPForum-discussion] ACK handling in 2xx and non-2xx messages

[abhishek.chattopadhyay at wipro.com]

Hi,

In the first place ACK is generated only for the final response to an
invite, further the ACK for 200 ok is end-to-end where as the ACK of any
other final response as 3xx, 4xx, 5xx, 6xx are sent hop by hop.

But things might not be same if there are proxies who have added their
contacts in the Record-Route header and wish to see the response to the
request that they forwarded, then all messages become hop to hop.

 

I think is that the handling is different because the following two
reasons.

 

Like a reliable 183 Progress would keep re-transmitting until the Prack
is received, similarly 200 OK for invite would keep on re-transmitting
till an ACK is received or the transaction times out (which ever is
earlier). And no underlying proxy is eligible to send this ACK to stop
the re-transmission (for reasons like the media transporting capability
of the ACK message). So this becomes the sole responsibility of the UAC
to re-transmit it. So it is deemed as its own transaction. 

 

Moreover I believe this is the only response possible within an invite
transaction which can be generated using a human intervention (keeping
aside bots which produce the 200 Ok for invites but at large they also
has the same motive)

 

Regards 
ABHISHEK 

 

________________________________

From: discussion-bounces at sipforum.org
[mailto:discussion-bounces at sipforum.org] On Behalf Of Tanna, Nisarg
Sent: Saturday, June 06, 2009 1:02 AM
To: discussion at sipforum.org
Subject: [SIPForum-discussion] ACK handling in 2xx and non-2xx messages

 

Hello,

 

Why does the 2xx gets a unique handling for ACK messages? When client
transaction receives a 300-699 message, it creates an ACK message and
sends it out and informs TU about it. But if the client tx receives 2xx
message, it cannot generate ACK message. It has to let the UAC core to
send the ACK message. Can someone explain why the difference?

 

Thanks,

Nick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20090609/53683c1b/attachment-0002.html>