Paul Kyzivat wrote:
> 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.
>
You're right - my mistake.
>
> 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.
Or, if it was an old implementation, it might return an SDP with media streams and
formats
it's willing to support.
>
> 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.
>
OK, however there are other downsides to this:
- How do you handle a 1xx response to the first INVITE ?
- What do you do if it turns out that you don't have any media formats in common, and
now
the called party is being alerted and/or has already answered ?
>
> 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.
You could do this, but it sounds a little fragile to me (e.g. consider clipping, no
media
formats in common, etc.)
-- Flemming
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
