> -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 17, 2008 6:45 PM > > AFAIK, the original goal of UALR was to get parameters to applications. > The last time I thought I understood the draft, these were preserved > back somewhere on teh route stack so that the application could get them.
That may have been the intent, but as I read draft-rosenberg-sip-ua-loose-route-01.txt, it doesn't do that if a retarget occurs. In a retargeting case the req-uri is replaced with the new target. In the rerouting case, the req-uri is left alone, and the newly resolved destination URI (for lack of a better term) would be pushed as a Route header. It does, though, say the previous req-uri would be pushed into the History-Info header. It would have been before this draft too, if people implemented it, except with this new draft ONLY retarget cases would push a History-Info. So I guess in that sense you're right, the pre-retargeting data could be there in that. > > > > But in the re-targeting scenario such as: > > RTRG RRT > > +---+ +---+ > > |R1 | |R2 | > > B /+---+\ C E /+---+\ F > > RT / \ RT RT / \ RT > > +---+/ \+---+ D +---+/ \+---+ > > |P1 | |P2 +---+P3 | |P4 | > > A /+---+ +---+ +---+ +---+\ G > > / \ > > +---+/ \+---+ > > |UAC| |UAS| > > +---+ +---+ > > > > UA-Loose-routing wants the req-uri seen on connection "C" I think. > > To header gives you A. > > PCPID gives you E. > > Hist-Info gives you A,B,C,D,E,F. > > As I thought I understood it, UALR gives us the stack of A and C. If R1 and R2 did UALR, the UAS would get the req-uri from C, a History-Info with B, and there'd be a Route header with UAS' contact. -hadriel _______________________________________________ Sip mailing list https://www1.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
