Flemming Andreasen wrote:
>
> It doesn't solve this particular problem by itself, however it provides a
> mechanism that can be used to help solve it while remaining backwards
> compatible. In its present form, you can send an INVITE/offer listing only one
> codec in the "m=" line, and then include all codecs supported in the
> capabilites. The answerer can accept this, and then do another re-INVITE
> picking one or more codecs from the capabilites if you wants to use a different
> one.
How about a variant of this - an Invite where the offer includes *no* m=
lines, but uses simcap to describe what is available. The recipient
would be expected to accept the invite with no media, perhaps also
returning capabilities. Then one side or the other need to send a
reinvite to establish media.
This provides the extra round trip to do negotiation. But it requires
significant support from all parties.
An alternative that I was going to mention is to precede the INVITE with
an OPTIONS request to discover what the other side is capable of. But it
suffers from a serious problem - it doesn't establish a dialog, so there
is no guarantee that the subsequent INVITE will go to the same place.
Paul
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
