Skip to main content

Session Initiation Protocol (SIP) History-Info Header Call Flow Examples
draft-ietf-sipcore-rfc4244bis-callflows-08

Revision differences

Document history

Date Rev. By Action
2014-03-03
08 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-02-10
08 (System) RFC Editor state changed to AUTH48 from EDIT
2014-01-03
08 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent
2014-01-03
08 (System) RFC Editor state changed to EDIT
2014-01-03
08 (System) Announcement was received by RFC Editor
2014-01-02
08 (System) IANA Action state changed to No IC
2014-01-02
08 (System) IANA Action state changed to In Progress
2014-01-02
08 Cindy Morgan State changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed
2014-01-02
08 Cindy Morgan IESG has approved the document
2014-01-02
08 Cindy Morgan Closed "Approve" ballot
2014-01-02
08 Cindy Morgan Ballot approval text was generated
2014-01-02
08 Cindy Morgan Ballot writeup was changed
2013-11-07
08 Shida Schubert New version available: draft-ietf-sipcore-rfc4244bis-callflows-08.txt
2013-10-21
07 Mary Barnes IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2013-10-21
07 Mary Barnes New version available: draft-ietf-sipcore-rfc4244bis-callflows-07.txt
2013-10-17
06 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2013-10-10
06 Cindy Morgan State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2013-10-10
06 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2013-10-10
06 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-10-10
06 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2013-10-09
06 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2013-10-09
06 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2013-10-09
06 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2013-10-09
06 Benoît Claise
[Ballot comment]
Minor editorial point:

OLD:

  The term "retarget" is used as defined in
  [I-D.ietf-sipcore-rfc4244bis].  The terms "location service",
  "redirect" …
[Ballot comment]
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].
2013-10-09
06 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2013-10-08
06 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2013-10-08
06 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2013-10-04
06 Spencer Dawkins
[Ballot comment]
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 …
[Ballot comment]
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?
2013-10-04
06 Spencer Dawkins Ballot comment text updated for Spencer Dawkins
2013-10-04
06 Spencer Dawkins
[Ballot comment]
Thanks for producing this document. Having co-chaired a working group that produced a callflows spec, there's a special place in eternity for people …
[Ballot comment]
Thanks for producing this document. Having co-chaired a working group that produced a callflows spec, there's a special place in eternity for people who do that (and I mean "a lovely special place").

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

I guess the comment on 3.11 is, too, but it's the only one that'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?
2013-10-04
06 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2013-10-04
06 Brian Carpenter Request for Telechat review by GENART Completed: Ready. Reviewer: Brian Carpenter.
2013-10-04
06 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-10-03
06 Jean Mahoney Request for Telechat review by GENART is assigned to Brian Carpenter
2013-10-03
06 Jean Mahoney Request for Telechat review by GENART is assigned to Brian Carpenter
2013-10-02
06 Richard Barnes State changed to IESG Evaluation from Waiting for AD Go-Ahead
2013-10-02
06 Richard Barnes Ballot has been issued
2013-10-02
06 Richard Barnes [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes
2013-10-02
06 Richard Barnes Created "Approve" ballot
2013-09-27
06 (System) State changed to Waiting for AD Go-Ahead from In Last Call (ends 2013-09-27)
2013-09-26
06 Brian Carpenter Request for Last Call review by GENART Completed: Ready. Reviewer: Brian Carpenter.
2013-09-20
06 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2013-09-20
06 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-sipcore-rfc4244bis-callflows-06, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-sipcore-rfc4244bis-callflows-06, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.
2013-09-19
06 Jean Mahoney Request for Last Call review by GENART is assigned to Brian Carpenter
2013-09-19
06 Jean Mahoney Request for Last Call review by GENART is assigned to Brian Carpenter
2013-09-19
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Glen Zorn
2013-09-19
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Glen Zorn
2013-09-13
06 Cindy Morgan IANA Review state changed to IANA - Review Needed
2013-09-13
06 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Session Initiation Protocol (SIP) History-Info …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Session Initiation Protocol (SIP) History-Info Header Call Flow Examples) to Informational RFC


The IESG has received a request from the Session Initiation Protocol Core
WG (sipcore) to consider the following document:
- 'Session Initiation Protocol (SIP) History-Info Header Call Flow
  Examples'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-09-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows/ballot/


No IPR declarations have been submitted directly on this I-D.


2013-09-13
06 Cindy Morgan State changed to In Last Call from Last Call Requested
2013-09-13
06 Richard Barnes Placed on agenda for telechat - 2013-10-10
2013-09-13
06 Richard Barnes Last call was requested
2013-09-13
06 Richard Barnes Ballot approval text was generated
2013-09-13
06 Richard Barnes State changed to Last Call Requested from Publication Requested
2013-09-13
06 Richard Barnes Last call announcement was generated
2013-09-13
06 Richard Barnes Ballot writeup was changed
2013-09-13
06 Richard Barnes Ballot writeup was generated
2013-09-06
06 Cindy Morgan
(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)?

      Informational

    …
