Subject: RE: draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC meeting in San Diego)

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 3 Dec 2000 23:59:12 -0500

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Thursday, November 30, 2000 12:42 PM
> To: Thomas LEVY
> Cc: [email-masked]
> Subject: Re: draft-andreasen-mmusic-sdp-simcap-00.txt (Was: MMUSIC
> meeting in San Diego)
> 
> 
> 
> 
> Thomas LEVY wrote:
> 
> >     Hi Flemming,
> >
> > I am not sure to understand the example you are referring to:
> > 1) Is it that the system is not able to handle some kind of 
> audio (for
> > inst:PCMU) and DTMF simultaneously?
> > or
> > 2) Is it that the system is able to but doesn't want to 
> associate some
> > kind of audio (for inst:PCMU) and DTMF for this particular stream?
> > or an other case?
> 
> It's the second case. Consider an application that wants to 
> receive DTMF
> input from the user. Different mechanisms have been proposed for this,
> and one of these is the use of an RFC 2833 DTMF media stream. In the
> case where DTMF is all you wanted to support for a media stream while
> having another media stream at the same time, you want a way 
> to express
> that a given capability only applies to a given media stream.

This doesn't require any extensions, so long as the originator always lists
all codecs possible in a new stream. Consider A and B are in a  call, and
that B is actually an application that wants to add a DTMF stream. 

The original INVITE from the user A to the server B has SDP like:

m=audio 44530 RTP/AVP 0 3 15 88
c=IN IP4 1.2.3.4
a=rtpmap:88 telephone-event

thus indicating support for PCMU, GSM, G.728 and DTMF. The response from the
server B indicates just PCMU:

m=audio 49230 RTP/AVP 0
c=IN IP4 14.5.3.55

Now, it wants to receive DTMF stream. It knows the other side supports DTMF.
It would send a re-INVITE thats like

m=audio 49230 RTP/AVP 0
c=IN IP4 14.5.3.55
m=audio 49232 RTP/AVP 88
c=IN IP4 14.5.3.55
a=rtpmap:88 telephone-event
a=recvonly

and the response is:

m=audio 44530 RTP/AVP 0
c=IN IP4 1.2.3.4
m=audio 44532 RTP/AVP 88
c=IN IP4 1.2.3.4
a=rtpmap:88 telephone-event
a=sendonly

Even assuming B didn't know whether A supported DTMF, it would simply try to
set up a dtmf stream, and the request would be rejected if the codec wasn't
available.

Thus, I am failing to see the pressing need here. 

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 04 Dec 2000 10:10:47 -0500

Jonathan Rosenberg wrote:

> all codecs possible in a new stream.

Yes, but that's the problem with SDP and the point about adding capability
descriptions that are separate from the media description. You may not be able
to or want to support all possible codecs simultaneously, e.g. due to DSP
restrictions or because you cannot express different types of media in a single
media stream as in the case of T.38.

> Consider A and B are in a  call, and
> thus indicating support for PCMU, GSM, G.728 and DTMF.

Yes, but what if A preferred to simply use PCMU or wanted to list two media
streams initially ? In the latter case, one of the media streams would be for
DTMF only, yet additional capabilities that only apply to the other media stream
are desired to be indicated, hence session level capability descriptions are not
adequate.

> The response from the

You can always use more or less blind trial-and-error, but that's hardly an
optimal design. While it may not be a major problem in this DTMF example, there
are other less forgiving scenarios such as shifting to fax relay.

-- Flemming

--
Flemming Andreasen
Cisco Systems