Right, but the behavior your after is not guaranteed by the relevant RFCs (as has been pointed out already). An extra offer-answer exchange is required in the case the answer lists multiple codecs.
I would hope to see only a single codec in an answer, and see the mechanisms defined in RFC 3388 used in cases where switching codecs is needed during the call, given the practical aspects of building platforms that handle multiple calls at a time.
Regards, Bert
Alex Zeffertt wrote:
In this case you should not advertise that you can. Use separate "m" lines, each with one codec. This will remove the ambiguity you're having, and be compliant with the relative RFCs.
Hi Bert,
This sounds like a good idea, and it would mean that the answerer wouldn't dynamically change codecs used on each RTP port - but I think it give the impression that the offerer can support multiple _simultaneous_ different codec streams, all on seperate RTP ports. What I actually want is the offerer to advertise all the codecs it supports in such a way that the answerer responds with just one.
Alex
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
