Subject: [MMUSIC] Another Offer/answer summary

From: Joerg Ott <[email-masked]>
Date: Thu, 21 Feb 2002 09:59:00 +0100

Folks,

we need to reach closure on this issue fairly shortly.
Having gone through the mailing list discussion, we believe
that we can narrow down Jonathan's summary a bit further
and come up with a concrete proposal to beat up:

Restating the issue:

> A sends an offer to B. That offer, for example, is for a single sendrecv
> media stream, which lists codecs 1,2 and 3. The answerer, B, responds,
> and lists codecs 1 and 2. Now, the question is this: can B still send to
> A using codec 3? Related to that, can B add codecs in the answer, which
> A can then send with?

Let us keep in mind that we are not designing offer/answer for telephony
but that telephony is rather one (maybe not unimportant) special case of
multimedia communications.  Let us also keep in mind that we should
optimize for the more common cases but at the same time not lose
generality.  And let us not forget that SIP is just *one* customer of
offer/answer.

Let us assume for a moment that we follow the "NO" proposal (and assume
further that this approach does not break interoperability/backward
compatility):

1. This idea allows us to narrow down codecs in an efficient fashion.

   This helps people who do not want to require their implementations
   to listen for multiple codecs simultaneously (e.g. because of
   limited DSP resources or difficulties in implementing MCUs).

   The counter-argument is that such device need to be able to support
   multiple codecs in the beginning anyway because of the race condition
   between the answer and the first RTP packet.  However, this can be
   circumvent this by simply waiting for the answer before accepting
   media at the risk of clipping.  But people may be able to architected
   their network in a way that it does not delay the answer unncessarily
   and thus avoid clipping in the first place).  Alternatively, they may
   guess which type of codec to expect or only load the decoder upon
   arrival of the first packet (assuming this is not going to change) at
   the expense of some additional delay, etc.

   Looks like there are sufficient alternatives that clipping can be
   considered a non-issue.  (Please note that if you are doing security
   handshakes and QoS preconditions or similar stuff, you are not going
   to worry about this type of clipping anyway -- but rather about post-
   dial delay.)

2. Expanding the codec set can be done by means of an extra offer in
   the opposite direction.  This is an extra exchange but we would assume
   this to be the less common case (and thus not optimize for it).

   The only application scenario for which this is really needed people
   have mentioned so far is DTMF -- more specifically, combining a
   sendrecv and an sendonly/recvonly media stream.  Please share ideas
   for others with us.

   We do acknowledge that this scenario is important and need support.
   But we also judge that this is not the common case and need not be
   optimized for at all cost if a cleaner solution exists.

   This cleaner solution can be based upon FID.  In the simplest case,
   A uses FID from the very beginning:

   A ----  INVITE   ----> B
       a=group:FID 1 2
       m=audio pt=0
       a=mid:1
       m=audio pt=97
       a=rtpmap:97 telephone-events
       a=mid:2
       a=sendonly

   and B can then decide whether or not to reject telephone events.

   However, A may or may not understand FID and may or may not indicate
   its send capabilities as described above.  Then we get the following
   simple exchange for A calling B:

   A ---- INVITE ----> B
          m=audio pt=0
      
   A <--- 200 OK ----- B
          m=audio pt=0
   A ----  ACK   ----> B

   Now B can indicate its receive caps using FID doing a re-INVITE.

   A <--- INVITE ----- B
          a=group:FID 1 2
          m=audio pt=0
          a=mid:1
          m=audio pt=97
          a=rtpmap:97 telephone-events
          a=mid:2
          a=recvonly

   ...

   Again, we can properly express the intended semantics.  If A does not
   support FID it ignores the attributes thus yielding the following
   in A's perception:

   A <--- INVITE ----- B
          m=audio pt=0
          m=audio pt=97
          a=rtpmap:97 telephone-events

   ...

   This is the alternative that can be pursued without FID (and, at the
   same time serves as fallback).  According to the rules defined in
   offer/answer for local processing of multiple streams of the same
   type with one local source or sink, this should just work.  The sender
   copies the input to all streams if the data can be mapped (i.e. only
   events go across the second media session), the receiver mixes the
   the incoming data streams locally as appropriate.  In a gateway this
   may sometimes mean to locally generate DTMF tones and mix them with
   audio signals, sometimes mean to locally sink the DTMF and process it.

   Jonathan, is this interpretation correct?  Is there need for clarifying
   text on this issue regarding offer/answer?

   The major issue to discuss here is whether or not there is an extra RTT
   required for this signaling (or whether other SIP methods can be used
   to achieve this more quickly) -- and whether the additional delay
   (whatever this may be) is an issue for DTMF.

   Thoughts?

Is this a viable approach ahead?

Note that we are not religious about this proposal -- but it seems to be a
reasonable way ahead taking into account some general design principles.
There may be other ways and if better ones are found, such proposals are
welcome.  But they need to be found NOW.

A small disclaimer in the end: probably we should be taking the more purist
SDP view (as Jonathan calles the "YES" approach) -- but since SDP is used 
in a way it was not supposed to be anyway the NO method may not cause too
much *extra* headache.

Colin and Joerg

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Feb 2002 22:17:43 -0500

FYI, I had a conversation with Joerg early yesterday morning about this,
and the proposal which I sent out is the one reflected in
offer-answer-01.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com