Dale Worley wrote:
> On Sat, 2009-08-15 at 23:35 +0800, T Satyanarayana-A12694 wrote:
>> Additional round trips should be made optional (only for implementations
>> having concurrent codecs limitation).
>>
>> Additionally, why can't the spec be modified (or place in a BCP):
>> 1. to allow only a sub-set (of what is present in the offer) in the
>> answer (or even just one codec)
>
> If you mean, "Is it allowed to put in the answer only a subset of the
> codecs that are in the offer", that is allowed now.
>
>> 2. to place a restrion on the offerer to only use one of the codecs
>> listed in the intersection of answer & offer.
>
> Some implementations use more than one codec, so that would have to be
> considered a BCP.
Note that Telepone-Events (DTMF) is simply represented as another codec,
so even implementations that support only one "real" codec at a time are
likely two support a real one plus telephone events. Who is to say that
there aren't other "special" codecs like this?
So I think you must actually consider this sort of restriction as a
restriction to certain *combinations* of codecs.
It doesn't even sound like a BCP, in that it isn't *best* for everybody.
Its just least common denominator - or a profile of usage.
But if there are implementations that have such a restriction, and have
good cause not to remove it, then it would be good to have a way to
signal such limitation.
One way I have heard of doing this with current mechanisms is to
initially offer several codecs, but with a=inactive. Then, after the
first answer is received, offer a single codec with a=sendrecv.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
