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
