Session Initiation Protocol (SIP) History-Info Header Call Flow Examples
Note: This ballot was opened for revision 06 and is now closed.
(Richard Barnes) Yes
(Spencer Dawkins) Yes
Comment (2013-10-04 for -06)
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)
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].