Subject: SDP on Physical Terminations

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 20 Feb 2001 11:35:36 -0500

Okay, I've been looking at this one for a while, and never said
anything, and now, at the Interop Event, it's a real problem.

I draw your attention to the example in Appendix A:
   MGC to MG1: 
   MEGACO/1 [123.123.123.4]:55555 
   Transaction = 9999 { 
       Context = - { 
           Modify = A4444 { 
               Media { Stream = 1 {  
                        LocalControl { 
                            Mode = SendReceive,  
                            tdmc/gain=2,  ; in dB,  
                            tdmc/ec=on                         
                        }, 
                        Local { 
   v=0 
   c=IN IP4 $ 
   m=audio $ RTP/AVP 0 
   a=fmtp:PCMU VAD=X-NNVAD ; special voice activity  
                           ; detection algorithm 

The problem is the SDP on the Physical Termination.
There are valid reasons why you should allow SDP on physical terminations.
The example shows one, setting the VAD bit.

The problem is the c and the a lines.  The physical termination is
not an IP flow, and is not using RTP.  Yet, SDP requires an a and m line,
just an a line is not a valid SDP.  Worse, the SDP is using "CHOOSE"
for the addresses, and there is no reply with the answers.

We need to do something.  All I can think of is to register some
new network/protocol combinations like:
c=X
m=audio 0 X

Another, less extreme suggestion would be most welcome.

Brian

---

From: Chuong Nguyen <[email-masked]>
Date: Tue, 20 Feb 2001 11:24:34 -0600

Is this a valid example to start with?

Let's look at it from a different angle.

The Reply in the Appendix did not return w/the c= and m= lines to indicate
what
Port # and IP address were chosen as asked by MGC in the request.

What kind of termination is A4444 - DS0 or an RTP termination?
The example indicated that it is an analog line.
So the question is can an analog line have RTP data on flowing across it?
Does it mean that if I pick up my analog line phone, I will hear RTP data
flow?

How does an analog line have Port# and IP address?

So if one wants to use SDP for TDM termination should the media be considered
non-RTP media?
If yes, how does the following paragraph from SDP RFC 2327 apply?

"   o Formats for non-RTP media should be registered as MIME content
     types as described in Appendix B.  For example, the LBL whiteboard
     application might be registered as MIME content-type application/wb
     with encoding considerations specifying that it operates over UDP,
     with no appropriate file format.  In SDP this would then be
     expressed using a combination of the "media" field and the "fmt"
     field, as follows:"

What was the intend of the following in the first place?
  " a=fmtp:PCMU VAD=X-NNVAD ; special voice activity
                           ; detection algorithm "

To detect something on the analog side or RTP side?
If on the analog side, should a package be defined to look for it and return
an event to MGC?

Either what is the MG supposed to do if it detect this special voice
activity?
Send an notify for event detect to MGC or go do some special processing?

Chuong

--
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Tue, 20 Feb 2001 14:19:01 -0500

The "c" field can be neglected, the connection field can appear in the SDP
"media description". We can live without "c" field. The SDP is must for
identifying the type of termination when the TerminationId is $. We need to
answer this too.
Best Regards.
Madhubabu

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Rosen, Brian
Sent: Tuesday, February 20, 2001 11:36 AM
To: [email-masked]'
Subject: SDP on Physical Terminations

   Transaction = 9999

       Context = -

           Modify = A4444

               Media { Stream = 1

                        LocalControl

                            Mode = SendReceive,
                            tdmc/gain=2,  ; in dB,
                            tdmc/ec=on
                        },
                        Local

   v=0
   c=IN IP4 $
   m=audio $ RTP/AVP 0

Brian

---

From: Troy Cauble <[email-masked]>
Date: Tue, 20 Feb 2001 14:30:53 -0500

> Another, less extreme suggestion would be most welcome.

I think the problem is more general than the physical case.  
Using SDP in the LocalDescriptor from the MGC to the MG is 
more trouble than it's worth.

If you look at the *typical* RTP usage, there's five pieces 
of information that COULD be extracted:
	host
	port
	mode
	payload
	packetization

In the context of an RTP LocalDescriptor sent from the MGC 
to the MG, the first two will always be CHOOSE,  and "mode" 
has already been moved to the LocalControlDescriptor.  
(BTW, what happens if the a=<mode> line is present and 
doesn't match the LCD??)

This leaves us with several lines of data to specify two
things, payload and packetization.  It also causes us to 
contort the SDP specs looking for ways to over/underspecify 
them.

I think the correct answer (although perhaps not what you 
consider "less extreme") is to stop using the LocalDescriptor
in the MGC -> MG direction and add these elements to the 
LocalControlDescriptor (like someone did with "mode").  
BTW, the MGCP approach is similar.

Your Physical example makes it even more clear that SDP
is the wrong way to do this.

-troy

---

From: Troy Cauble <[email-masked]>
Date: Tue, 20 Feb 2001 14:59:22 -0500

> is the wrong way to do this.

Several quotes from RFC2327 seems to indicates it's for DESCRIBING
sessions, not NEGOTIATING them.

   ...a session directory tool
   is used to advertise multimedia conferences and communicate the
              ^^^^^^^^^
   conference addresses and conference tool-specific information
   necessary for participation.  This document defines a session
   description protocol for this purpose...

   SDP is not intended for negotiation of media encodings.
                           ^^^^^^^^^^^

   Session directories assist the advertisement of conference sessions
                                  ^^^^^^^^^^^^^
   and communicate the relevant conference setup information to
   prospective participants.  SDP is designed to convey such information
   to recipients.  SDP is purely a format for session description...

   However, it is not intended to
   support negotiation of session content or media encodings - this is
           ^^^^^^^^^^^
   viewed as outside the scope of session description.

-troy