Session Initiation Protocol (SIP) History-Info Header Call Flow Examples
RFC 7131

Note: This ballot was opened for revision 06 and is now closed.

(Richard Barnes) Yes

(Spencer Dawkins) Yes

Comment (2013-10-04 for -06)
No email
send info
Thanks for producing this document. Having co-chaired a RAI working group that produced a callflows spec, I know they don't just fall out of your laptop and roll across the floor - they're a lot of work..

I have a small number of comments. Most are editorial. 

I guess the comment on 3.11 is, too, but it's beyond a nit. Please look it over and see if my suggestion would improve it. I'm happy to help if that's needed.

Why does one occurence of "Home" have asterisks around it ("*Home*)?

I salute the authors for the use of "blah, blah, blah..." in an RFC, when approved :-)

There are two instances of this text:

   Note that some VMSs may also (or instead) use the
   information available in the History-Info headers for custom handling
   of the VM in terms of how and why the call arrived at the VMS.
             ^^^^^^^^^^^

"in terms of" wasn't clear to me. I might sugget "based on".

In Section 3.6.  PBX Voicemail Example, there's one instance of rfc4244bis used as a reference that's not bracketed (all the other instances are). The RFC Editor will almost certainly find it to replace it with an RFC number, but if it matched all the others, that might help them.

In Section 3.10, "to invocate a service" might be more easily understood if it were "to invoke a service".

The shepherd writeup recommended removing a reference to ietf-enum-cnam which expired in 2009. I'm just mentioning that, too.

In 3.11.  Toll Free Number

   Once such a translation has been performed, the call needs to be
   routed towards the target of the request.  Normally, this would
                                              ^^^^^^^^
   happen by selecting a PSTN gateway which is a good route towards the
                       ^^^^^^^^^^^^^^
   translated number.  However, one can imagine all-IP systems where the
                       ^^^^^^^                  ^^^^^^
   8xx numbers are SIP endpoints on an IP network, in which case the
   translation of the 8xx number would actually be a SIP URI and not a
   phone number.  Assuming for the moment it is a PSTN connected entity,
                  ^^^^^^^^^^^^^^^^^^^^^^^       ^^^^^^^^^^^^^^^^^^^^^^^
   the call would be routed towards a PSTN gateway.  Proper treatment of
   the call in the PSTN (and in particular, correct reconciliation of
   billing records) requires that the call be marked with both the
   original 8xx number AND the target number for the call.  However, in
                                                            ^^^^^^^
   our example here, since the translation was performed by a SIP proxy
                                                            ^^^^^^^^^^^
   upstream from the gateway, the original 8xx number would have been
   lost, and the call will not interwork properly with the PSTN.
   History-info would come in play here to assure original 8xx number is
   not lost.

   Furthermore, even if the translation of the 8xx number was a SIP URI,
   ^^^^^^^^^^^^^^^^^^^^
   the enterprise or user who utilize the 8xx service would like to know
   whether the call came in via 8xx number in order to treat the call
   differently (for example to play a special announcement..) but if the
   original R-URI is lost through translation, there is no way to tell
   if the call came in via 8xx number.

I understood every sentence in this text, but flipping back and forth between PTSN gateways and all-IP systems made the paragraphs difficult to follow. Any chance that this could be split into a PSTN case and an all-IP case, with only one transition?

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-10-09 for -06)
No email
send info
Minor editorial point:

OLD:

   The term "retarget" is used as defined in
   [I-D.ietf-sipcore-rfc4244bis].  The terms "location service",
   "redirect" and "AOR" are used consistent with the terminology in
   [RFC3261].

NEW:

   The term "retarget" is used as defined in
   [I-D.ietf-sipcore-rfc4244bis].  The terms "location service",
   "redirect" and "address-of-record (AOR)" are used consistent with 
   the terminology in [RFC3261].

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

Barry Leiba No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection