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

[Jonathan Rosenberg <jdrosen@dynamicsoft.com>]

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.


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

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic