Flemming - more comments below.
Paul
Flemming Andreasen wrote:
>
> 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.
Why? It is legal to negotiate a media-less session. And an SDP body
constitutes an offer even if it doesn't contain any m= lines. This would
of course mean that the capability descriptions would all have to be
session-level.
So, the offer would contain a request for a session with no media, but
with capability descriptions for supported media. The response would
agree to the session with no media and return capability descriptions.
Then one side or the other would initiate a re-invite, offering media
compatible with the capabilities supported by both sides.
>
> > 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.
Well, you only do this if you don't know what to offer initially.
You can also implement half of this techique: if you receive an offer
with media that you can't support, you could accept the invite but
refuse the media, and include a simcap description of what you would be
willing to accept. Then hope for a reinvite. If the offerer doesn't know
how to deal with this, ought to send bye to media-less session.
>
> >
> > 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
