draft-ietf-mmusic-media-loopback-00.txt | draft-ietf-mmusic-media-loopback-01.txt | |||
---|---|---|---|---|
K. Hedayat | K. Hedayat | |||
Internet Draft Brix Networks | Internet Draft Brix Networks | |||
Expires: June 30, 2005 P. Jones | Expires: December 27,2005 P. Jones | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
A. Roychowdhury | A. Roychowdhury | |||
Hughes Software Systems | Flextronics Software Systems | |||
C. SivaChelvan | C. SivaChelvan | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
N. Stratton | N. Stratton | |||
BroadVoice | BroadVoice | |||
December 2, 2004 | June 27, 2005 | |||
An Extension to the Session Description Protocol (SDP) for Media | An Extension to the Session Description Protocol (SDP) for Media | |||
Loopback | Loopback | |||
draft-ietf-mmusic-media-loopback-00.txt | draft-ietf-mmusic-media-loopback-01.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, we certify that any applicable | By submitting this Internet-Draft, each author represents that any | |||
patent or other IPR claims of which we are aware have been | applicable patent or other IPR claims of which he or she is aware | |||
disclosed and any of which we become aware will be disclosed, in | have been or will be disclosed, and any of which he or she becomes | |||
accordance with RFC 3668 (BCP 79). | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
By submitting this Internet-Draft, we accept the provisions of | ||||
Section 3 of RFC 3667 (BCP 78). | ||||
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), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as | other groups may also distribute working documents as | |||
Internet-Drafts. | Internet-Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six | Internet-Drafts are draft documents valid for a maximum of six | |||
months and may be updated, replaced, or obsoleted by other | months and may be updated, replaced, or obsoleted by other | |||
documents at any time. It is inappropriate to use Internet-Drafts | documents at any time. It is inappropriate to use Internet-Drafts | |||
as reference material or to cite them other than as "work in | as reference material or to cite them other than as "work in | |||
progress." | progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
Copyright Notice | ||||
Copyright (C) The Internet Society (2005). | ||||
Abstract | Abstract | |||
The wide deployment of VoIP and Video over IP services has | The wide deployment of VoIP and Video over IP services has | |||
introduced new challenges in managing and maintaining voice/video | introduced new challenges in managing and maintaining voice/video | |||
quality, reliability, and overall performance. In particular, | quality, reliability, and overall performance. In particular, | |||
media delivery is an area that needs attention. One method of | media delivery is an area that needs attention. One method of | |||
meeting these challenges is monitoring the media delivery | meeting these challenges is monitoring the media delivery | |||
performance by looping media back to the transmitter. This is | performance by looping media back to the transmitter. This is | |||
typically referred to as "active monitoring" of services. Media | typically referred to as "active monitoring" of services. Media | |||
loopback is especially popular in ensuring the quality of transport | loopback is especially popular in ensuring the quality of transport | |||
to the edge of a given VoIP or Video over IP service. Today in | to the edge of a given VoIP or Video over IP service. Today in | |||
networks that deliver real-time media, short of running ' ping' and | networks that deliver real-time media, short of running ' ping' and | |||
skipping to change at page 2, line 27 | skipping to change at page 2, line 30 | |||
SDP media attributes which enables establishment of media sessions | SDP media attributes which enables establishment of media sessions | |||
where the media is looped back to the transmitter. Such media | where the media is looped back to the transmitter. Such media | |||
sessions will serve as monitoring and troubleshooting tools by | sessions will serve as monitoring and troubleshooting tools by | |||
providing the means for measurement of more advanced VoIP and Video | providing the means for measurement of more advanced VoIP and Video | |||
Over IP performance metrics. | Over IP performance metrics. | |||
Table of Contents | Table of Contents | |||
1. Introduction..................................................3 | 1. Introduction..................................................3 | |||
2. Terminology...................................................3 | 2. Terminology...................................................3 | |||
3. Offering Entity Behavior......................................3 | 3. Offering Entity Behavior......................................4 | |||
4. Answering Entity Behavior.....................................4 | 4. Answering Entity Behavior.....................................4 | |||
5. SDP Constructs Syntax.........................................4 | 5. SDP Constructs Syntax.........................................4 | |||
5.1 Loopback Type Attribute...................................4 | 5.1 Loopback Type Attribute...................................4 | |||
5.2 Loopback Mode Attribute...................................5 | 5.2 Loopback Mode Attribute...................................6 | |||
5.3 Generating the Offer for Loopback Session.................5 | 5.3 Generating the Offer for Loopback Session.................6 | |||
5.4 Generating the Answer for Loopback Session................6 | 5.4 Generating the Answer for Loopback Session................7 | |||
5.5 Offerer Processing of the Answer..........................7 | 5.5 Offerer Processing of the Answer..........................8 | |||
5.6 Modifying the Session.....................................7 | 5.6 Modifying the Session.....................................8 | |||
6. RTP Requirements..............................................7 | 6. RTP Requirements..............................................8 | |||
7. RTCP Requirements.............................................8 | 7. RTCP Requirements.............................................9 | |||
8. Examples......................................................8 | 8. Examples......................................................9 | |||
8.1 Offer for specific media loopback type....................8 | 8.1 Offer for specific media loopback type....................9 | |||
8.2 Offer for choice of media loopback type...................9 | 8.2 Offer for choice of media loopback type..................10 | |||
8.3 Response to INVITE request rejecting loopback media......10 | 8.3 Offer for choice of media loopback type with | |||
9. Implementer Guidelines.......................................11 | rtp-start-loopback...........................................11 | |||
10. Security Considerations.....................................11 | 8.4 Response to INVITE request rejecting loopback media......12 | |||
11. IANA Considerations.........................................11 | 8.5 Response to INVITE request rejecting loopback media with | |||
12. Acknowledgements............................................11 | rtp-start-loopback...........................................13 | |||
13. References..................................................11 | 9. Security Considerations......................................13 | |||
13.1 Normative References....................................11 | 10. IANA Considerations.........................................14 | |||
11. Acknowledgements............................................14 | ||||
12. References..................................................14 | ||||
12.1 Normative References....................................14 | ||||
1. Introduction | 1. Introduction | |||
The overall quality, reliability, and performance of VoIP and Video | The overall quality, reliability, and performance of VoIP and Video | |||
over IP services relies on the performance and quality of the media | over IP services relies on the performance and quality of the media | |||
path. In order to assure the quality of the delivered media there | path. In order to assure the quality of the delivered media there | |||
is a need to monitor the performance of the media transport. One | is a need to monitor the performance of the media transport. One | |||
method of monitoring and managing the overall quality of VoIP and | method of monitoring and managing the overall quality of VoIP and | |||
Video over IP Services is through monitoring the quality of the | Video over IP Services is through monitoring the quality of the | |||
media in an active session. This type of "active monitoring" of | media in an active session. This type of "active monitoring" of | |||
services is a method of pro-actively managing the performance and | services is a method of pro-actively managing the performance and | |||
skipping to change at page 4, line 39 | skipping to change at page 4, line 42 | |||
Two new media attributes are defined: one indicates the type of | Two new media attributes are defined: one indicates the type of | |||
loopback and one indicates the mode of the loopback. | loopback and one indicates the mode of the loopback. | |||
5.1 Loopback Type Attribute | 5.1 Loopback Type Attribute | |||
The loopback type is a property media attribute with the following | The loopback type is a property media attribute with the following | |||
syntax: | syntax: | |||
a=loopback:<loopback-type> | a=loopback:<loopback-type> | |||
Following is the Augmented BNF (RFC 2234) [RFC2234] for loopback- | Following is the Augmented BNF (RFC 2234) [RFC2234] for | |||
type: | loopback-type: | |||
loopback-type = loopback-type-choice [ space loopback-type-choice ] | loopback-type = loopback-type-choice [ space loopback-type-choice ] | |||
loopback-type-choice = "rtp-pkt-loopback" | "rtp-media-loopback" | loopback-type-choice = "rtp-pkt-loopback" | "rtp-media-loopback | | |||
rtp-start-loopback" | ||||
The loopback type is used to indicate the type of loopback. The | The loopback type is used to indicate the type of loopback. The | |||
loopback-type values are rtp-pkt-loopback and rtp-media-loopback. | loopback-type values are rtp-pkt-loopback, rtp-media-loopback, and | |||
rtp-start-loopback. | ||||
rtp-pkt-loopback: In this mode, the RTP packets are looped back to | rtp-pkt-loopback: In this mode, the RTP packets are looped back to | |||
the sender at a point before the encoder/decoder function in the | the sender at a point before the encoder/decoder function in the | |||
receive direction to a point after the encoder/decoder function in | receive direction to a point after the encoder/decoder function in | |||
the send direction. This effectively re-encapsulates the RTP | the send direction. This effectively re-encapsulates the RTP | |||
payload with the RTP/UDP/IP overheads appropriate for sending it in | payload with the RTP/UDP/IP overheads appropriate for sending it in | |||
the reverse direction. Any type of encoding related functions, | the reverse direction. Any type of encoding related functions, | |||
such as packet loss concealment, MUST NOT be part of this type of | such as packet loss concealment, MUST NOT be part of this type of | |||
loopback path. | loopback path. | |||
rtp-media-loopback: This loopback is activated as close as possible | rtp-media-loopback: This loopback is activated as close as possible | |||
to the analog interface and after the decoder so that the RTP | to the analog interface and after the decoder so that the RTP | |||
packets are subsequently re-encoded prior to transmission back to | packets are subsequently re-encoded prior to transmission back to | |||
the sender. | the sender. | |||
rtp-start-loopback: In certain scenarios it is possible that the | ||||
media transmitted by the offering entity is blocked by a network | ||||
element until the answering entity starts transmitting packets. | ||||
One example of this scenario is the presence of an RTP relay in the | ||||
path of the media. RTP relays exist in VoIP networks for purpose | ||||
of NAT and Firewall traversal. If an RTP relay is present the | ||||
offering entityÆs packets are dropped by the RTP relay until the | ||||
answering entity has started transmitting media and the media state | ||||
within the RTP relay is established. This loopback attribute is | ||||
used to specify the media type for transmitting media packets by | ||||
the answering entity prior to the loopback process for the purpose | ||||
of setting media state within the network. In the presence of this | ||||
loopback attribute the answering entity will transmit media, | ||||
according to the description that contains this attribute, until it | ||||
receives media from the offering entity. After the first media | ||||
packet is received from the offering entity, the answering entity | ||||
MUST terminate the transmission of rtp-start-loopback media and | ||||
MUST start looping back media as defined by the other loopback | ||||
attributes present in the offer. If an offer includes the | ||||
rtp-start-loopback attribute it MUST also include at least one | ||||
other attribute as defined in this section. The offering entity is | ||||
able to filter rtp-start-loopback packets from other types of | ||||
loopback with the payload type of the packet. The media port number | ||||
for rtp-start-loopback MUST be the same as the corresponding | ||||
loopback attribute that will take over after the reception of first | ||||
media packet from the offering entity. | ||||
It is recommended that an offering entity specifying media with | ||||
either rtp-pkt-loopback or rtp-media-loopback attribute also | ||||
specify the rtp-start-loopback attribute unless the offering entity | ||||
is certain that its media will not be blocked by a network entity | ||||
as explained above. | ||||
5.2 Loopback Mode Attribute | 5.2 Loopback Mode Attribute | |||
The loopback mode is a value media attribute that is used to | The loopback mode is a value media attribute that is used to | |||
indicate the mode of the loopback. These attributes can be viewed | indicate the mode of the loopback. These attributes can be viewed | |||
as additional mode attributes similar to sendonly, recvonly, etc. | as additional mode attributes similar to sendonly, recvonly, etc. | |||
The syntax of the loopback mode media attribute is: | The syntax of the loopback mode media attribute is: | |||
a=<loopback-mode> | a=<loopback-mode> | |||
The loopback-mode values are loopback-source and loopback-mirror.. | The loopback-mode values are loopback-source and loopback-mirror. | |||
loopback-source: This attribute specifies that the sender is the | loopback-source: This attribute specifies that the sender is the | |||
media source and expects the receiver to act as a loopback-mirror. | media source and expects the receiver to act as a loopback-mirror. | |||
loopback-mirror: This attribute specifies that the receiver will | loopback-mirror: This attribute specifies that the receiver will | |||
mirror (echo) all received media back to the sender of the RTP | mirror (echo) all received media back to the sender of the RTP | |||
stream. No media is generated locally by the reciver for | stream. No media is generated locally by the reciver for | |||
transmission in the mirrored stream. | transmission in the mirrored stream. | |||
The loopback mode attribute does not apply to rtp-start-loopback | ||||
attribute and MAY be omitted. If the loopback mode attribute is | ||||
present with the rtp-start-loopback attribute it MUST be ignored by | ||||
the answering entity. | ||||
5.3 Generating the Offer for Loopback Session | 5.3 Generating the Offer for Loopback Session | |||
If an offerer wishes to make a loopback request, it MUST include | If an offerer wishes to make a loopback request, it MUST include | |||
both the loopback-type and loopback-mode attribute in a valid SDP | both the loopback-type and loopback-mode attribute in a valid SDP | |||
offer: | offer: | |||
Example: a=loopback-type:rtp-media-loopback | Example: a=loopback:rtp-media-loopback | |||
a=loopback-source | a=loopback-source | |||
Note: A loopback offer in a given media description MUST NOT | Note: A loopback offer in a given media description MUST NOT | |||
contain the standard mode attributes sendonly, recvonly, sendrecv | contain the standard mode attributes sendonly, recvonly, sendrecv | |||
or inactive. | or inactive. | |||
The offerer may offer more than one loopback-type in the SDP offer. | The offerer may offer more than one loopback-type in the SDP offer. | |||
In this case the answer MUST include only one of the loopback types | In this case the answer MUST include only one of the loopback types | |||
that is accepted by the answerer. The answerer SHOULD give | that is accepted by the answerer. The answerer SHOULD give | |||
preference to the first loopback-type in the SDP offer. | preference to the first loopback-type in the SDP offer. | |||
For loopback-source media (e.g. audio) streams, the port number and | For loopback-source media (e.g. audio) streams, the port number and | |||
skipping to change at page 6, line 32 | skipping to change at page 7, line 26 | |||
If an answerer wishes to accept the loopback request it MUST | If an answerer wishes to accept the loopback request it MUST | |||
include both the loopback mode and loopback type attribute in the | include both the loopback mode and loopback type attribute in the | |||
answer. If a stream is offered with loopback-source or | answer. If a stream is offered with loopback-source or | |||
loopback-mirror attributes, the corresponding stream MUST be | loopback-mirror attributes, the corresponding stream MUST be | |||
loopback-mirror or loopback-source respectively, provided that | loopback-mirror or loopback-source respectively, provided that | |||
answerer is capable of supporting the requested loopback-type. | answerer is capable of supporting the requested loopback-type. | |||
For example, if the offer contains: | For example, if the offer contains: | |||
a=loopback-type:rtp-media-loopback | a=loopback:rtp-media-loopback | |||
a=loopback-source | a=loopback-source | |||
The answer that is capable of supporting the offer MUST contain: | The answer that is capable of supporting the offer MUST contain: | |||
a=loopback-type:rtp-media-loopback | a=loopback:rtp-media-loopback | |||
a=loopback-mirror | a=loopback-mirror | |||
As previously stated if a stream is offered with multiple loopback | As previously stated if a stream is offered with multiple loopback | |||
type attributes, the corresponding stream MUST contain only one | type attributes, the corresponding stream MUST contain only one | |||
loopback type attribute selected by the answerer. | loopback type attribute selected by the answerer. | |||
For example, if the offer contains: | For example, if the offer contains: | |||
a=loopback-type:rtp-media-loopback rtp-pkt-loopback | a=loopback:rtp-media-loopback rtp-pkt-loopback | |||
a=loopback-source | a=loopback-source | |||
The answer that is capable of supporting the offer and chooses to | The answer that is capable of supporting the offer and chooses to | |||
loopback the media using the rtp-media-loopback type MUST contain: | loopback the media using the rtp-media-loopback type MUST contain: | |||
a=loopback-type:rtp-media-loopback | a=loopback:rtp-media-loopback | |||
a=loopback-mirror | a=loopback-mirror | |||
5.4.1 Rejecting the Loopback Offer | 5.4.1 Rejecting the Loopback Offer | |||
An offered stream with loopback-source MAY be rejected, if the | An offered stream with loopback-source MAY be rejected, if the | |||
loopback-type is not specified, the specified loopback-type is not | loopback-type is not specified, the specified loopback-type is not | |||
supported, or the endpoint cannot honor the offer for any other | supported, or the endpoint cannot honor the offer for any other | |||
reason. The Loopback request may be rejected by setting the media | reason. The Loopback request may be rejected by setting the media | |||
port number to zero, according to RFC 3264 [RFC3264], in the | port number to zero, according to RFC 3264 [RFC3264], in the | |||
answer. | answer. | |||
5.5 Offerer Processing of the Answer | 5.5 Offerer Processing of the Answer | |||
skipping to change at page 10, line 23 | skipping to change at page 11, line 19 | |||
e=user@example.com | e=user@example.com | |||
c=IN IP4 224.2.17.12/127 | c=IN IP4 224.2.17.12/127 | |||
t=0 0 | t=0 0 | |||
m=audio 49170 RTP/AVP 0 | m=audio 49170 RTP/AVP 0 | |||
a=loopback:rtp-pkt-loopback | a=loopback:rtp-pkt-loopback | |||
a=loopback-mirror | a=loopback-mirror | |||
The server is accepting to mirror the media from the client at the | The server is accepting to mirror the media from the client at the | |||
packet level. | packet level. | |||
8.3 Response to INVITE request rejecting loopback media | 8.3 Offer for choice of media loopback type with rtp-start-loopback | |||
A client sends an INVITE request with SDP which looks like: | ||||
v=0 | ||||
o=user1 2890844526 2890842807 IN IP4 126.16.64.4 | ||||
s=Example | ||||
i=An example session | ||||
e=user@example.com | ||||
c=IN IP4 224.2.17.12/127 | ||||
t=0 0 | ||||
m=audio 49170 RTP/AVP 0 | ||||
a=loopback:rtp-media-loopback rtp-pkt-loopback | ||||
a=loopback-source | ||||
m=audio 49170 RTP/AVP 100 | ||||
a=loopback:rtp-start-loopback | ||||
The client is offering to source the media and expects the server | ||||
to mirror the RTP stream at either the media or rtp level. The | ||||
client also expects the server to source media until it receives | ||||
packets from the server per media described with the | ||||
rtp-start-loopback attribute. | ||||
A server sends a response with SDP which looks like: | ||||
v=0 | ||||
o=user1 2890844526 2890842807 IN IP4 126.16.64.4 | ||||
s=Example | ||||
i=An example session | ||||
e=user@example.com | ||||
c=IN IP4 224.2.17.12/127 | ||||
t=0 0 | ||||
m=audio 49170 RTP/AVP 0 | ||||
a=loopback:rtp-pkt-loopback | ||||
a=loopback-mirror | ||||
m=audio 49170 RTP/AVP 100 | ||||
a=rtpmap:100 pcmu/8000 | ||||
a=loopback:rtp-start-loopback | ||||
The server is accepting to mirror the media from the client at the | ||||
packet level. The server is also accepting to source media until | ||||
it receives media packets from the client. | ||||
8.4 Response to INVITE request rejecting loopback media | ||||
A client sends an INVITE request with SDP which looks like: | A client sends an INVITE request with SDP which looks like: | |||
v=0 | v=0 | |||
o=user1 2890844526 2890842807 IN IP4 126.16.64.4 | o=user1 2890844526 2890842807 IN IP4 126.16.64.4 | |||
s=Example | s=Example | |||
i=An example session | i=An example session | |||
e=user@example.com | e=user@example.com | |||
c=IN IP4 224.2.17.12/127 | c=IN IP4 224.2.17.12/127 | |||
t=0 0 | t=0 0 | |||
skipping to change at page 11, line 12 | skipping to change at page 13, line 5 | |||
c=IN IP4 224.2.17.12/127 | c=IN IP4 224.2.17.12/127 | |||
t=0 0 | t=0 0 | |||
m=audio 0 RTP/AVP 0 | m=audio 0 RTP/AVP 0 | |||
a=loopback:rtp-media-loopback | a=loopback:rtp-media-loopback | |||
a=loopback-mirror | a=loopback-mirror | |||
NOTE: Loopback request may be rejected by either not including the | NOTE: Loopback request may be rejected by either not including the | |||
loopback mode attribute(for backward compatibility) or setting the | loopback mode attribute(for backward compatibility) or setting the | |||
media port number to zero, or both, in the response. | media port number to zero, or both, in the response. | |||
9. Implementer Guidelines | 8.5 Response to INVITE request rejecting loopback media with | |||
rtp-start-loopback | ||||
This section provides guidelines to the implementers of this | A client sends an INVITE request with SDP which looks like: | |||
extension. | ||||
10. Security Considerations | v=0 | |||
o=user1 2890844526 2890842807 IN IP4 126.16.64.4 | ||||
s=Example | ||||
i=An example session | ||||
e=user@example.com | ||||
c=IN IP4 224.2.17.12/127 | ||||
t=0 0 | ||||
m=audio 49170 RTP/AVP 0 | ||||
a=loopback:rtp-media-loopback | ||||
a=loopback-source | ||||
m=audio 49170 RTP/AVP 100 | ||||
a=loopback:rtp-start-loopback | ||||
The client is offering to source the media and expects the server | ||||
to mirror the RTP stream at the media level. The client also | ||||
expects the server to source media until it receives packets from | ||||
the server per media described with the rtp-start-loopback | ||||
attribute. | ||||
A server sends a response with SDP which looks like: | ||||
v=0 | ||||
o=user1 2890844526 2890842807 IN IP4 126.16.64.4 | ||||
s=Example | ||||
i=An example session | ||||
e=user@example.com | ||||
c=IN IP4 224.2.17.12/127 | ||||
t=0 0 | ||||
m=audio 0 RTP/AVP 0 | ||||
a=loopback:rtp-media-loopback | ||||
a=loopback-mirror | ||||
m=audio 0 RTP/AVP 0 | ||||
a=loopback:rtp-start-loopback | ||||
NOTE: Loopback request may be rejected by either not including the | ||||
loopback mode attribute(for backward compatibility) or setting the | ||||
media port number to zero, or both, in the response. | ||||
9. Security Considerations | ||||
The security considerations of [RFC3261] apply. Furthermore, given | The security considerations of [RFC3261] apply. Furthermore, given | |||
that media loopback may be automated without the end userÆs | that media loopback may be automated without the end user's | |||
knowledge, the server of the media loopback should be aware of | knowledge, the server of the media loopback should be aware of | |||
denial of service attacks. It is recommended that sessions with | denial of service attacks. It is recommended that sessions with | |||
media loopback are authenticated and the frequency of such sessions | media loopback are authenticated and the frequency of such sessions | |||
are limited by the server. | are limited by the server. | |||
11. IANA Considerations | 10. IANA Considerations | |||
There are no IANA considerations associated with this | There are no IANA considerations associated with this | |||
specification. | specification. | |||
12. Acknowledgements | 11. Acknowledgements | |||
The authors wish to thank Flemming Andreasen, Jeff Bernstein, Paul | The authors wish to thank Flemming Andreasen, Jeff Bernstein, Paul | |||
Kyzivat, and Dave Oran for their comments and suggestions. | Kyzivat, and Dave Oran for their comments and suggestions. | |||
13. References | 12. References | |||
13.1 Normative References | 12.1 Normative References | |||
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., | [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., | |||
Johnston, A., Peterson, J., Sparks, R., Handley, M. | Johnston, A., Peterson, J., Sparks, R., Handley, M. | |||
and E. Schooler, "SIP: Session Initiation Protocol", | and E. Schooler, "SIP: Session Initiation Protocol", | |||
RFC 3261, STD 1, June 2002. | RFC 3261, STD 1, June 2002. | |||
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer | [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer | |||
Model with the Session Description Protocol (SDP)", | Model with the Session Description Protocol (SDP)", | |||
RFC 3264, STD 1, June 2002. | RFC 3264, STD 1, June 2002. | |||
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. | [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. | |||
Jacobson, "RTP: A Transport Protocol for Real-Time | Jacobson, "RTP: A Transport Protocol for Real-Time | |||
Applications", RFC 3550, STD 1, July 2003. | Applications", RFC 3550, STD 1, July 2003. | |||
skipping to change at page 13, line 4 | skipping to change at page 15, line 29 | |||
Paul E. Jones | Paul E. Jones | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
7025 Kit Creek Rd. | 7025 Kit Creek Rd. | |||
Research Triangle Park, NC 27709 | Research Triangle Park, NC 27709 | |||
US | US | |||
Phone: +1 919 392 6948 | Phone: +1 919 392 6948 | |||
EMail: paulej@packetizer.com | EMail: paulej@packetizer.com | |||
URI: http://www.cisco.com/ | URI: http://www.cisco.com/ | |||
Arjun Roychowdhury | Arjun Roychowdhury | |||
Hughes Software Systems | Flextronics Software Systems | |||
11717 Exploration Lane | 11717 Exploration Lane | |||
Germantown, MD 20876 | Germantown, MD 20876 | |||
US | US | |||
Phone: +1 301 212 7860 | Phone: +1 301 212 7860 | |||
EMail: aroychow@hssworld.com | EMail: arjun.roy@flextronicssoftware.com | |||
URI: http://www.hssworld.com/ | URI: http://www.flextronicssoftware.com/ | |||
Chelliah SivaChelvan | Chelliah SivaChelvan | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
2200 East President George Bush Turnpike | 2200 East President George Bush Turnpike | |||
Richardson, TX 75082 | Richardson, TX 75082 | |||
US | US | |||
Phone: +1 972 813 5224 | Phone: +1 972 813 5224 | |||
EMail: chelliah@cisco.com | EMail: chelliah@cisco.com | |||
URI: http://www.cisco.com/ | URI: http://www.cisco.com/ | |||
skipping to change at page 14, line 27 | skipping to change at page 17, line 11 | |||
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE | |||
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND | REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND | |||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, | |||
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT | EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT | |||
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR | THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR | |||
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A | ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A | |||
PARTICULAR PURPOSE. | PARTICULAR PURPOSE. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2004). | Copyright (C) The Internet Society (2005). | |||
This document is subject to the rights, licenses and restrictions | This document is subject to the rights, licenses and restrictions | |||
contained in BCP 78, and except as set forth therein, the authors | contained in BCP 78, and except as set forth therein, the authors | |||
retain all their rights. | retain all their rights. | |||
Acknowledgment | Acknowledgment | |||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | |||
Internet Society. | Internet Society. | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |