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

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 Feb 2013 17:36:32 -0500

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: [email-masked]
To: [email-masked]
CC: [email-masked]

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-callflows

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-callflows-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 4 Feb 2013 15:53:35 -0500 (EST)

My previous comments have been addressed acceptably.  But there are a
few new nits that I've spotted:

** General

* On page 19

   Alice       example.com     Gold          Silver       Agent

   |              |              |             |            |
   | INVITE F1    |              |             |            |
   |------------->|              |             |            |
   |              |              |             |            |
   |              |  INVITE F2   |             |            |
   |              |------------->|             |            |
   |              |              |             |            |
   |              |  302 Moved Temporarily F3  |            |
   |              |<-------------|             |            |
   |              |              |             |            |
   |             ACK             |             |            |
   |---------------------------->|             |            |
   |              |              |             |            |

The ACK should be shown thus:

   |              |              |             |            |
   |              |  ACK         |             |            |
   |              |------------->|             |            |
   |              |              |             |            |

* On page 27, the top ACK should be shown thus:

   |              |              |             |            |
   |              |  ACK         |             |            |
   |              |------------->|             |            |
   |              |              |             |            |

* On page 31, the top ACK should be shown thus:

   |              |              |             |            |
   |              |  ACK         |             |            |
   |              |------------->|             |            |
   |              |              |             |            |

* On page 40, there are two occurrences of:

   To: <sip:sip:tgruu.7hs==[email-masked]\
    ;gr>

"sip:sip:" should be replaced with "sip:".

** http://www.ietf.org/mail-archive/web/sipcore/current/msg05489.html

* "5. In draft-ietf-sipcore-rfc4244bis-callflows-01, examples 3.6 and 3.7
do not show the History-Info value in the final 200 response to the
UAC.  This final value would be useful, in particular, because they
give further examples of how proxies process History-Info."

In neither of these examples is the final 200 response shown.  I
assume that this is the authors' intention.

** http://www.ietf.org/mail-archive/web/sipcore/current/msg05429.html

* "But in draft-ietf-sipcore-rfc4244bis-callflows-01, Reason header
values for 1xx responses are not generated.  See message F8 in section
3.1."

rfc4244bis-callflows-02 does not show Reason headers with 1xx values.
I expect this is because the authors intend for this to be how
History-Info operates.  But that does mean we are committed to
updating rfc4244bis to state that (because it currently says that 1xx
responses set Reason headers).

Dale

---

From: Brett Tate <[email-masked]>
Date: Sat, 9 Feb 2013 19:50:40 +0000

Howdy,

Most of my comments have been adequately addressed.

Thanks,
Brett

-----

Concerning my various comments to include Max-Forwards, the values are good enough for me; however I was surprised to see some of the decrementing and initial values.  For instance, section 3.1 F5 and F13 contain initial values within ACK reflecting the related INVITE instead of 70.  And for instance, section 3.1 F6 and F9 reflect the proxy decrementing the value again for INVITE sent to new location because of 302 or timeout.

If not intentional, the figure labels are of the format "Figure 1: Figure 1." and not consistently located (i.e. before or after detailed messages).

Section 3.2 F3: top Via received should be on the second via.

Section 3.4 picture: 302 ACK arrow reflection wrong source.  The same applies to sections 3.6 and 3.7.

Concerning http://www.ietf.org/mail-archive/web/sipcore/current/msg05265.html comment 2, section 3.5 was not modified; thus I'll assume that the transport switch from UDP to TCP was intentional (i.e. registered UDP Contact but INVITE sent over TCP).

Section 3.9 F2: Added Max-Forwards to response.

New comment (if want to address): figure 1 indicates a "retransmit INVITE" with arrow after having received a 180.

---

From: <[email-masked]>
Date: Thu, 14 Feb 2013 13:11:36 +0000

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).

MM#2 §3.6 in F6: The History-Info header is
History-Info: <sip:[email-masked]>;index=1 			[MM] ok [/MM]
History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D302>;\
      		   index=1.1;rc=1 				[MM] ok [/MM]
