Subject: [sipcore] WGLC draft-ietf-sipcore-rfc4244bis-callflows-01 review Section 3.7

From: <[email-masked]>
Date: Mon, 15 Oct 2012 16:45:17 +0200

Hi,
here is my review of Section 3.7
In addition to Brett's comments I have the following:

1. Within F6/F7 the cause parameter (408) regarding RFC4458 is missing.
The cause parameter is also included within cases where no Response appears. It is the same as for the escaped Reason.
e.G.:
   History-Info: <sip:[email-masked];target=sip:carol%40example.com>; cause=408\
                                index=1.3;mp=1.2
2. F4/F5/F6/F7 the text of Response code is missing e.G. ?Reason=SIP%3Bcause%3D302; text="Moved Temporarily"

3. F6/F7 The Question is if it is implementation depended if the target parameter is put into both entries identifying the Voice Mail. If it is so then some text to point to the fact that this is possible would be nice.

4.F6/F7 Last H-I there is the rc=1.3 missing

   History-Info: <sip:[email-masked];target=sip:carol%40example.com>;\
                       index=1.3.1; rc=1.3

5. Perhaps a hint that End devices don't have to put in an "mp", "rc", "np" would help the reader to differentiate between the different use cases. (3.6 versus 3.7)

I hope I don't miss anything.

Best Regards

Roland

---

From: Shida Schubert <[email-masked]>
Date: Tue, 16 Oct 2012 09:09:56 +0900

Hi Roland;

 Thanks again for your comments.. My comments inline..

>   History-Info: <sip:[email-masked];target=sip:carol%40example.com>; cause=408\

 Great..

> 2. F4/F5/F6/F7 the text of Response code is missing e.G. ?Reason=SIP%3Bcause%3D302; text="Moved Temporarily"

 Thanks. 

> 3. F6/F7 The Question is if it is implementation depended if the target parameter is put into both entries identifying the Voice Mail. If it is so then some text to point to the fact that this is p…

 You mean to mention that adding target parameter is one way to explicitly indicate 
the target URI of the voicemail? (As an optional mechanism to accomplish 
something defined here?) 

>   History-Info: <sip:[email-masked];target=sip:carol%40example.com>;\

 Thanks.

> 5. Perhaps a hint that End devices don't have to put in an "mp", "rc", "np" would help the reader to differentiate between the different use cases. (3.6 versus 3.7)

 What do you mean? 

 Only device that are retargeting or forwarding the request 
would set the "mp", "rc" and "np" So the UE would not 
set these parameters.. Do we need to be more explicit 
about that?

---

From: <[email-masked]>
Date: Tue, 16 Oct 2012 18:17:45 +0200

Hi Shida,

> >
> > 3. F6/F7 The Question is if it is implementation depended
> if the target parameter is put into both entries identifying
> the Voice Mail. If it is so then some text to point to the
> fact that this is possible would be nice.
>
>  You mean to mention that adding target parameter is one way
> to explicitly indicate the target URI of the voicemail? (As
> an optional mechanism to accomplish something defined here?)

My Question is more if this is RFC4458 compliant. I'm not really sure. It look's OK but that is a Application issue of the retargeting in combination with RFC4458.
So question is if both entries (also belongs to the Request URI) are valid with a target parameter or not.

> >
> > 5. Perhaps a hint that End devices don't have to put in an
> "mp", "rc",
> > "np" would help the reader to differentiate between the
> different use
> > cases. (3.6 versus 3.7)
>
>  What do you mean?
>
> would set the "mp", "rc" and "np" So the UE would not set
> these parameters.. Do we need to be more explicit about that?
>

As Brett referred already to RFC3261, that the UE in the 302 case is a UE a Redirect Server. So for 302 the "mp"/"rc" has to be set in other cases not. I Think it would be help to be a little bit more explicit on this.

Best Regards

Roland

---

From: Shida Schubert <[email-masked]>
Date: Wed, 17 Oct 2012 09:46:01 +0900

Hi Roland;

 Many Thanks for your comments, more comments inline.

> So question is if both entries (also belongs to the Request URI) are valid with a target parameter or not.

 Snip from RFC4458 about using it with H-I..

History-Info can complement this specification.  In particular, when
   a proxy inserts a URI containing the parameters defined in this
   specification into the Request-URI of a forwarded request, the proxy
   can also insert a History-Info header field entry into the forwarded
   request, and the URI in that entry will incorporate these parameters.
   Therefore, even if the Request-URI is replaced as a result of
   rerouting by a downstream proxy, the History-Info header field will
   still contain these parameters, which may be of use to the UAS.
   Consequently, UASes that make use of this information may find the
   information in the History-Info header and/or in the Request-URI,
   depending on the capability of the proxy to support generation of
   History-Info or on the behavior of downstream proxies; therefore,
   applications need to take this into account.

> As Brett referred already to RFC3261, that the UE in the 302 case is a UE a Redirect Server. So for 302 the "mp"/"rc" has to be set in other cases not. I Think it would be help to be a little bit m…

 Okay, I see.. I think I know what you are getting at. 

 UE when receiving 302 doesn't set mp or rc at its own decision but the 
Redirect Server when sending a response would set contact with "mp" 
or "rc". UE would then generate a hi-entry using the contact (with mp or rc) 
as it is the R-URI of the outgoing request.   

 The procedure covers this case as it is defined, as far as I know.. But 
do you feel that we need more explanation? 

 Regards
  Shida