ACK is only for INVITE requests.
 
Regards,
Hisham
-----Original Message-----
From: ext Radhika [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 14, 2002 8:49 PM
To: Ramachandran Iyer; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [Sip-implementors] Via branch in ACK for 200?

Hello All,
 
The content of the mail says that an ACK is sent for a 200 OK. But as per my understanding, 200 OK is a final response and in case of say, a Registrar, there is no ACK received by it, when it sends a 200 OK.
 
Please correct me if I am wrong.
 
Thanks and Regards,
Radhika.
----- Original Message -----
Sent: Wednesday, March 13, 2002 10:00 PM
Subject: RE: [Sip-implementors] Via branch in ACK for 200?

hi,

I guess the question being asked here is more from a client perspective

of what an UAC is supposed to do while sending an ACK back.. for a non-2xx final response...

As mentioned earlier, the spec makes it clear for an ACK being sent for a non-2xx final response

as having to have the branch parameter in Via (17.1.1.3) same as that of the INVITE request

as this ACK will belong to the same transaction.

But an ACK for 2xx final response, will be a new transaction in itself and thus as per the spec should

have a unique branch parameter, which the UAC would need to construct. But now again the UAS

does'nt really have to do anything about it as an ACK does'nt solicit a response. So the branch may

not really be of any use.

Could we get some more clarity on this.

Rama

  Brett Tate <[EMAIL PROTECTED]> wrote:

> In ACK generated by client transaction for non-200 responses
> the bis clearly states that the topmost Via should be used
> when constructing the ACK request. What about the ACK
> generated for 200 OK? I guess that this kind of ACK should
> have a unique Via branch ( not matching the ACKed INVITE's
> branch) but I couldn't clearly derive it from bis. Could
> someone please clarify what is the correct behaviour ?

After sending a 200 response, the UAS/proxy
cannot rely upon the branch being the
same because the prior proxy might not
have added itself to the record-route.
Thus it ultimately should not make a
difference either way.
> ATTACHMENT part 2 application/ms-tnef name=winmail.dat



Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!

Reply via email to