History-Info: <sip:[email-masked]>;index=1.2;mp=1 	[MM] ok [/MM]
History-Info: <sip:[email-masked]?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:[email-masked];\
                     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:[email-masked];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:[email-masked];\
                     target=sip:bob%40example.com>;\
                     index=1.3.1;rc=1.3 				[MM] nok, same comment

But IMO it should be:

History-Info: <sip:[email-masked]>;index=1 
History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D302>;\ 
                     index=1.1;rc=1         
History-Info: <sip:[email-masked]>;index=1.2;mp=1 
History-Info: <sip:[email-masked];cause=480>;\
                     index=1.2.1;rc=1.2 
History-Info: <sip:[email-masked];\
                     target=sip:bob%40example.com;cause=480>;\
                     index=1.3;mp=1
History-Info: <sip:[email-masked];\
                     target=sip:bob%40example.com;cause=480>;\
                     index=1.3.1;rc=1.3

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:[email-masked]?Reason=SIP%3Bcause%3D302\
                         ;text="Moved Temporarily">\
                 ;index=1.1;rc=1

Should be:
History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D302\
                         %3Btext%3D"Moved Temporarily">\
                 ;index=1.1;rc=1

Here is my feedback.

Best Regards,
Marianne

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Paul Kyzivat
Envoyé : vendredi 1 février 2013 23:37
À : [email-masked]; 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 --------

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.

Abstract:

_________________________________________________________________________________________________________________________

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.

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 18 Feb 2013 16:05:55 -0500 (EST)

> From: <[email-masked]>
> Subject: RE: [sipcore] Verify draft-ietf-sipcore-rfc4244bis-callflows-02.txt
> 
> MM#1 B'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).

No, that's to show that the contact <sip:[email-masked]> was
generated by "mapping" from the URI with index 1,
<sip:[email-masked]>.  This is described in 4244bis section 8.
(There are a number of such Contact headers in the callflows.)

> MM#2 B'3.6 in F6: The History-Info header is
> [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]

I believe the cause is supposed to be 408 (Timeout) rather than 480,
and it is correct for the proxy to synthesize a 408 cause here because
of 4244bis section 10.2 paragraph 2.  (And many SIP systems treat
timing out while waiting for a response as if they received an
explicit 408 response.)

This mistake of 480 for 408 is also present in the request-line of F6
and the History-Info of F7.

(Confusion can easily arise because 480 (Temporarily Unavailable) is
also a plausible cause for diversion to VM.)

> [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:[email-masked];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]

Beware that message F6 does not correspond to entry 1.3 but rather to
entry 1.3.1, which is derived from 1.3 by internal redirection.  (It
might be worth adding a note in the text to warn the reader!)  So it
is entry 1.3.1 that must have the cause parameter, to match the
request-URI.

However, since the 1.3.1 request-URI has a cause parameter, it is
likely that 1.3 request-URI has the same cause parameter.

The messier problem is not really present.  There is only one cause at
this point, the implicit 408 response from Carol.  And there may be
complexities concerning what the diversion URI should be, but that is
the proxy's problem, not a problem in designing 4244bis, and we do not
have to solve it here, we only have to show the History-Info that
comes from this particular proxy's decisions.

> [MM] nok, same comment
> MM#3 B'3.7 in F4 and followings: 

The header field as it stands is:

but the escaping is incorrect.  The Reason header would be:

    Reason: SIP;cause=302;text="Moved Temporarily"

so the 'hname' is 'Reason' and the 'hvalue' is
'SIP;cause=302;text="Moved Temporarily"', so the URI should be

<sip:[email-masked]?Reason=SIP%3Bcause%3D302%3Btext%3D%34Moved%20Temporarily%34>

There are 4 instances of this problem, in 3.7 F4, F5, F6, and F7

Dale

---

From: Shida Schubert <[email-masked]>
Date: Tue, 19 Feb 2013 14:16:37 -0800

Hi Marianne;

 Thank you for further comments.. My comments inline..

> 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. 

>                     target=sip:bob%40example.com;cause=480>;\

 Ok. Fixed.

>                         %3Btext%3D"Moved Temporarily">\

 Good catch. Thanks

 Shida

---

From: Shida Schubert <[email-masked]>
Date: Tue, 19 Feb 2013 15:00:58 -0800

