Subject: Re: RE: [AVT] RE: [Rtp] payload type

From: "kiran lati" <[email-masked]>
Date: 7 Sep 2001 04:42:20 -0000

what does it  mean by "but the actual numbers are negotiated during call setup."

does the payload formart for telephony tones which is mentioned in section 4.4 of RFC2833implemented in the vovida source code?

On Thu, 06 Sep 2001 Miao, Kai wrote :
>RFC2833 gives you the (dynamic) payload (registered) 
>types, but the actual
>numbers are negotiated during call setup.
>
>Kai Miao
>
>-----Original Message-----
>From: Sandeep Sahai [mailto:[email-masked]]
>Sent: Thursday, September 06, 2001 12:17 PM
>To: 'kiran lati'; [email-masked]; [email-masked]
>Subject: [AVT] RE: [Rtp] payload type
>
>
>Hi
>Refer to rfc 2833, which deal with RTP Payload for DTMF 
>Digits, Telephony
>Tones and Telephony Signals.
>
>I think you will find the information you requested.
>
>Thanks
>Sandeep Sahai
>
>-----Original Message-----
>From: kiran lati [mailto:[email-masked]]
>Sent: Thursday, September 06, 2001 8:40 AM
>To: [email-masked]; [email-masked]
>Subject: [Rtp] payload type
>
>
>Hi all,
>
>what is the payload type number for DTMF events and for 
>telephony tones. is it defined some where or can we use 
>any number between
>96 to 127.
>
>does the payload formart for telephony tones 
>implemented in the vovida
>source code?
>
>pls clarify asap.
>thanx in advance
>
>-Kiran.L 
>
> 
>
>
>
>_______________________________________________
>rtp mailing list
>[email-masked]
>http://www.vovida.org/mailman/listinfo/rtp
>
>_______________________________________________
>Audio/Video Transport Working Group
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/avt
>
>_______________________________________________
>Audio/Video Transport Working Group
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www1.ietf.org/mailman/listinfo/avt

---

From: "Dan Firac" <[email-masked]>
Date: Fri, 7 Sep 2001 09:26:28 +0300

They are not NEGOTIATED but PROPOSED through SDP. A part of a session
description describing  DTMF channel would look like:
m=audio 47900 RTP/AVP 111
a=rtpmap:111 telephony-events
a=fmtp:111 0-15

This means that I can receive on port 47900 RTP packets having the format
described in RFC2833 and carrying telephony events from 0 to 15 (which are
infact the digits). Using the 'fmtp' attribute you can select other events
you may want receive.
The dynamic payload type(111) is chosed to be a random number between 96-127
and has to be different from other dynamic payload typed you have defined in
your entire SDP message. That's all.

Anyway see RFC2833.

Best regards,
Dan.

----- Original Message -----
From: "kiran lati" <[email-masked]>
To: "Miao,Kai" <[email-masked]>
Cc: "'Sandeep Sahai'" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Friday, September 07, 2001 7:42 AM
Subject: Re: RE: [AVT] RE: [Rtp] payload type

what does it  mean by "but the actual numbers are negotiated during call
setup."

does the payload formart for telephony tones which is mentioned in section
4.4 of RFC2833implemented in the vovida source code?

---

From: "Adam Li" <[email-masked]>
Date: Thu, 6 Sep 2001 23:49:56 -0700

> This means that I can receive on port 47900 RTP packets having the format
                        ^^^^^^^

The dynamic payload type should probably be selected by the sender not the
receiver I remember. Otherwise there will be trouble in multicast, for
example.

Adam

----------
Adam H. Li
Image Communication Lab                    (310) 825-5178 (Lab)
University of California, Los Angeles      (310) 825-7928 (Fax)

---

From: "Dan Firac" <[email-masked]>
Date: Fri, 7 Sep 2001 10:06:52 +0300

see comments below,

----- Original Message -----
From: "Adam Li" <[email-masked]>
To: "Dan Firac" <[email-masked]>; "kiran lati"
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 07, 2001 9:49 AM
Subject: RE: RE: [AVT] RE: [Rtp] payload type

> The dynamic payload type should probably be selected by the sender not the

^^^^^^^^
> receiver I remember. Otherwise there will be trouble in multicast, for

1. The INITIATOR(offerer) must select the dynamic PT. The SDP message
contains what it can to receive.
    The answerer uses the PT as is, and the DTMF channel is
accepted(port!=0)  or not (port=0).

2. Could you give me a practival example of using DTMF digits in a multicast
conference?
3. If there are two or more sources how would you mix DTMF digits ????

Dan.

---

From: "Adam Li" <[email-masked]>
Date: Fri, 7 Sep 2001 00:44:39 -0700

> 3. If there are two or more sources how would you mix DTMF digits ????

I am not familiar with DTMF RTP payload. Sorry I can not give a practical
example of using DTMF digits in multicast.

However, what I am trying to comment on is signalling of dynamic payload
type in general. Selecting of the dynamic payload type in a multicast
conference seems is better done by the sender I think.

The receiver should have no problem if it listens to two senders, which
happen to both select the same dynamic payload type number. The two RTP
streams will be coming in two seperate sessions (and two seperate ports). As
long as the dynamic payload type number is unique  for each SSRC, it should
be fine.

Just what I remembered from top of my head. I might be wrong, so please feel
free to correct me.

Adam

----------
Adam H. Li