RFC Errata System
2013-06-17 14:51:00 UTC
The following errata report has been submitted for RFC5850,
"A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP)".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5850&eid=3662
--------------------------------------
Type: Editorial
Reported by: Joël Repiquet <***@gmail.com>
Section: 2.5
Original Text
-------------
The multi-party architecture may also need to provide a mechanism to
get information about the status/handling of a dialog (for example,
information about the history of other contacts attempted prior to
the current contact). Finally, the architecture should provide ample
opportunities to present informational URIs that relate to calls,
conversations, or dialogs in some way. For example, consider the SIP
Call-Info header or Contact header fields returned in a 300-class
response. Frequently, additional information about a call or dialog
can be fetched via non-SIP URIs. For example, consider a web page
for package tracking when calling a delivery company or a web page
with related documentation when joining a dial-in conference. The
use of URIs in the multi-party framework is discussed in more detail
in Section 3.7.
Corrected Text
--------------
The multi-party architecture may also need to provide a mechanism to
get information about the status/handling of a dialog (for example,
information about the history of other contacts attempted prior to
the current contact). Finally, the architecture should provide ample
opportunities to present informational URIs that relate to calls,
conversations, or dialogs in some way. For example, consider the SIP
Call-Info header or Contact header fields returned in a 300-class
response. Frequently, additional information about a call or dialog
can be fetched via non-SIP URIs. For example, consider a web page
for package tracking when calling a delivery company or a web page
with related documentation when joining a dial-in conference. The
use of URIs in the multi-party framework is discussed in more detail
in Section 2.7.
Notes
-----
Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.
--------------------------------------
RFC5850 (draft-ietf-sipping-cc-framework-12)
--------------------------------------
Title : A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP)
Publication Date : May 2010
Author(s) : R. Mahy, R. Sparks, J. Rosenberg, D. Petrie, A. Johnston, Ed.
Category : INFORMATIONAL
Source : Session Initiation Proposal Investigation
Area : Real-time Applications and Infrastructure
Stream : IETF
Verifying Party : IESG
"A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP)".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5850&eid=3662
--------------------------------------
Type: Editorial
Reported by: Joël Repiquet <***@gmail.com>
Section: 2.5
Original Text
-------------
The multi-party architecture may also need to provide a mechanism to
get information about the status/handling of a dialog (for example,
information about the history of other contacts attempted prior to
the current contact). Finally, the architecture should provide ample
opportunities to present informational URIs that relate to calls,
conversations, or dialogs in some way. For example, consider the SIP
Call-Info header or Contact header fields returned in a 300-class
response. Frequently, additional information about a call or dialog
can be fetched via non-SIP URIs. For example, consider a web page
for package tracking when calling a delivery company or a web page
with related documentation when joining a dial-in conference. The
use of URIs in the multi-party framework is discussed in more detail
in Section 3.7.
Corrected Text
--------------
The multi-party architecture may also need to provide a mechanism to
get information about the status/handling of a dialog (for example,
information about the history of other contacts attempted prior to
the current contact). Finally, the architecture should provide ample
opportunities to present informational URIs that relate to calls,
conversations, or dialogs in some way. For example, consider the SIP
Call-Info header or Contact header fields returned in a 300-class
response. Frequently, additional information about a call or dialog
can be fetched via non-SIP URIs. For example, consider a web page
for package tracking when calling a delivery company or a web page
with related documentation when joining a dial-in conference. The
use of URIs in the multi-party framework is discussed in more detail
in Section 2.7.
Notes
-----
Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.
--------------------------------------
RFC5850 (draft-ietf-sipping-cc-framework-12)
--------------------------------------
Title : A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP)
Publication Date : May 2010
Author(s) : R. Mahy, R. Sparks, J. Rosenberg, D. Petrie, A. Johnston, Ed.
Category : INFORMATIONAL
Source : Session Initiation Proposal Investigation
Area : Real-time Applications and Infrastructure
Stream : IETF
Verifying Party : IESG