Subject: RE: [Sip] Question about ACK for None-200 Response

From: "Chen, Xin (Xin)" <[email-masked]>
Date: Thu, 1 Nov 2001 14:29:31 -0000

Dear Vijay,

Thanks for your answer.

Another question: Why the ACK for non-2xx must not have route header? What
happens if it has? 

Regards

Xin Chen

Lucent Technologies
Tel: +44 1793 883137
Mobile: +44 7799 034668

-----Original Message-----
From: Vijay Gurbani [mailto:[email-masked]]
Sent: 30 October 2001 14:39
To: Chen, Xin (Xin)
Cc: SIP LIST
Subject: Re: [Sip] Question about ACK for None-200 Response

"Chen, Xin (Xin)" wrote:
> 
> Bis-05 says: "The ACK request MUST NOT contain any Route headers."
> 
> In line 2467, Bis 05 says:  For a stateless proxy receiveing CANCEL and
> non-Routed ACK requests, it  MUST generate the same choice as their
> associated INVITE.
> 
> Bis-05 also says: "The ACK request MUST NOT contain any Route headers."

The section you are referring the above quote from is Section 17.1.1.3,
which talks about an ACK to a non-2xx response to an INVITE.  These ACKs are

hop by hop, and do NOT contain Route headers.  ACKs for 2xx responses to
an INVITE are end to end and their processing is outlined elsewhere in 
-05bis (I am still getting familiar with it -- started the process of "un"-
burning -04bis sections from my brain).  These ACKs can (and indeed MUST if 
some SIP entity R-R'ed) contain a Route.

> I think these two pargraphes are conflicted each other. How can a 
> stateless proxy generate the same choice as the INVITE for a non-Routed 
> ACK if the ACK doesn't have a route header? A INVITE will have a route 
> header which is used by proxy to route the request, but without the route 
> header, when the stateless proxy gets that ACK, it will be very confused 
> about where to forward this.

An INVITE will not always have a Route header; it will only do so if one
of the SIP entities in the signaling path R-R'ed.  The question boils down
to where, in the absence of a Route, does a stateless proxy send an ACK or
CANCEL.  ACK and CANCEL are really pseudo-requests since they depend on 
another transaction, namely INVITE, to do their job.  As such, they should 
be routed to the same host that the original INVITE went to.  A stateless 
proxy can do so by using the modulo N hash of the Call-ID value as the 
uniform random number while weighing the results from a DNS SRV lookup.  See

section 24 in -05 bis; towards the end of the section for more information.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Vijay Gurbani <[email-masked]>
Date: Thu, 01 Nov 2001 09:50:57 -0600

"Chen, Xin (Xin)" wrote:
> 
> Dear Vijay,
> 
> Thanks for your answer.
> 
> Another question: Why the ACK for non-2xx must not have route header? 

Because it is hop by hop.

> What happens if it has?

Nothing drastic, I would presume.  The receiving UAS will stop retxing the
response.  Since the UAS sent a non-2xx response, a route list is never
established.

- vijay

---

From: Lei Liang <[email-masked]>
Date: Thu, 1 Nov 2001 16:17:53 +0000 (GMT)

hi, Vijay,
  so the ACK don't need to have route header but not MUST NOT. Is it
right?
lei

---

From: Vijay Gurbani <[email-masked]>
Date: Thu, 01 Nov 2001 11:12:50 -0600

>   so the ACK don't need to have route header but not MUST NOT. Is it

I am not sure why we're getting so bogged down; the idea is simple, really.
An ACK for a 200 class response needs to be routed independently of where
the INVITE went to; it is a transaction on its own.  

Think of it this way (assume P2 R-R's):

   UAC          P1          P2          UAS
   INV---->
                INV--->
                            INV--->

Now, if the UAS accepts the session, an ACK will flow as follows (since a
Route list is created):

   UAC          P2          UAS
   INV--->
                INV--->

Hence it is important that a Route be there in an ACK to a 200 class 
response.  Note that from UAC's point of view, the ACK did not go to P1 
(like the INVITE did); it went to a different destination (P2).

Now, consider this:

   UAC          P1                       P2
   --->INV
                --->INV
                           <---404 Not Found
                --->ACK
   <--- 404 Not Found
   --->ACK

ACKs here are hop by hop; P1 ACKs P2 and UAC ACKs P1.  First of all, since
the response from P2->P1 (or P1->UAC) was not a 200 class response, no Route
set is ever created.  Secondly, even if a misbehaving P1 inserted a Route
in the ACK towards P2, it does no harm since the ACK going towards P2 is
intended more to stop retransmissions rather than carry end to end 
information.

Hope that helps.

- vijay