[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt
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: marianne.mohali at orange-ftgroup.com
> [mailto:marianne.mohali at orange-ftgroup.com]
> Sent: Thursday, March 19, 2009 9:54 AM
> To: DRAGE, Keith (Keith)
> Cc: sip at ietf.org; mary.barnes at nortel.com; audet at nortel.com
> 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:drage at alcatel-lucent.com]
> Envoyé : mardi 17 mars 2009 00:55 À : MOHALI Marianne
> RD-CORE-ISS; mary.barnes at nortel.com; audet at nortel.com Cc :
> sip at ietf.org 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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of
> > marianne.mohali at orange-ftgroup.com
> > Sent: Monday, March 16, 2009 10:11 PM
> > To: mary.barnes at nortel.com; audet at nortel.com
> > Cc: sip at ietf.org
> > 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
> > sip-implementors at cs.columbia.edu for questions on current sip Use
> > sipping at ietf.org for new developments on the application of sip
> >
>