Yes. Isn't the more fundamental design problem that causes this that the Reason is captured on the hi-targeted-to-uri that has been retargeted instead of being associated with the new target signifying how it came into being.
Not sure if adding additional indexes makes things clearer. BTW: If UA4 is from 302, then why does UA3 line on F8 contain reason 480? I would expect it to have no attached reason. /Hans Erik -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, March 19, 2008 10:33 PM To: [email protected] Subject: [Sip] Deficiencies of History-Info I've looking at History-Info (RFC 4244) and I think that as it is currently defined, it has a deficiency in regard to capturing the forking structure of a request. Let us look at an example that parallels the first example of RFC 4244 Appendix A (with non-significant messages omitted): UA1 Proxy1 UA2 UA3 UA4 | | | | | |-INVITE F1->| | | | | | | | | | |--INVITE F2------>| | | | | | | | | |<-302 F4----------| | | | | | | | | |-------INVITE F5 --------->| | | | | | | | |<-------486 F6 ------------| | | | | | | | |------INVITE F8 ------------------->| | | | | | | |<-200 F10 --------------------------| | | | | | | |-- ACK F11------------------------->| |<--200 F12--| | | | | | | | | |--ACK F13-->| | | | | | | | | Assuming that each agent applies History-Info, the History-Info headers will look like this: F1 INVITE UA1 ->Proxy1 History-Info: <sip:[EMAIL PROTECTED]>; index=1 F2 INVITE Proxy1 ->UA2 History-Info: <sip:[EMAIL PROTECTED]>; index=1, <sip:[EMAIL PROTECTED]>; index=1.1 F5 INVITE Proxy1 -> UA3 History-Info: <sip:[EMAIL PROTECTED]>; index=1, <sip:[EMAIL PROTECTED];\ cause=302; text="Moved Temporarily">; index=1.1, <sip:[EMAIL PROTECTED]>;index=1.2 F8 INVITE Proxy1 -> UA4 History-Info: <sip:[EMAIL PROTECTED]>; index=1, <sip:[EMAIL PROTECTED];\ cause=302; text="Moved Temporarily">;index=1.1, <sip:[EMAIL PROTECTED];cause=480;\ text="Temporarily Unavailable" >;index=1.2, <sip:[EMAIL PROTECTED]>;index=1.3 These History-Info headers correctly give the forking structure of the INVITE. The difficulty is that History-Info does not tell us why UA4 was chosen as a target -- It could have been generated by Proxy1 as a target for UA2, or it could have been a Contact in the 302 response F4. As one thinks about call routing, UA4 could be a consequence of [EMAIL PROTECTED], or it could have been a consequence of [EMAIL PROTECTED] which was itself a consequence of [EMAIL PROTECTED] It seems to me that we need a further indicator when a target is added to the target set by a received 3xx response. Let me propose that the indicator be an additional field parameter "redir" whose value is the "index" value of the URI whose 3xx response added the target. In the above example, if both UA3 and UA4 were from the 302 response, F8 would become: F8 INVITE Proxy1 -> UA4 History-Info: <sip:[EMAIL PROTECTED]>; index=1, <sip:[EMAIL PROTECTED];\ cause=302; text="Moved Temporarily">;index=1.1;redir=1, <sip:[EMAIL PROTECTED];cause=480;\ text="Temporarily Unavailable" >;index=1.2;redir=1, <sip:[EMAIL PROTECTED]>;index=1.3 Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
