Paul Kyzivat wrote:
> 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.
That wouldn't be backwards compatible or RFC 2327 conformant for that matter.
> 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.
>
Right. Apart from the above, I'm also not a big fan of requiring the extra
round-trip. Default behavior should work with just a single round-trip, but further
refinement (or changes) may require an extra round.
>
> 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.
Right - good point (it's also SIP specific as opposed to more general offer/answer).
-- Flemming
>
>
> Paul
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
