Subject: Fw: Re: [MMUSIC] updated offer/answer draft

From: Roman Shpount <[email-masked]>
Date: 04 Feb 2002 18:17:43 GMT

Hi Folks,

It is specified in the section 6.1 of the new offer-answer draft that recvonly stream MAY indicate additional media formats, not listed in the offer, that the answerer is willing to receive with. Is it allowed in sendrecv streams?
___________________________________
Roman Shpount, VP of Technology
aTelo, Inc. 
2107 Wilson Blvd., Suite 301 
Arlington, VA 22201 
PCN: 703-621-4040 for voice / fax
www.atelo.com

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 05 Feb 2002 17:03:40 -0500

Roman Shpount wrote:
> 
> Hi Folks,
> 
> It is specified in the section 6.1 of the new offer-answer draft that
> recvonly stream MAY indicate additional media formats, not listed in the
> offer, that the answerer is willing to receive with. Is it allowed in
> sendrecv streams?

This is a good question.

In the sendrecv case, if the answerer adds a codec X, it cant ever send
with X, since it doesn't know if its supported by the other side. Thus,
its not actually being used as sendrecv, and therefore, does not belong
in the list as a valid sendrecv codec. That is different for recvonly. 

I could be convinced to remove this bit in the case of recvonly, to make
things simple and concise. The answer is always a subset, period.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Roman Shpount <[email-masked]>
Date: 05 Feb 2002 23:06:13 GMT

The reasoning behind this question is the same as the reasoning used to justify and support different payload type numbers in reply to the sendrecv offer. If we follow this logic, a called party gets an offer, which specifies what the calling party is willing to receive and replies with an answer that lists everything that called party is willing to receive for each of the offered streams. Those two offers must intersect as far as capabilities are concerned but both can include additional formats and use different payload types. Actually, what would be ideal is to have an ability to send two independent lists of formats that application is willing to send and to receive on the sendrecv stream. This way, for instance, application can specify its codec preferences for asymmetric connections.

Roman Shpount

------ Original message ------
>From: Jonathan Rosenberg <[email-masked]>
>Subject: Re: Fw: Re: [MMUSIC] updated offer/answer draft
>Date: 05 Feb 02, 10:03 PM
>To: Roman Shpount <[email-masked]>
>Cc: [email-masked]

This is a good question.

-Jonathan R.

[email-masked]             
  PH:  (973) 952-5000

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 06 Feb 2002 15:18:50 -0500

Roman Shpount wrote:
> 
> The reasoning behind this question is the same as the reasoning used to
> justify and support different payload type numbers in reply to the
> sendrecv offer. If we follow this logic, a called party gets an offer,
> which specifies what the calling party is willing to receive and replies
> with an answer that lists everything that called party is willing to
> receive for each of the offered streams. 

Thats not how it works. For sendrecv streams, the caller offers what it
can send and received, and same in the answer. If both sides just send
what they can receive, you can't guarantee overlap.

> Those two offers must intersect
> as far as capabilities are concerned but both can include additional
> formats and use different payload types. Actually, what would be ideal
> is to have an ability to send two independent lists of formats that
> application is willing to send and to receive on the sendrecv stream.
> This way, for instance, application can specify its codec preferences
> for asymmetric connections.

That is a known limitiation of SDP we cannot fix in this draft. In  a
sendrecv stream, you can only specify sendrecv codecs. If you want more
than that, you can use FID, and that works just fine within the
offer/answer framework.

-Jonathan R.