(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)?

      Informational

    Why is this the proper type of RFC?

      This document provides non-normative example call flows
      that demonstrate the use of the History-Info header field
      defined in draft-ietf-sipcore-rfc4244bis.

    Is this type of RFC indicated in the title page header?

      Yes

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  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.

Working Group Summary

  There was considerable debate about the placement of
  these call flows: all within the bis draft, all in a separate draft,
  or some in the bis and some in this separate draft. This is largely
  a matter of taste. Ultimately the WG decided that a separate draft
  for all the call flows was preferred.

  It took an exceedingly long time to get this document adequately
  reviewed and to resolve issues with rfc4244bis that the reviews
  resolved. It has been hard to get attention on this because
  rfc4244bis has been considered "done" for a long time by those
  who care.

Document Quality

  Are there existing implementations of the protocol?

    NA. See the writeup for 4244bis.

  Have a significant number of vendors indicated their plan to
  implement the specification?

    NA. See the writeup for 4244bis.

  Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?

    Dale Worley did very heavy lifting reviewing all of
    these call flows, checking all the details. He deserves
    five gold stars.

    Roland Jesske, Laura Liess, and Marianne Mohali
    also did careful reviews that led to fixes.

  If there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

    There is nothing in this document that calls for an
    expert review.

Personnel

  Who is the Document Shepherd?

    Paul Kyzivat

  Who is the Responsible Area Director?

    Richard Barnes

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  I have followed this document throughout its evolution.
  I also did a final read-through while preparing this writeup.
  And I ran IdNits on it. IdNits reports no errors and no warnings.

  It has been a long haul, but I now think the document is
  ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

  It was difficult to get adequate reviews of this document.
  All the examples have been around for years. Most were in
  RFC4244, and were simply evolved based on the changes made
  in rfc4244bis. Finally I held up rfc4244bis until we had a
  thorough review of the call flows. It turned out that the
  call flows in RFC4244 were themselves buggy. And the new
  review identified some issues with rfc4244bis. After some
  extensive discussion the call flows and the bis have been
  reconciled. I am now satisfied with the level of review.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  YES. No IPR has been filed against this draft.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  None filed.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  There are two camps within the WG. One camp considers the
  History-Info header field to be important, while the other
  considers it worthless/silly. There are substantial numbers of
  participants in each camp. The camp in favor includes those with
  a strong interest in 3GPP IMS. The camp with an interest are
  strongly in favor. The other camp has not objected.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No one has indicated extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  None.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  None of these apply to this document.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.
  There are mutual informative references between this document
  and draft-ietf-sipcore-rfc4244bis.

  I just noticed that there is an informative reference to
  draft-ietf-enum-cnam-08, which expired long ago. It isn't
  important, but should probably be removed.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
    existing RFCs?

        No.

    Are those RFCs listed on the title page header, listed
    in the abstract, and discussed in the introduction?

        N/A

    If the RFCs are not
    listed in the Abstract and Introduction, explain why, and point to the
    part of the document where the relationship of this document to the
    other RFCs is discussed. If this information is not in the document,
    explain why the WG considers it unnecessary.

        N/A

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  There are no IANA considerations, and that is appropriate.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None
2013-09-06
06 Cindy Morgan Intended Status changed to Informational
2013-09-06
06 Cindy Morgan IESG process started in state Publication Requested
2013-09-06
06 (System) Earlier history may be found in the Comment Log for /doc/draft-barnes-sipcore-rfc4244bis-callflows/
2013-09-05
06 Paul Kyzivat IETF WG state changed to Submitted to IESG for Publication from WG Document
2013-09-05
06 Paul Kyzivat Document shepherd changed to Paul Kyzivat
2013-09-05
06 Paul Kyzivat Changed document writeup
2013-09-05
06 Paul Kyzivat Changed document writeup
2013-07-15
06 Shida Schubert New version available: draft-ietf-sipcore-rfc4244bis-callflows-06.txt
2013-07-11
05 Shida Schubert New version available: draft-ietf-sipcore-rfc4244bis-callflows-05.txt
2013-07-08
04 Shida Schubert New version available: draft-ietf-sipcore-rfc4244bis-callflows-04.txt
2013-03-19
03 Stephanie McCammon New version available: draft-ietf-sipcore-rfc4244bis-callflows-03.txt
2013-01-29
02 Shida Schubert New version available: draft-ietf-sipcore-rfc4244bis-callflows-02.txt
2012-09-20
01 Shida Schubert New version available: draft-ietf-sipcore-rfc4244bis-callflows-01.txt
2012-09-11
00 Hans van Elburg New version available: draft-ietf-sipcore-rfc4244bis-callflows-00.txt