Subject: RE: [Sip] Replies to ACK

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 18 Dec 2002 11:09:00 -0000

Remember we do not tend to write standards stating what is precluded.

There is an implicit assumption that what is not allowed is precluded. Certainly any equipment claiming conformance to RFC 3261 should list this as an exception, like any other extensions, as it is not explicitly required by RFC 3261.

I would also still question the use. There seems to be little point in responding when as far as I read RFC 3261, any intermediate proxy would kill the incoming response message at the client process, and not pass it up to the transaction layer for further processing. The sort of error detection you are talking about would need to be done by the sender of the ACK, which would be this proxy only for ACK following non 2xx final responses.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> -----Original Message-----
> From: Jiri Kuthan [mailto:[email-masked]]
> Sent: 17 December 2002 17:37
> To: Christer Holmberg; Drage, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [Sip] Replies to ACK
> 
> 
> At 05:56 PM 12/17/2002, Christer Holmberg wrote:
> 
> >Hi,
> >
> >Since the ACK will stop the re-transmission of the final 
> response, if the re-transmissions of the final responses keep 
> coming it does indicate to the UAC that something (even if 
> not exactly what) is wrong.
>                                                               
>      ^^^^^^^^^^^^^^^^^^^^^^^^^
> That's the primary argument, I think, some implementers have 
> decided to send replies
> to ACKs. (However surprising this technique may sound [to me 
> too], I don't see it 
> breaks the spec, except challenges are prohibitted.) An 
> assertation "the r-uri which 
> made it to me is bad" is certainly much more useful than 
> one-bit diagnostic assertation 
> "something is wrong".
> 
> -Jiri 
> 
_______________________________________________
Sip mailing list  https://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