Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-offer-answer-examples-02.txt

From: [email-masked]
Date: Tue, 17 Feb 2004 10:35:28 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title		: Session Description Protocol Offer Answer Examples
	Author(s)	: A. Johnston, R. Sparks
	Filename	: draft-ietf-mmusic-offer-answer-examples-02.txt
	Pages		: 24
	Date		: 2004-2-17
	
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-offer-answer-examples-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mmusic-offer-answer-examples-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-offer-answer-examples-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Pekka Pessi <[email-masked]>
Date: Tue, 17 Feb 2004 20:18:36 +0200

Hello all,

Just a few comments on offer-answer-examples-02.

Based on experience during the last SIPit, it would be nice to
have a call hold flow where a=recvonly would be a session-level
attribute, e.g., 3.1 [Answer] could have a=recvonly at session
level.

Also, the RFC 3264 does not require that the rejected media lines
have same media type in the answer as they had in offer. So, it
could be useful to include such an O/A exchange in the document,
for example:

   This scenario shows Alice sending an offer describing audio,
   video and text session. Bob does not support video or text, so
   he rejects both video and text sessions. Bob does not regocnize
   the text media at all, so he returns a generic media line
   instead on its place. Alice and Bob may send only AMR audio.

    [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 8 96
      a=rtpmap:0 PCMU/8000
      a=rtpmap:8 PCMA/8000
      a=rtpmap:96 AMR/8000
      m=video 51372 RTP/AVP 31 32
      a=rtpmap:31 H261/90000
      a=rtpmap:32 MPV/90000
      m=text 36626 RTP/AVP 99 100
      a=rtpmap:99 T140/1000
      a=rtpmap:100 red/1000
      a=fmtp:100 99

   [Answer]

      v=0
      o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
      s=
      c=IN IP4 host.biloxi.example.com
      t=0 0
      m=audio 49174 RTP/AVP 96
      a=rtpmap:96 AMR/8000
      m=video 0 RTP/AVP 13
      m=unknown 0 UDP rejected

There are some SDP syntax errors and nits, too:

- iLBC codec misses the clock rate 
	a=rtpmap:97 iLBC   =>   a=rtpmap:97 iLBC/8000
- telephone-event codec (not telephone-event*s*) sometimes misses
  clock rate
        a=rtpmap:98 telephone-event   =>   a=rtpmap:98 telephone-event/8000
        a=rtpmap:98 telephone-events  =>   a=rtpmap:98 telephone-event/8000
- in the 3.2 [Second-Offer], there is an extra empty line
- in the 4.1 [Second-Answer], the c= line in first m=audio is
  after a= line.
- in the 4.3 [Answer], there is 97 on media line but rtpmap
  describes PCMU - it should be a=rtpmap:97 iLBC/8000

--Pekka

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Alan Johnston <[email-masked]>
Date: Tue, 17 Feb 2004 14:07:49 -0600

Hi Pekka,

Thanks very much for going over the document.  We'll fix the nits you list 
.  See some comments below.

Thanks,
Alan Johnston
MCI
sip:[email-masked]

>attribute, e.g., 3.1 [Answer] could have a=recvonly at session

Is this what you have in mind as an answer?

       v=0
       o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
       s=
       c=IN IP4 placeholder.biloxi.example.com
       a=sendonly
       t=0 0
       m=audio 49172 RTP/AVP 97
       a=rtpmap:97 iLBC

>       c=IN IP4 host.biloxi.example.com

OK.

>   describes PCMU - it should be a=rtpmap:97 iLBC/8000

OK

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Feb 2004 15:48:03 -0500

inline.

Alan Johnston wrote:

>> have same media type in the answer as they had in offer.

I disagree. I think its implied by:

6.1 Unicast Streams

    If a stream is offered with a unicast address, the answer for that
    stream MUST contain a unicast address.  The media type of the stream
    in the answer MUST match that of the offer.

The idea with rejection is that you set the port to zero, but otherwise 
it is a valid answer.

  So, it
>>    instead on its place. Alice and Bob may send only AMR audio.

There is no need to even understand the media type in order to reject it 
- you could just copy the string from offer to answer.

>>       c=IN IP4 host.biloxi.example.com

Per above, I think this is wrong.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Pekka Pessi <[email-masked]>
Date: Wed, 18 Feb 2004 12:09:22 +0200

>The idea with rejection is that you set the port to zero, but otherwise it
>is a valid answer.

You are much better O-A lawyer than I. I interpreted this
regarding accepted streams. So, this is not a valid answer either:

       v=0
       m=text 0 RTP/AVP 13

I guess not, because having c= line for each media is lower-case
must in RFC2327, MUST in sdp-new.

--Pekka

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 18 Feb 2004 16:14:11 -0500

Pekka Pessi wrote:

> regarding accepted streams. 

I can understand that read of it; however the intent was certainly not 
that you can put things like "unknown" in the media type.

> must in RFC2327, MUST in sdp-new.

Right.

-Jonathan R.