Re: [sipcore] Verify draft-ietf-sipcore-rfc4244bis-callflows-02.txt

[<[e-mail]>]

Hi Shida,

My answers inline [MM2]

Marianne

> -----Message d'origine-----
> De : Shida Schubert [mailto:[e-mail]]
> Envoyé : mardi 19 février 2013 23:17
> À : MOHALI Marianne OLNC/OLN
> Cc : Paul Kyzivat; [e-mail]; Laura Liess; Brett Tate; Dale R.
> Worley; SIPCORE
> Objet : Re: [sipcore] Verify draft-ietf-sipcore-rfc4244bis-callflows-
> 02.txt
> 
> 
> Hi Marianne;
> 
>  Thank you for further comments.. My comments inline..
> 
> On Feb 14, 2013, at 5:11 AM, <[e-mail]>
> <[e-mail]> wrote:
> 
> > Hello,
> >
> > Most of my comments have been perfectly addressed but I have still
> some concerns with the following changes:
> >
> > MM#1 §3.6 in F3: there is an "mp" tag in a Contact header; I guess
> it's a mistake and it should be a History-Info header (as in F4).
> 
>  This is intentional. Per section  4.2.1 of RFC 4244bis regarding
> Redirect Server behavior, redirect server would indicate the method a
> redirect-to contact was determined.
> 
[MM2] ok, understood




