--- 1/draft-ietf-mmusic-offer-answer-examples-04.txt	2006-02-05 00:26:49.000000000 +0100
+++ 2/draft-ietf-mmusic-offer-answer-examples-05.txt	2006-02-05 00:26:49.000000000 +0100
@@ -1,48 +1,50 @@
 
 MMUSIC Working Group                                         A. Johnston
 Internet-Draft                                                       MCI
-Expires: January 6, 2005                                       R. Sparks
+Expires: February 16, 2005                                     R. Sparks
                                                              dynamicsoft
-                                                            July 8, 2004
+                                                         August 18, 2004
 
            Session Description Protocol Offer Answer Examples
-               draft-ietf-mmusic-offer-answer-examples-04
+               draft-ietf-mmusic-offer-answer-examples-05
 
 Status of this Memo
 
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
+   This document is an Internet-Draft and is subject to all provisions
+   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
+   author represents that any applicable patent or other IPR claims of
+   which he or she is aware have been or will be disclosed, and any of
+   which he or she become aware will be disclosed, in accordance with
    RFC 3668.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as
    Internet-Drafts.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
    The list of current Internet-Drafts can be accessed at
    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 January 6, 2005.
+   This Internet-Draft will expire on February 16, 2005.
 
 Copyright Notice
 
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+   Copyright (C) The Internet Society (2004).
 
 Abstract
 
    This document gives examples of Session Description Protocol (SDP)
    offer answer exchanges.  Examples include codec negotiation and
    selection, hold and resume, and addition and deletion of media
    streams.  The examples show multiple media types, bidirectional,
    unidirectional, inactive streams and dynamic payload types.  Common
    Third Party Call Control (3pcc) examples are also given.
 
@@ -84,21 +86,22 @@
    (SIP) [3].
 
    Examples include codec negotiation and selection, hold and resume,
    and addition and deletion of media streams.  The examples show
    multiple media types, bidirectional, unidirectional, inactive streams
    and dynamic payload types.  Common Third Party Call Control (3pcc)
    [5] examples are also given.
 
    The following sections contain examples in which two parties, Alice
    and Bob, exchange SDP offers, answers, and, in some cases, additional
-   offers and answers.
+   offers and answers.  Note that the subject line (s=) contains a
+   single space character.
 
 2.  Codec Negotiation and Selection
 
 2.1  Audio and Video 1
 
    This common scenario shows a video and audio session in which
    multiple codecs are offered but only one is accepted.  As a result of
    the exchange shown below, Alice and Bob may send only PCMU audio and
    MPV video.  Note: Dynamic payload type 97 is used for iLBC codec [6].
 
@@ -500,24 +503,24 @@
       v=0
       o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com
       s=
       c=IN IP4 host.atlanta.example.com
       t=0 0
       m=audio 49178 RTP/AVP 97
       a=rtpmap:97 iLBC/8000
 
 3.2  Hold with Two Streams
 
-   Alice sends but can not receive RFC2833 tones in a separate audio
-   stream.  Bob accepts both audio streams.  Bob then puts Alice's audio
-   stream on hold but not the tone stream.  Alice responds with
-   identical SDP to the initial offer.
+   Alice offers two media streams, a bidirectional audio stream and a
+   send only telephone event stream.  Bob accepts both streams.  Bob
+   then puts Alice's audio stream on hold but not the tone stream.
+   Alice responds with identical SDP to the initial offer.
 
     [Offer]
 
       v=0
       o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
       s=
       c=IN IP4 host.atlanta.example.com
       t=0 0
       m=audio 49170 RTP/AVP 0 97
       a=rtpmap:0 PCMU/8000