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 <joelrepiquet@xxxxxxxxx> 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
_______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
