Subject: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer

From: Flemming Andreasen <[email-masked]>
Date: Fri, 15 Feb 2002 15:58:29 -0500

Roman Shpount wrote:

> Roman Shpount wrote:
>
> > There are two problems that I have with answerers sending with codecs
> > not in the answer:
> > 1. Interoperability with original RFC2543
>
> Flemming Andreasen wrote:
>
> > Not sure this is a real issue, as RFC 2543 was not entirely clear on
> > this and, as indicated earlier, the understanding a lot of people had is
> > to allow the answerer to send with any offered codec, regardless of the
> > answer.
>
> The problem is that there are also enough people that interpreted RFC 2543 the other way (not accepting codecs not specified in the answer). So, in order to interoperate with products from those people the answerer should not send media with codecs not included in the answer.

We obviously can't support both interpretations, however could we put in a note about it being a potential problem for some older implementations and hence at least alert people to it ?

-- Flemming

>
> ___________________________________
> 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

--
Flemming Andreasen
Cisco Systems

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

---

From: "Bert Culpepper" <[email-masked]>
Date: Fri, 15 Feb 2002 16:24:36 -0500

Flemming Andreasen wrote:

> > The problem is that there are also enough people that 
> interpreted RFC 2543 the other way (not accepting codecs not 
> specified in the answer). So, in order to interoperate with 
> products from those people the answerer should not send media 
> with codecs not included in the answer.

I had the same understanding as Flemming describes (it solves 
clipping issues and supports sending early media).  However, as 
I said earlier I'd rather see positive indications of what a 
sender will send (this doesn't affect clipping/early media 
capabilities).  But again, this is not what I got from reading 
rfc2543 and rfc2327.  I think the interpretation you describe 
is incorrect (although I'd prefer your interpretation).

> 
> We obviously can't support both interpretations, however 
> could we put in a note about it being a potential problem for 
> some older implementations and hence at least alert people to it ?
> 

I'd like to see some mention of it written down someplace.  That 
way I wouldn't have to argue my interpretation, I could point 
to a I-D/rfc :)

Regards,
Bert