IARI is end to end (either user terminal or application) and is not changed by intermediate call functionality.
Therefore any intermediate application that changes this is essentially making a new call that is not the original call. Think of something like a conference bridge. If you start recording IARI in History-Info, then that would suggest you record all the other headers and bodies that are end to end information. regards Keith > -----Original Message----- > From: [email protected] > [mailto:[email protected]] > Sent: Thursday, March 19, 2009 9:54 AM > To: DRAGE, Keith (Keith) > Cc: [email protected]; [email protected]; [email protected] > Subject: RE: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt > > Hi Keith, > > Let's just talk about IARI. My idea was just to suggest a > trail to improve History-Info. Before to create new things > (headers or parameters), we should look what is available and > reusable. If it is not conceivable to use IARI values in a > History-Info header allowing a proxy server to indicate what > has been done in term of service, could you please give a reason. > > Best Regards, > Marianne > > -----Message d'origine----- > De : DRAGE, Keith (Keith) [mailto:[email protected]] > Envoyé : mardi 17 mars 2009 00:55 À : MOHALI Marianne > RD-CORE-ISS; [email protected]; [email protected] Cc : > [email protected] Objet : RE: [Sip] I-D > Action:draft-barnes-sip-rfc4244bis-00.txt > > You wrote: > > > ** To make the History-Info header usefull for applications and > > services interactions, it could be interesting to be able > to include > > in the hi-target-to-uri IARI and ICSC values as described > in TS 24.229 > > (3GPP) wich ar coded as URN. An example of an ICSI for a > 3GPP defined > > IMS communication service is: > urn:urn-xxx:3gpp-service.ims.icsi.mmtel > > Do you think, this kind of enhancement for Histroy-Info > header could > > be added in the document ? > > Question: What have these values to do with the history of a > retargetting? > > Keith > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > Behalf Of > > [email protected] > > Sent: Monday, March 16, 2009 10:11 PM > > To: [email protected]; [email protected] > > Cc: [email protected] > > Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt > > > > > > Hi Mary and François, > > > > I have a suggestion and few comments on the document. > > > > ** To make the History-Info header usefull for applications and > > services interactions, it could be interesting to be able > to include > > in the hi-target-to-uri IARI and ICSC values as described > in TS 24.229 > > (3GPP) wich ar coded as URN. An example of an ICSI for a > 3GPP defined > > IMS communication service is: > urn:urn-xxx:3gpp-service.ims.icsi.mmtel > > Do you think, this kind of enhancement for Histroy-Info > header could > > be added in the document ? > > > > ** Section 4.1: About Retarget (hi-target), it is indicated "A > > retarget parameter is not added for a hi-entry when it is > first added > > in a History- Info header, but rather is added when the retargeting > > actually occurs". It is indicated when the Retarget > > indication should be added but it could be good to add an > > information on where the parameter should be added > (associated to the > > retargeting hi-targeted-to-uri). This is > > just to be clear on the History-Info header structure. > > I have the same comment for the Reason header escaped in the > > History-Info. About that, there is an inconsistency between > > Reason header associated to the retargeting URI and > > cause-param parameter (RFC4458) associated to the > retargeted-to URI. > > This should be corrected in RFC4458 but I > > don't know if it is possible. > > > > ** Section 4.5.1 and following: in the call flows there is a > > "retarget" parmeter inserted in the second INVITE by Proxy1 when > > sending the request to Proxy2. In my understanding, it > should only be > > added (in the same place) by Proxy2 when retargeting the request to > > Bob. Did I miss something ? > > > > ** Privacy: I also think that it should be recommended in > the document > > to use the Privacy header with the value "history" > > escaped in the hi-entries rather than directly in the > INVITE request. > > > > > > Best Regards, > > Marianne > > _______________________________________________ > > 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
