draft-ietf-speermint-requirements-09.txt   draft-ietf-speermint-requirements-10.txt 
SPEERMINT Working Group J-F. Mule SPEERMINT Working Group J-F. Mule
Internet-Draft CableLabs Internet-Draft CableLabs
Intended status: Informational October 26, 2009 Intended status: Informational October 25, 2010
Expires: April 29, 2010 Expires: April 28, 2011
SPEERMINT Requirements for SIP-based Session Peering Requirements for SIP-based Session Peering
draft-ietf-speermint-requirements-09.txt draft-ietf-speermint-requirements-10.txt
Abstract
This memo captures protocol requirements to enable session peering of
voice, presence, instant messaging and other types of multimedia
traffic. This informational document is intended to link the various
use cases described for session peering to protocol solutions.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on April 28, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This memo captures protocol requirements to enable session peering of described in the Simplified BSD License.
voice, presence, instant messaging and other types of multimedia
traffic. It is based on the use cases that have been described in
the SPEERMINT working group. This informational document is intended
to link the session peering use cases to protocol solutions.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General Requirements . . . . . . . . . . . . . . . . . . . . . 5 3. General Requirements . . . . . . . . . . . . . . . . . . . . . 5
3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Border Elements . . . . . . . . . . . . . . . . . . . . . 5 3.2. Border Elements . . . . . . . . . . . . . . . . . . . . . 5
3.3. Session Establishment Data . . . . . . . . . . . . . . . . 9 3.3. Session Establishment Data . . . . . . . . . . . . . . . . 9
3.3.1. User Identities and SIP URIs . . . . . . . . . . . . . 9 3.3.1. User Identities and SIP URIs . . . . . . . . . . . . . 9
skipping to change at page 3, line 38 skipping to change at page 3, line 38
This document first describes general requirements. The use cases This document first describes general requirements. The use cases
are then analyzed in the spirit of extracting relevant protocol are then analyzed in the spirit of extracting relevant protocol
requirements that must be met to accomplish the use cases. These requirements that must be met to accomplish the use cases. These
requirements are intended to be independent of the type of media requirements are intended to be independent of the type of media
exchanged such as Voice over IP (VoIP), video telephony, and instant exchanged such as Voice over IP (VoIP), video telephony, and instant
messaging. Requirements specific to presence and instant messaging messaging. Requirements specific to presence and instant messaging
are defined in Section 4. are defined in Section 4.
It is not the goal of this document to mandate any particular use of It is not the goal of this document to mandate any particular use of
IETF protocols by SIP Service Providers in order to establish session IETF protocols other than SIP by SIP Service Providers in order to
peering. Instead, the document highlights what requirements should establish session peering. Instead, the document highlights what
be met and what protocols may be used to define the solution space. requirements should be met and what protocols might be used to define
the solution space.
Finally, we conclude with a list of parameters for the definition of Finally, we conclude with a list of parameters for the definition of
a session peering policy, provided in an informative appendix. It a session peering policy, provided in an informative appendix. It
should be considered as an example of the information SIP Service should be considered as an example of the information SIP Service
Providers may have to discuss or agree on to exchange SIP traffic. Providers may have to discuss or agree on to exchange SIP traffic.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 11, line 8 skipping to change at page 11, line 8
incur minimal overhead and delay, and employ caching wherever incur minimal overhead and delay, and employ caching wherever
possible to avoid extra protocol round trips. possible to avoid extra protocol round trips.
o Requirement #9: o Requirement #9:
The mechanisms for session peering MUST allow an SBE to locate its The mechanisms for session peering MUST allow an SBE to locate its
peer SBE given a URI type and the target SSP domain name. peer SBE given a URI type and the target SSP domain name.
4. Requirements for Session Peering of Presence and Instant Messaging 4. Requirements for Session Peering of Presence and Instant Messaging
This section describes requirements for presence and instant This section describes requirements for presence and instant
messaging session peering. Several use cases for presence and messaging session peering.
instant messaging peering are described in [RFC5344], a document
authored by A. Houri, E. Aoki and S. Parameswar. Credits for the Two SSPs create a peering relationship to enable their IM and
original content captured in this section must go to them. presence users to collaborate with users on the other SSP network.
We focus the requirements on inter-domain subscriptions to presence
information, the exchange of messages and privacy settings and the
use of standard presence document formats across domains.
Several use cases for presence and instant messaging peering are
described in [RFC5344], a document authored by A. Houri, E. Aoki and
S. Parameswar. Credits for the original content captured from these
use cases into requirements in this section must go to them.
o Requirement #10: o Requirement #10:
The mechanisms recommended for the exchange of presence The mechanisms recommended for the exchange of presence
information between SSPs SHOULD allow a user of one presence information between SSPs SHOULD allow a user of one presence
community to send a presence subscription request to presentities community to send a presence subscription request to presentities
served by another SSP via its local community, including served by another SSP via its local community, including
subscriptions to a single presentity, a personal, public or ad-hoc subscriptions to a single presentity, a personal, public or ad-hoc
group list of presentities. group list of presentities.
Notes: see section 2.2 of [RFC5344]. Notes: see sections 2.1 and 2.2 of [RFC5344].
o Requirement #11: o Requirement #11:
The mechanisms recommended for Instant Messaging exchanges between The mechanisms recommended for Instant Messaging exchanges between
SSPs SHOULD allow a user of one SSP's community to communicate SSPs SHOULD allow a user of one SSP's community to communicate
with users of the other SSP community via their local community with users of the other SSP community via their local community
using the various methods. Note that some SSPs may exercise some using the various methods. Note that some SSPs may exercise some
control over which methods are allowed based on service policies. control over which methods are allowed based on service policies.
Such methods include sending a one-time IM message, initiating a Such methods include sending a one-time IM message, initiating a
SIP session for transporting sessions of messages, participating SIP session for transporting sessions of messages, participating
in n-way chats using chat rooms with users from the peer SSPs, in n-way chats using chat rooms with users from the peer SSPs,
etc. etc.
Notes: see section 2.6 of [RFC5344]. Notes: see sections 2.4, 2.5 and 2.6 of [RFC5344].
o Requirement #12: Privacy Sharing o Requirement #12: Privacy Sharing
In some presence communities, users can define the list of In some presence communities, users can define the list of
watchers that receive presence notifications for a given watchers that receive presence notifications for a given
presentity. Such privacy settings for watcher notifications per presentity. Such privacy settings for watcher notifications per
presentity are typically not shared across SSPs causing multiple presentity are typically not shared across SSPs causing multiple
notifications to be sent for one presentity change between SSPs. notifications to be sent for one presentity change between SSPs.
The sharing of those privacy settings per presentity between SSPs The sharing of those privacy settings per presentity between SSPs
would allow fewer notifications: a single notification would be would allow fewer notifications: a single notification would be
sent per presentity and the terminating SSP would send sent per presentity and the terminating SSP would send
notifications to the appropriate watchers according to the notifications to the appropriate watchers according to the
presentity's privacy information. presentity's privacy information.
The mechanisms recommended for Presence information exchanges The mechanisms recommended for Presence information exchanges
between SSPs SHOULD allow the sharing of some user privacy between SSPs SHOULD allow the sharing of some user privacy
settings in order for users to convey the list of watchers that settings in order for users to convey the list of watchers that
can receive notification of presence information changes on a per can receive notification of presence information changes on a per
presentity basis. presentity basis.
The privacy sharing mechanism must be done with the express The privacy sharing mechanism must be done with the express
consent of the user whose privacy settings will be shared with to consent of the user whose privacy settings will be shared with the
the other community. Because of the privacy-sensitive information other community. Because of the privacy-sensitive information
exchanged between SSPs, the protocols used for the exchange of exchanged between SSPs, the protocols used for the exchange of
presence information must follow the security recommendations presence information must follow the security recommendations
defined in section 6 of [RFC3863]. defined in section 6 of [RFC3863].
Notes: see section 2.3 of [RFC5344]. Notes: see section 2.3 of [RFC5344].
o Requirement #13: Multiple Watchers o Requirement #13: Multiple Watchers
It should be possible to send a presence document with a list of It should be possible to send a presence document with a list of
watchers on the other community that should receive the presence watchers on the other community that should receive the presence
document notification. This will enable sending less presence document notification. This will enable sending less presence
document notifications between the communities while avoiding the document notifications between the communities while avoiding the
need to share privacy information of presentities from one need to share privacy information of presentities from one
community to the other. community to the other.
The systems used to exchange presence documents between SSPs The systems used to exchange presence documents between SSPs
SHOULD allow more than one watchers to be passed with a presence SHOULD allow a presence document to be delivered to one or more
document. watchers.
Note: The privacy sharing mechanisms defined in Requirement #12
also apply to this requirement.
o Requirement #14: Standard PIDF Documents and Mappings o Requirement #14: Standard PIDF Documents and Mappings
Early deployments of SIP-based presence and Instant Messaging Early deployments of SIP-based presence and Instant Messaging
gateways have been done in front of legacy proprietary systems gateways have been done in front of legacy proprietary systems
that use different naming schemes or name values for the elements that use different naming schemes or name values for the elements
and properties defined in a Presence Information Data Format and properties defined in a Presence Information Data Format
(PIDF) document ([RFC3863]). For example the value "Do Not (PIDF) document ([RFC3863]). For example the value "Do Not
Disturb" in one presence service may be mapped to "Busy" in Disturb" in one presence service may be mapped to "Busy" in
another system for the status element. Beyond this example of another system for the status element. Beyond this example of
status values, it is important to ensure that the meaning of the status values, it is important to ensure that the meaning of the
skipping to change at page 13, line 22 skipping to change at page 13, line 22
Functions (LUF and LRF), the SIP signaling between SIP Service Functions (LUF and LRF), the SIP signaling between SIP Service
Providers, and the associated media exchanges. Providers, and the associated media exchanges.
This section is focused on three security services, authentication, This section is focused on three security services, authentication,
data confidentiality and data integrity as summarized in [RFC3365]. data confidentiality and data integrity as summarized in [RFC3365].
However, this text does not specify the mandatory-to-implement However, this text does not specify the mandatory-to-implement
security mechanisms as required by [RFC3365]; this is left for future security mechanisms as required by [RFC3365]; this is left for future
protocol solutions that meet the requirements. protocol solutions that meet the requirements.
A security threat analysis provides additional guidance for session A security threat analysis provides additional guidance for session
peering ([I-D.niccolini-speermint-voipthreats]). peering ([I-D.ietf-speermint-voipthreats]).
5.1. Security Properties for the Acquisition of Session Establishment 5.1. Security Properties for the Acquisition of Session Establishment
Data Data
The Look-Up Function (LUF) and Location Routing Function (LRF) are The Look-Up Function (LUF) and Location Routing Function (LRF) are
defined in [RFC5486]. They provide mechanisms for determining the defined in [RFC5486]. They provide mechanisms for determining the
SIP target address and domain the request should be sent to, and the SIP target address and domain the request should be sent to, and the
associated SED to route the request to that domain. associated SED to route the request to that domain.
o Requirement #15: o Requirement #15:
skipping to change at page 14, line 46 skipping to change at page 14, line 46
as they may prevent intermediary SSPs from "inserting" SBEs/DBEs as they may prevent intermediary SSPs from "inserting" SBEs/DBEs
along the signaling and data paths. along the signaling and data paths.
o providing an Authentication Service to authenticate the identity o providing an Authentication Service to authenticate the identity
of connected users based on the SIP Service Provider domains (for of connected users based on the SIP Service Provider domains (for
both the SIP requests and the responses). both the SIP requests and the responses).
The fundamental mechanisms for securing SIP between proxy servers The fundamental mechanisms for securing SIP between proxy servers
intra- and inter-domain are applicable to session peering; refer to intra- and inter-domain are applicable to session peering; refer to
Section 26.2 of [RFC3261] for transport-layer security of SIP Section 26.2 of [RFC3261] for transport-layer security of SIP
messages using TLS, [I-D.ietf-sip-connect-reuse] for establishing TLS messages using TLS, [RFC5923] for establishing TLS connections
connections between proxies, [RFC4474] for the protocol mechanisms to between proxies, [RFC4474] for the protocol mechanisms to verify the
verify the identity of the senders of SIP requests in an inter-domain identity of the senders of SIP requests in an inter-domain context,
context, and [RFC4916] for verifying the identity of the sender of and [RFC4916] for verifying the identity of the sender of SIP
SIP responses). responses).
5.3. End-to-End Media Security 5.3. End-to-End Media Security
Media security is critical to guarantee end-to-end confidentiality of Media security is critical to guarantee end-to-end confidentiality of
the communication between the end-users' devices, independently of the communication between the end-users' devices, independently of
how many direct or indirect peers are present along the signaling how many direct or indirect peers are present along the signaling
path. A number of desirable security properties emerge from this path. A number of desirable security properties emerge from this
goal. goal.
The establishment of media security may be achieved along the media The establishment of media security may be achieved along the media
path and not over the signaling path given the indirect peering use path and not over the signaling path given the indirect peering use
cases. cases.
For example, media carried over the Real-Time Protocol (RTP) can be For example, media carried over the Real-Time Protocol (RTP) can be
secured using secure RTP (SRTP [RFC3711]). A framework for secured using secure RTP (SRTP [RFC3711]). A framework for
establishing SRTP security using Datagram TLS [RFC4347] is described establishing SRTP security using Datagram TLS [RFC4347] is described
in [I-D.ietf-sip-dtls-srtp-framework]: it allows for end-to-end media in [RFC5763]: it allows for end-to-end media security establishment
security establishment using extensions to DTLS using extensions to DTLS ([RFC5764]).
([I-D.ietf-avt-dtls-srtp]).
It should also be noted that media can be carried in numerous It should also be noted that media can be carried in numerous
protocols other than RTP such as SIP (SIP MESSAGE method), MSRP (the protocols other than RTP such as SIP (SIP MESSAGE method), MSRP (the
Message Session Relay Protocol, [RFC4975], XMPP (the Extensible Message Session Relay Protocol, [RFC4975], XMPP (the Extensible
Messaging and Presence Protocol, [RFC3920]) and many others. Media Messaging and Presence Protocol, [RFC3920]) and many others. Media
may also be carried over TCP ([RFC4571]), and it can be encrypted may also be carried over TCP ([RFC4571]), and it can be encrypted
over secure connection-oriented transport sessions over TLS over secure connection-oriented transport sessions over TLS
([RFC4572]). ([RFC4572]).
A desirable security property for session peering is for SIP entities A desirable security property for session peering is for SIP entities
to be transparent to the end-to-end media security negotiations: SIP to be transparent to the end-to-end media security negotiations: SIP
skipping to change at page 18, line 14 skipping to change at page 18, line 14
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 8.2. Informative References
[I-D.ietf-avt-dtls-srtp]
McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for Secure
Real-time Transport Protocol (SRTP)",
draft-ietf-avt-dtls-srtp-07 (work in progress),
February 2009.
[I-D.ietf-pmol-sip-perf-metrics] [I-D.ietf-pmol-sip-perf-metrics]
Malas, D. and A. Morton, "SIP End-to-End Performance Malas, D. and A. Morton, "Basic Telephony SIP End-to-End
Metrics", draft-ietf-pmol-sip-perf-metrics-04 (work in Performance Metrics", draft-ietf-pmol-sip-perf-metrics-07
progress), September 2009. (work in progress), September 2010.
[I-D.ietf-sip-connect-reuse]
Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in
the Session Initiation Protocol (SIP)",
draft-ietf-sip-connect-reuse-14 (work in progress),
August 2009.
[I-D.ietf-sip-dtls-srtp-framework]
Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing an SRTP Security Context using DTLS",
draft-ietf-sip-dtls-srtp-framework-07 (work in progress),
March 2009.
[I-D.ietf-speermint-architecture] [I-D.ietf-speermint-architecture]
Penno, R. and S. Khan, "SPEERMINT Peering Architecture", Malas, D. and J. Livingood, "SPEERMINT Peering
draft-ietf-speermint-architecture-08 (work in progress), Architecture", draft-ietf-speermint-architecture-12 (work
March 2009. in progress), October 2010.
[I-D.ietf-speermint-voip-consolidated-usecases] [I-D.ietf-speermint-voip-consolidated-usecases]
Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases", Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases",
draft-ietf-speermint-voip-consolidated-usecases-14 (work draft-ietf-speermint-voip-consolidated-usecases-18 (work
in progress), August 2009. in progress), April 2010.
[I-D.niccolini-speermint-voipthreats] [I-D.ietf-speermint-voipthreats]
Niccolini, S., Chen, E., Seedorf, J., and H. Scholz, Seedorf, J., Niccolini, S., Chen, E., and H. Scholz,
"SPEERMINT Security Threats and Suggested "SPEERMINT Security Threats and Suggested
Countermeasures", draft-niccolini-speermint-voipthreats-05 Countermeasures", draft-ietf-speermint-voipthreats-05
(work in progress), October 2008. (work in progress), September 2010.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
September 1997. September 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
skipping to change at page 22, line 5 skipping to change at page 21, line 5
March 2009. March 2009.
[RFC5503] Andreasen, F., McKibben, B., and B. Marshall, "Private [RFC5503] Andreasen, F., McKibben, B., and B. Marshall, "Private
Session Initiation Protocol (SIP) Proxy-to-Proxy Session Initiation Protocol (SIP) Proxy-to-Proxy
Extensions for Supporting the PacketCable Distributed Call Extensions for Supporting the PacketCable Distributed Call
Signaling Architecture", RFC 5503, March 2009. Signaling Architecture", RFC 5503, March 2009.
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", RFC 5630, October 2009. Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in
the Session Initiation Protocol (SIP)", RFC 5923,
June 2010.
Appendix A. Policy Parameters for Session Peering Appendix A. Policy Parameters for Session Peering
This informative section lists various types of parameters that This informative section lists various types of parameters that
should be considered by implementers when deciding what configuration should be considered by implementers when deciding what configuration
variables to expose to system administrators or management stations, variables to expose to system administrators or management stations,
as well as SSPs or federations of SSPs when discussing the technical as well as SSPs or federations of SSPs when discussing the technical
part of a session peering policy. part of a session peering policy.
In the context of session peering, a policy can be defined as the set In the context of session peering, a policy can be defined as the set
of parameters and other information needed by an SSP to exchange of parameters and other information needed by an SSP to exchange
skipping to change at page 23, line 6 skipping to change at page 23, line 6
based on peer relationships. based on peer relationships.
A.1. Categories of Parameters for VoIP Session Peering and A.1. Categories of Parameters for VoIP Session Peering and
Justifications Justifications
The following list should be considered as an initial list of The following list should be considered as an initial list of
"discussion topics" to be addressed by peers when initiating a VoIP "discussion topics" to be addressed by peers when initiating a VoIP
peering relationship. peering relationship.
o IP Network Connectivity: o IP Network Connectivity:
Session peers should define how the IP network connectivity Session peers should define the IP network connectivity between
between their respective SBEs and DBEs. While this is out of their respective SBEs and DBEs. While this is out of scope of
scope of session peering, SSPs must agree on a common mechanism session peering, SSPs must agree on a common mechanism for IP
for IP transport of session signaling and media. This may be transport of session signaling and media. This may be accomplish
accomplish via private (e.g. IPVPN, IPsec, etc.) or public IP via private (e.g. IPVPN, IPsec, etc.) or public IP networks.
networks.
o Media-related Parameters: o Media-related Parameters:
* Media Codecs: list of supported media codecs for audio, real- * Media Codecs: list of supported media codecs for audio, real-
time fax (version of T.38, if applicable), real-time text (RFC time fax (version of T.38, if applicable), real-time text (RFC
4103), DTMF transport, voice band data communications (as 4103), DTMF transport, voice band data communications (as
applicable) along with the supported or recommended codec applicable) along with the supported or recommended codec
packetization rates, level of RTP payload redundancy, audio packetization rates, level of RTP payload redundancy, audio
volume levels, etc. volume levels, etc.
 End of changes. 24 change blocks. 
87 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/