Subject: [SIP] Proxying ACKs

From: Dvir Oren <[email-masked]>
Date: Thu, 6 Jul 2000 16:54:39 +0300 (IDT)

Section 4.2.2 says that if a proxy receives a final non-success reply, 
it should try and figure out whether it should proxy it or not.
However, the RFC also says that for each final non-success reply, the
first proxy should ACK it.  I can't seem to understand under what
condition should a proxy proxy an ACK request.  I can't think of any
situation where an ACK needs to be proxied for final non-success
replies, since the ACK is always sent hop-by-hop, and not end-to-end.

This brings me to another question.  The RFC says that a proxy should
proxy the following ACKs:
1.  If it cannot find a call-leg that corresponds to this ACK.
2.  If it never sent any replies.

I don't understand why a proxy should proxy ACKs, if it cannot find a
call-leg, or if it seems like its state does not correspond to
receiving an ACK now.

If my proxy also handles QoS, or handles billing, or any other type of 
situation where it will need to maintain call states, then I don't see 
why it should allow such wandering ACKs to travel through it.
Allowing these ACKs will change the state of the proxy, not in the
proper way.

Can anybody clarify this to me?

-- 
Dvir Oren               <[email-masked]>
Lucid VON Ltd.     <http://www.lucidvon.com>
9 Saloniki St.,        Tel-Aviv       Israel
Tel:  +972 3 644 3038  Fax:  +972 3 644 3039

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 6 Jul 2000 15:29:28 +0100

> it should try and figure out whether it should proxy it or not.

Not quite.  It says that if it had _sent_ a definitive, non-2xx,
then it should try and figure out whether it should proxy the ACK
or not.

> first proxy should ACK it.

Yes, that's correct.

> I can't seem to understand under what

In general, it's probably not going to be a frequent occurrence.
It's going to occur when a 200 response arrives very late; that
is, after the proxy had decided that the transaction was completed
(because all branches had completed or timed-out or whatever);
and the requesting UAC routes the ACK back through the proxy
(because of Record-Route: or missing Contact: or whatever).

I'm trying to think if it can happen if a downstream proxy
transitions from stateful to stateless "early".  I don't think
it can if the proxy in question here still has state on the
transaction (I question this because of the indented rationale
in 4.2.2 -- I'm not quite clear on why it's there).

(There are also other cases where the INVITE already contained
a tag in the To header; these are dealt with by section 12.3.5.)

> call-leg, or if it seems like its state does not correspond to

I'm not quite following what you mean by state, here.  A proxy should
probably not rely on ACKs to maintain any sort of transaction state,
since it's not guaranteed to ever see the ACK.  If you're talking
about call-state, I'm not sure that the proxy should start mandating
that UAs are in the same state that it thinks they should be in
(but of course, there's doubtless going to be billing applications
and whathaveyou where such decisions will be required).

In the case I talked about above (the late 200), an ACK could
conceivably arrive after the proxy had dropped all state on the
INVITE.  If the proxy did not try and route in this case, the call
would never properly be set up from the receiving UAS's point-of-view.

I think there's other nasty conditions, such as non-complete Route
headers; probably most of them tend to indicate buggy implementations
somewhere along the path.

> Allowing these ACKs will change the state of the proxy, not in the

Yes, well here is where you potentially get problems.
Once you get into issues where there's money involved, if you pay
the Proxy enough, doubtless it'll be willing to "lose" the ACKs
for you... &:)

HTH,

 - Jo.