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