Hi Brett;

 Thanks for further comments. 

My comments inline.

> Concerning my various comments to include Max-Forwards, the values are good enough for me; however I was surprised to see some of the decrementing and initial values.  For instance, section 3.1 F5…

My bad. Will fix these. 

> If not intentional, the figure labels are of the format "Figure 1: Figure 1." and not consistently located (i.e. before or after detailed messages).

I will fix these as well. 

> Section 3.2 F3: top Via received should be on the second via.

Thanks for the catch. Done. 

> Section 3.4 picture: 302 ACK arrow reflection wrong source.  The same applies to sections 3.6 and 3.7.

Thanks. Done.

> Concerning http://www.ietf.org/mail-archive/web/sipcore/current/msg05265.html comment 2, section 3.5 was not modified; thus I'll assume that the transport switch from UDP to TCP was intentional (i.…

I must have overlooked this.. Fixed. 

> Section 3.9 F2: Added Max-Forwards to response.

Thanks. Fixed.

Regards
 Shida

---

From: Shida Schubert <[email-masked]>
Date: Tue, 19 Feb 2013 19:26:51 -0800

Hi Dale;

 Thanks for further comments..

>   Alice       example.com     Gold          Silver       Agent

DONE.

> assume that this is the authors' intention.

 This, I think was because the value of h-i would not change from 
the last proxy to UAC, and didn't see a need. If you want to see this 
added. I will add them

> responses set Reason headers).

 Okay, I will add these.

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 20 Feb 2013 10:42:53 -0500 (EST)

> From: Shida Schubert <[email-masked]>

[everything you write is fine with me]

> the last proxy to UAC, and didn't see a need. If you want to see this 

I agree that there is no need.  I believe I was under a
misapprehension when I wrote point 5.

Dale

---

From: <[email-masked]>
Date: Wed, 20 Feb 2013 15:44:56 +0000

Hi Dale,

See my answer inline [MM2]

Marianne

> De : Dale R. Worley [mailto:[email-masked]]
> Envoyé : lundi 18 février 2013 22:06
> À : MOHALI Marianne OLNC/OLN
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Objet : Re: [sipcore] Verify draft-ietf-sipcore-rfc4244bis-callflows-
> 02.txt
> 
> > Subject: RE: [sipcore] Verify
> generated by "mapping" from the URI with index 1, <sip:[email-masked]>.
> This is described in 4244bis section 8.

[MM2] Right, my mistake

> timing out while waiting for a response as if they received an explicit
> 408 response.)
> 

[MM2] No, there is no mistake in the code, the correction were done after one of my comments. Here we are in a Call Deflection immediate response situation (as defined in TS24.604) and the cause URI parameter value to be used and defined in RFC4458 is 480. My point was about the format which is a [Reason header's cause parameter] format instead of the [cause URI parameter] format in the URI.

The line should be:

>From RFC4458
                +---------------------------------+-------+
                | Redirecting Reason              | Value |
                +---------------------------------+-------+
                | Unknown/Not available           | 404   |
                | User busy                       | 486   |
                | No reply                        | 408   |
                | Unconditional                   | 302   |
                | Deflection during alerting      | 487   |
                | Deflection immediate response   | 480   |
                | Mobile subscriber not reachable | 503   |
                +---------------------------------+-------+

> > for not answering the call is lost. [/MM] [MM]If someone have a
> > better/other idea, please don't hesitate... [/MM]
> 
> might be worth adding a note in the text to warn the reader!)  So it is
> entry 1.3.1 that must have the cause parameter, to match the request-
> URI.
> 
> have to solve it here, we only have to show the History-Info that comes
> from this particular proxy's decisions.
> 

[MM2] OK, so the following hi-entry (index=1.3.1) must contain a cause URI parameter set to "cause=408" (removed from the draft-01 version)

> > 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:

[MM2] Exact!

> Dale

[MM2]Marianne

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 20 Feb 2013 15:49:23 -0500 (EST)

The History-Info shown in example 3.6 F6 (of the -02 version) is:

