That sounds reasonable to me. It is a bummer that History-Info is optional...
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of [EMAIL PROTECTED] > Sent: Friday, March 21, 2008 20:28 > To: [email protected] > Subject: [Sip] Further observations about History-Info > > Considering again how History-Info handles 3xx responses, let > me construct this example of multi-stage translation: > > Let us assume that sip:[EMAIL PROTECTED] routes to proxy 1. > Proxy 1 knows that (one) target of this URI is Alice's AOR, > sip:[EMAIL PROTECTED], which then routes to proxy 2. Proxy 2 > knows the phone address for sip:[EMAIL PROTECTED], which is > sip:[EMAIL PROTECTED] > > As the request reaches the UA at 10.1.1.1, the History-Info looks like > this: > > History-Info: <sip:[EMAIL PROTECTED]>;index=1, > <sip:[EMAIL PROTECTED]>;index=1.1, > <sip:[EMAIL PROTECTED]>;index=1.1.1 > > This clearly gives the logical derivation of the destination > address from the original request-URI (which is presumably > also the To: > value): > > sip:[EMAIL PROTECTED] -> > sip:[EMAIL PROTECTED] -> > sip:[EMAIL PROTECTED] > > Now let us modify the scenario by changing proxy 2 not to > route the request itself, but rather to send a 302 response > back to proxy 1. > Within SIP, any agent that potentially routes a request can > choose to send a 3xx response instead; in theory, all forking > can be forced back onto the originating UA if downstream > agents always send 3xx responses rather than routing. > > With the 302 response, the History-Info looks like this > (taking liberties with the escaping): > > History-Info: <sip:[EMAIL PROTECTED]>;index=1, > <sip:[EMAIL PROTECTED];cause=302>;index=1.1, > <sip:[EMAIL PROTECTED]>;index=1.2 > > And this is the forking structure of the request. But it > looses the logical structure of the translation; the UA at > 10.1.1.1 does not see that it received the request "through" > its AOR, sip:[EMAIL PROTECTED] > The apparent derivation of the destination address is: > > sip:[EMAIL PROTECTED] -> > sip:[EMAIL PROTECTED] > > (Although in practice the UA could guess from the "cause=302" on its > ".1 sibling" that its fork was derived from the index=1.1 fork.) > > And in the extreme case of a complex forking and retargeting > structure, if all other agents used 3xx responses to > implement it, the UAS would receive a History-Info whose > indexes were all single integers, obscuring completely how > its address was derived. > > As I proposed earlier, I think getting around this problem > will require adding an additional field-parameter to show how > the address derivations are performed. In this example: > > History-Info: <sip:[EMAIL PROTECTED]>;index=1, > <sip:[EMAIL PROTECTED];cause=302>;index=1.1, > <sip:[EMAIL PROTECTED]>;index=1.2;redir=1.1 > > For diagnostic purposes, it would also be convenient if any > other field-parameters on the Contacts of a 3xx response were > copied into the derived History-Info elements. Only the "q" > parameter seems to be useful information. A typical "serial > fork" would then look like this when the request reached the > second contact: > > History-Info: <sip:[EMAIL PROTECTED]>;index=1, > <sip:[EMAIL PROTECTED];cause=302>;index=1.1, > > <sip:[EMAIL PROTECTED];cause=486>;q=1.0;index=1.2;redir=1.1 > <sip:[EMAIL PROTECTED]>;q=0.9;index=1.3;redir=1.1 > > As an elaboration, if we suppose UA sip:[EMAIL PROTECTED] > redirected the request to sip:[EMAIL PROTECTED], we could get: > > History-Info: <sip:[EMAIL PROTECTED]>;index=1, > <sip:[EMAIL PROTECTED];cause=302>;index=1.1, > > <sip:[EMAIL PROTECTED];cause=486>;q=1.0;index=1.2;redir=1.1 > > <sip:[EMAIL PROTECTED];cause=302>;q=0.9;index=1.3;redir=1.1 > <sip:[EMAIL PROTECTED]>;index=1.4;redir=1.3 > > This illustrates that the forking structure is flat > (arranging the entries by their indexes): > > sip:[EMAIL PROTECTED] > sip:[EMAIL PROTECTED] > sip:[EMAIL PROTECTED] > sip:[EMAIL PROTECTED] > sip:[EMAIL PROTECTED] > > whereas the address derivation is more complex (placing each > entry under the entry referenced by its 'redir' parameter): > > sip:[EMAIL PROTECTED] > sip:[EMAIL PROTECTED] > sip:[EMAIL PROTECTED] > sip:[EMAIL PROTECTED] > sip:[EMAIL PROTECTED] > > The latter is more useful for attacking the "UA loose route" problem. > > We still need to investigate what History-Info looks like if > some of the participating proxies do not support it. > > 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
