Thanks for responding. Unless I'm really misinterpreting section 17.1.1.3, your explanation only confirms why they should have the Route headers (i.e. they are acknowledgments of non-2XX responses). The ACK messages I've called out should be formulated by the client transaction, not the UAC core. The 3rd paragraph of the aforementioned section conveys the MUST level requirement to which I'm referring.
Thanks,
Steve
Alan Johnston wrote:
[EMAIL PROTECTED]"> Hi Steve,
Thanks for your comments on the draft. The current version is actually draft-ietf-sipping-basic-call-flows-00.txt and draft-ietf-sipping-pstn-call-flows-00.txt, as the document has been split.
The ACK messages listed below are correct as they are with no Route header, despite the pre-loaded Route header in the INVITE. This is because they are acknowledgements of non-2xx responses, so they are hop-by-hop instead of end-to-end.
Thanks,
Alan Johnston
WorldCom
sip:[EMAIL PROTECTED]
At 07:47 AM 10/3/2002 -0400, Steve Pellegrino wrote:
Posted this question to sipping a while back with no response...
There appears to be an omission in the draft-ietf-sipping-call-flows-01 document. Per section 17.1.1.3 of RFC 3261, I believe the ACK messages in the following scenarios should contain Route headers from the INVITE response that they are acknowledging:
3.1.2 - F3
3.1.3 - F3, F10
3.2.2 - F11
3.2.3 - F15
3.2.4 - F14
I realize that the document is only informational, but this may be useful info to some implementors :-) .
Kind regards,
Steve
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