In regard to this example Marianne Mohali has written (and I have

> [MM2] No, there is no mistake in the code, the correction were done
> after one of my comments. Here we are in a Call Deflection immediate
> response situation (as defined in TS24.604) and the cause URI
> parameter value to be used and defined in RFC4458 is 480. My point
> was about the format which is a [Reason header's cause parameter]
> format instead of the [cause URI parameter] format in the URI.
> 
> The line should be:

> [MM2] OK, so the following hi-entry (index=1.3.1) must contain a
> cause URI parameter set to "cause=408" (removed from the draft-01
> version)

As I understand them, the suggestions are:

    The target sip:[email-masked] (index 1.2) is generated from
    sip:[email-masked] by "deflection immediate response", and so that
    URI should be augmented with the parameter cause=480.  I assume that
    parameter is carried into the hi-entry 1.2.1.

(It is not clear to me whether RFC 4458 applies exactly here, since
the deflection is not directly to voicemail but rather to Carol.
However, it seems that the intention of RFC 4458 is to describe how to
mark deflections to targets other than VM as well.  Probably
comparison with PSTN operation is the way to resolve this question.)

    The target sip:[email-masked] (index 1.3) is generated from
    sip:[email-masked] due to timeout of the INVITE to
    sip:[email-masked] (index 1.2.1).  So hi-entry 1.2.1 gets
    "?Reason=SIP%3Bcause%3D408" and hi-entry 1.3 gets a URI parameter
    ";cause=408".  I assume that parameter is carried into the hi-entry
    1.3.1.

If I haven't made any mistakes, the marked changes need to be made:

  History-Info: <sip:[email-masked]>;index=1
  History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D302>;\
                     index=1.1;rc=1
  History-Info: <sip:[email-masked];cause=480>;index=1.2;mp=1
                                      ^^^^^^^^^^
  History-Info: <sip:[email-masked];cause=480?Reason=SIP%3Bcause%3D408>;\
                                    ^^^^^^^^^^                      ^^^
                     index=1.2.1;rc=1.2
  History-Info: <sip:[email-masked];\
                     target=sip:bob%40example.com;\
                                                 ^^
 		     cause=408>;\
                     ^^^^^^^^^
                     index=1.3;mp=1
  History-Info: <sip:[email-masked];\
                     target=sip:bob%40example.com;\
                                                 ^^
 		     cause=408>;\
                     ^^^^^^^^^
                     index=1.3.1;rc=1.3

These changes need to be made to these hi-entries wherever they appear
in the example, except the "Reason=SIP%3Bcause%3D408" for 1.2.1 only
appears in F6 and F7.

Also, in F3, the Contact header becomes:

  Contact: <sip:[email-masked];cause=480>;mp=1

Additionally, the last paragraph of the description of 3.6 seems to
have a damaged sentence:

   Furthermore it is the proxy forwarding the call to VMS that
   determines the target of the voicemail, it is the proxy that sets the
   target of voicemail which is also the entity that utilizes RFC4244bis
   to find the target which is usually based on local policy installed
   by the user or an administrator.

It might be helpful to add this note at F4:

  F4 INVITE Example.com -> Carol

  Because the call was forwarded from Bob to Carol due to "deflection
  immediate response", the URI parameter "cause=480" was added to
  Carol's AOR per [RFC448].  That parameter was carried through to
  Carol's contact URI during internal retargeting.

  INVITE sip:[email-masked] SIP/2.0
  ...

Dale

---

From: <[email-masked]>
Date: Thu, 21 Feb 2013 08:51:54 +0000

Hi Shida,

My answers inline [MM2]

Marianne

> De : Shida Schubert [mailto:[email-masked]]
> Envoyé : mardi 19 février 2013 23:17
> Cc : Paul Kyzivat; [email-masked]; Laura Liess; Brett Tate; Dale R.
> Worley; SIPCORE
> > 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
>  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

> >                     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]
> >                     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:
> 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
> 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]