> >
> > MM#2 §3.6 in F6: The History-Info header is
> > History-Info: <sip:[e-mail]>;index=1 			[MM] ok [/MM]
> > History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302>;\
> >      		   index=1.1;rc=1 				[MM] ok [/MM]
> > History-Info: <sip:[e-mail]>;index=1.2;mp=1 	[MM] ok [/MM]
> > History-Info: <sip:carol@192.0.2.4?Reason=SIP%3Bcause%3D480>;\
> >                     index=1.2.1;rc=1.2 				[MM]
> nok, it is a cause URI parameter that should be set to "480" (call
> deflection) following RFC4458. The Reason header is escaped in the SIP
> URI only when it is a real received respond (it is the case with the
> 302) [/MM]
> > History-Info: <sip:[e-mail];\
> >                     target=sip:bob%40example.com>;\
> >                     index=1.3;mp=1 				[MM] nok,
> The hi-entry with the voicemail should be a copy of the R-URI so with
> the cause=480 URI parameter. Additionally, the vm is finally reached
> because Carol does not reply, so the no reply reason (cause=408) should
> also be reflected in a cause URI parameter following RFC4458. Hence,
> the hi-entry should be History-Info:
> <sip:[e-mail];target=sip:bob%40example.com;cause=480;cause=408>;
> index=1.3;mp=1  => Oops, I think we have a problem... This is due to
> the fact that at the same time we have successive forwarding (1 after
> the other) with Carol at the second-to-last position and we try to join
> B's vm (1st diverting user). IMO, we should add some text stating that
> depending on which voicemail is reached (Bob or Carol), the call
> forwarding reason (Bob or Carol's diverting reason) in the cause URI
> parameter should be set accordingly (to be consistent). Here the target
> vm is Bob so only cause=480 should be used and Carol's reason for not
> answering the call is lost. [/MM]
> > [MM]If someone have a better/other idea, please don't hesitate...
> > [/MM]
> > History-Info: <sip:vm@192.0.2.6;\
> >                     target=sip:bob%40example.com>;\
> >                     index=1.3.1;rc=1.3 				[MM]
> nok, same comment
> >
> > But IMO it should be:
> >
> > History-Info: <sip:[e-mail]>;index=1
> > History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302>;\
> >                     index=1.1;rc=1
> > History-Info: <sip:[e-mail]>;index=1.2;mp=1
> > History-Info: <sip:carol@192.0.2.4;cause=480>;\
> >                     index=1.2.1;rc=1.2
> > History-Info: <sip:[e-mail];\
> >                     target=sip:bob%40example.com;cause=480>;\
> >                     index=1.3;mp=1
> > History-Info: <sip:vm@192.0.2.6;\
> >                     target=sip:bob%40example.com;cause=480>;\
> >                     index=1.3.1;rc=1.3
> 
>  Ok. Fixed.
> 

[MM2] After discussion with Dale, I'm not sure for the last hi-entry reason value if it should be 408 (for the no reply from Carol) or 480 (for the initial call deflection from bob). Indeed, in this last proposal, we lose the no reply reason from Carol so set 408 could give this information but on the other hand because there is mp=1 in the second-to-last hi-entry refering to bob whom reason is 480... 
Finally, I think 480 is correct and the 2-last reasons should be 408 (no reply) only if mp was=1.2. Do you agree?



> >
> > MM#3 §3.7 in F4 and followings:
> > In the hi-entry the reason-text has been added.
> > I have 2 comments:
> > 1. why adding the reason-text? (and why not ;)=> ok for me 2. if the
> > reason-text is added, it should be "escaped" in the same way as the
> cause parameter.
> > So that, the hi-entry:
> > History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302\
> >                         ;text="Moved Temporarily">\
> >                 ;index=1.1;rc=1
> >
> > Should be:
> > History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302\
> >                         %3Btext%3D"Moved Temporarily">\
> >                 ;index=1.1;rc=1
> 
>  Good catch. Thanks
[MM2] Once again, check Dale's response to me because remaining " and = seem also wrong. I didn't do the whole escaping.   




> 
>  Shida
> 
> >
> > Here is my feedback.
> >
> > Best Regards,
> > Marianne
> >
> > -----Message d'origine-----
> > De : [e-mail] [mailto:[e-mail]] De la
> > part de Paul Kyzivat Envoyé : vendredi 1 février 2013 23:37 À :
> > [e-mail]; Laura Liess; MOHALI Marianne OLNC/OLN; Brett
> > Tate; Dale R. Worley Cc : SIPCORE Objet : [sipcore] Verify
> > draft-ietf-sipcore-rfc4244bis-callflows-02.txt
> >
> > A new version of 4244bis-callflows has been published, to address the
> comments we received in the WGLC review at the end of last year.
> >
> > I've sent this *To* the people who provided comments.
> > I would appreciate your verifying that your comments were properly
> > addressed. (Please comment back one way or the other.)
> >
> > This is *not* a new WGLC. So please don't bring up *new* issues now.
> We are past that. I just want to verify that the comments already
> raised have been handled. We are holding the bis to publish
> concurrently with the callflows, so is the last thing holding them up.
> >
> > 	Thanks,
> > 	Paul
> >
> >
> > -------- Original Message --------
> > Subject: [sipcore] I-D Action:
> > draft-ietf-sipcore-rfc4244bis-callflows-02.txt
> > Date: Tue, 29 Jan 2013 12:49:12 -0800
> > From: [e-mail]
> > To: [e-mail]
> > CC: [e-mail]
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >  This draft is a work item of the Session Initiation Protocol Core
> Working Group of the IETF.
> >
> > 	Title           : Session Initiation Protocol (SIP) History-Info
> Header
> > Call Flow Examples
> > 	Author(s)       : Mary Barnes
> >                           Francois Audet
> >                           Shida Schubert
> >                           Detecon International Gmbh
> >                           Christer Holmberg
> > 	Filename        : draft-ietf-sipcore-rfc4244bis-callflows-02.txt
> > 	Pages           : 46
> > 	Date            : 2013-01-29
> >
> > Abstract:
> >    This document describes use cases and documents call flows which
> >    require the History-Info header field to capture the Request-URIs
> as
> >    a Session Initiation Protocol (SIP) Request is retargeted.  The
> use
> >    cases are described along with the corresponding call flow
> diagrams
> >    and messaging details.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-
> callflo
> > ws
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-02
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4244bis-
> callflo
> > ws-02
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
> >
> >
> >
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> que les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, France Telecom - Orange decline toute responsabilite si
> ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender
> and delete this message and its attachments.
> > As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.
> > Thank you.
> >
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.