[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?

> >                         %3Btext%3D"Moved Temporarily">\
[MM2] Once again, check Dale's response to me because remaining " and = seem also wrong. I didn't do the whole escaping.   

> > De : [email-masked] [mailto:[email-masked]] De la
> > part de Paul Kyzivat Envoyé : vendredi 1 février 2013 23:37 À :
> > [email-masked]; Laura Liess; MOHALI Marianne OLNC/OLN; Brett
> > Tate; Dale R. Worley Cc : SIPCORE Objet : [sipcore] Verify
> > 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
> >
> >
> > https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-
> callflo
> > ws
> >
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4244bis-
> callflo
> > ws-02
> >
> >
> ______________________________________________________________________
> > ___________________________________________________
> >
> > 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.
> >

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 22 Feb 2013 15:20:41 +0900

Hi, all.

I'm interested in these drafts, but I'm confused a little.

draft-ietf-sipcore-rfc4244bis-callflows-02.txt Page 34
3.7.  Consumer Voicemail Example

In this scenario, I assume another indexing for last two History-Info headers.

[original]
   F6 INVITE Example.com -> VM

   INVITE sip:[email-masked];target=sip:carol%40example.com SIP/2.0
   Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bKbbg4
   Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK42t2
   Max-Forward: 67
   From: Alice <sip:[email-masked]>;tag=kkaz-
   To: Bob <sip:[email-masked]>
   Supported: histinfo
   Call-Id: [email-masked]
   CSeq: 1 INVITE
   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D302\
                      ;text="Moved Temporarily">;index=1.1;rc=1
   History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D408>;\
                      index=1.2;mp=1
   History-Info: <sip:[email-masked]>;index=1.2.1;rc=1.2
   History-Info: <sip:[email-masked];target=sip:carol%40example.com>;\
                      index=1.3;mp=1.2
   History-Info: <sip:[email-masked];target=sip:carol%40example.com>\
                      ;cause=408;index=1.3.1;rc=1.3
   Contact: Alice <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: <appropriate value>

[my indexing]
   INVITE sip:[email-masked];target=sip:carol%40example.com;cause=408 SIP/2.0
   <snip/>
   History-Info: <sip:[email-masked];target=sip:carol%40example.com;cause=408>;\
                      index=1.2.2;mp=1.2
   History-Info: <sip:[email-masked];target=sip:carol%40example.com;cause=408>\
                      ;index=1.2.2.1;rc=1.2.2

Is my indexing against this specifications?

Regards,
Shinji.

[email-masked]
Tue, 29 Jan 2013 12:49:12 -0800
>	Title           : Session Initiation Protocol (SIP) History-Info Header Call Flow Examples
>	Author(s)       : Mary Barnes
>                          Francois Audet
>                          Shida Schubert

---

From: <[email-masked]>
Date: Tue, 26 Feb 2013 11:16:13 +0100

Hi Paul,
I went through the draft and I'm happy with the status as it is.
So from my side no more open issues and all my comments are covered.

Thank you and Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Paul Kyzivat [mailto:[email-masked]]
> Gesendet: Freitag, 1. Februar 2013 23:37
> An: Jesske, Roland; Laura Liess;
> [email-masked]; Brett Tate; Dale R. Worley
> Cc: SIPCORE
> Betreff: 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 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
>
>

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 26 Feb 2013 22:22:23 -0500 (EST)

> From: OKUMURA Shinji <[email-masked]>

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

I believe that you've found an error.

If the call was sent to *Bob's* voicemail, then the fork to VM would
be a child of the INVITE to sip:[email-masked] (index 1), so the
INVITE to voicemail would have index 1.3.

But in this case, the call was sent to *Carol's* voicemail, it is
(most likely) a child of the INVITE to sip:[email-masked] (index
1.2), and so the INVITE to voicemail would have index 1.2.2.

Dale

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 27 Feb 2013 17:22:48 +0900

Hi, Dale.

Thank you for your response, my comments inline.

[email-masked] (Dale R. Worley)
Tue, 26 Feb 2013 22:22:23 -0500 (EST)
>1.2), and so the INVITE to voicemail would have index 1.2.2.

I don't think the original indexing is an error.

Is a result of indexing unique?

In this case, the Contact of 302 has mp=1.2. The index "1.2" is
created by proxy.example.com. But if the index is "1.2.1.x" that created
by another proxy, what is the new index of the new INVITE?

1.3? 1.2.1.x.1??

And I have an additional question.
If Contact of 302 has no mp parameter, what is an index of the new hi-entry?
and what is a mp parameter of it.

Shinji.