Subject: [AVT] Doubt in RFC2833 and in related things

From: "Ponraj" <[email-masked]>
Date: Thu, 20 Dec 2001 18:23:57 +0530

Hello all,

I have some questions in RTP and RTP related things,

1. I would like to know the people who have implemented RFC2833 fully, for transferring named events and telephony tones. And who have implemented the RFC2198? Redundancy header mechanism. (Sorry, These questions already asked in this group on july 6th. The answer was given only for DTMF digits, but it must be implemented by all the systems). This is to design and test interoperability with other implementations.

2. I assume that single dynamic payload type can be used for all named events(digits, fax tones, line events, etc. 0-15, 32-49, 64-89 etc). Is there any system which will assign different dynamic payload types(more than one) for named events? i.e. dynamic payload type 109 for event 89(ring) and 110 for event 66(dial tone). Note that both events are same type(E.182 line events).

3. How to propose dynamic payload types for events and telephoney tones while establishing connection through SDP? 

4. What is the difference between header extension and redundancy header?

Your answer will be much helpful to me

Thanks and regards,
R.Ponraj

---

From: "Suresh H.B" <[email-masked]>
Date: Thu, 20 Dec 2001 20:53:38 +0530

my comments follows after each question.

-Suresh
  ----- Original Message -----
  From: Ponraj
  To: [email-masked] ; [email-masked]
  Sent: Thursday, December 20, 2001 6:23 PM
  Subject: [AVT] Doubt in RFC2833 and in related things

  Hello all,

  1. I would like to know the people who have implemented RFC2833 fully, for
transferring named events and telephony tones. And who have implemented the
RFC2198? Redundancy header mechanism. (Sorry, These questions already asked
in this group on july 6th. The answer was given only for DTMF digits, but it
must be implemented by all the systems). This is to design and test
interoperability with other implementations.

  I guess, it is not mandatory to implement RFC2198 those who have
implemented RFC2833.But by implementing RFC2198 both telephony tone and
named events payload types can be combined into a single payload apart from
additional security considerations that are described in RFC2198.

  2. I assume that single dynamic payload type can be used for all named
events(digits, fax tones, line events, etc. 0-15, 32-49, 64-89 etc). Is
there any system which will assign different dynamic payload types(more than
one) for named events? i.e. dynamic payload type 109 for event 89(ring) and
110 for event 66(dial tone). Note that both events are same type(E.182 line
events).

  I don't think any system will assign different dynamic payload types(more
than one) for named events.There will be one dynamic payload type for named
events and another one dynamic payload type for telephony tones .[I would
like to know what prompted you to ask this question(which section in
RFC?).]

  3. How to propose dynamic payload types for events and telephoney tones
while establishing connection through SDP?

  I guess u can get the answer for above question by reading section 3.9
from RFC2833.

     For example, if the payload format uses the payload type number 100,
and the implementation can handle the DTMF tones (events 0 through
     15) and the dial and ringing tones, it would include the following
description in its SDP message:

     a=fmtp:100 0-15,66,70

  header extension and redundancy header both are same..and all the
redundancy information for a packet in a header  extension would make it
easy for applications that do not implement redundancy to discard it and
just process the primary encoding data.

  Thanks and regards,
  R.Ponraj

---

From: "Ponraj" <[email-masked]>
Date: Thu, 20 Dec 2001 21:52:29 +0530

Thank you verymuch Mr. Suresh,

Why I asked the 2nd question is, I thought more than one proposal can be send.

Eg.  Iitiator(sender) is proposing dynamic payload type as
a=fmtp:100 0-15,66,70
If this attribute is received once means, the  receiver can decide that the dynamic payload 100 is used to transfer the events 0-15, 66 and 70. 
If it receives a=fmtp:101 38, 39 again means, 101 for Fax related events.
There is no restriction specified in RFC. If the fmtp(attribute) can be send only once means, OK. Will it comes more than once?

Then, I have another question,
If it is named event we can give the format specific things after the paylod type.
like, a=fmtp:100 <format specific parameters>

What will be in the place of <format specific parameters> for telephony tones. ?

Thanks and regards,
R.Ponraj

  ----- Original Message ----- 
  From: Suresh H.B 
  To: Ponraj ; [email-masked] ; [email-masked] 
  Sent: Thursday, December 20, 2001 8:53 PM
  Subject: Re: [AVT] Doubt in RFC2833 and in related things

  -Suresh
    ----- Original Message ----- 
    From: Ponraj 
    To: [email-masked] ; [email-masked] 
    Sent: Thursday, December 20, 2001 6:23 PM
    Subject: [AVT] Doubt in RFC2833 and in related things

    Hello all,

    I guess, it is not mandatory to implement RFC2198 those who have implemented RFC2833.But by implementing RFC2198 both telephony tone and named events payload types can be combined into a single payload apart from additional security considerations that are described in RFC2198.

    I don't think any system will assign different dynamic payload types(more than one) for named events.There will be one dynamic payload type for named events and another one dynamic payload type for telephony tones .[I would like to know what prompted you to ask this question(which section in  RFC?).]

    I guess u can get the answer for above question by reading section 3.9 from RFC2833.

       For example, if the payload format uses the payload type number 100, and the implementation can handle the DTMF tones (events 0 through
       15) and the dial and ringing tones, it would include the following description in its SDP message:

       a=fmtp:100 0-15,66,70

    header extension and redundancy header both are same..and all the redundancy information for a packet in a header  extension would make it easy for applications that do not implement redundancy to discard it and just process the primary encoding data.

    Thanks and regards,
    R.Ponraj

---

From: Wayne Mills <[email-masked]>
Date: Thu, 20 Dec 2001 12:17:14 -0500

If a multi-payload implementation such as your proposal were to try
interoperating with a single-payload implementation, that SDP parser
might balk at more than 1 payload type because of the rtpmap lines.  In
other words, a combination like the one shown below might cause a
conflict with payload-to-app binding in an SDP parser:

    a=rtpmap: 100 telephone-event
    a=fmtp:100 0-15
    a=rtpmap: 101 telephone-event
    a=fmtp:101 38,39

I'm not sure what multiple payload types buy you in implementation.  I
would think it would be just as easy for an RTP event handler to route
events based on event ranges (i.e., 0-15 for DTMF) vs. unique payload
types (i.e., payload type 100 for DTMF).

Regards,
Wayne

Ponraj wrote:

> Thank you verymuch Mr. Suresh, Why I asked the 2nd question is, I
> thought more than one proposal can be send.
>   Eg.  Iitiator(sender) is proposing dynamic payload type asa=fmtp:100
> 0-15,66,70If this attribute is received once means, the  receiver can
> decide that the dynamic payload 100 is used to transfer the events
> 0-15, 66 and 70.If it receives a=fmtp:101 38, 39 again means, 101 for
> Fax related events.There is no restriction specified in RFC. If the
> fmtp(attribute) can be send only once means, OK. Will it comes more
> than once? Then, I have another question,If it is named event we can
> give the format specific things after the paylod type.like, a=fmtp:100
> <format specific parameters> What will be in the place of <format
> specific parameters> for telephony tones. ? Thanks and
> regards,R.Ponraj
>
>        my comments follows after each question. -Suresh
>
>            Hello all, I have some questions in RTP and RTP
>           related things, 1. I would like to know the people
>           who have implemented RFC2833 fully, for
>           transferring named events and telephony tones. And
>           who have implemented the RFC2198? Redundancy
>           header mechanism. (Sorry, These questions already
>           asked in this group on july 6th. The answer was
>           given only for DTMF digits, but it must be
>           implemented by all the systems). This is to design
>           and test interoperability with other
>           implementations. I guess, it is not mandatory to
>           implement RFC2198 those who have implemented
>           RFC2833.But by implementing RFC2198 both telephony
>           tone and named events payload types can be
>           combined into a single payload apart from
>           additional security considerations that are
>           described in RFC2198.  2. I assume that single
>           dynamic payload type can be used for all named
>           events(digits, fax tones, line events, etc. 0-15,
>           32-49, 64-89 etc). Is there any system which will
>           assign different dynamic payload types(more than
>           one) for named events? i.e. dynamic payload type
>           109 for event 89(ring) and 110 for event 66(dial
>           tone). Note that both events are same type(E.182
>           line events). I don't think any system will assign
>           different dynamic payload types(more than one) for
>           named events.There will be one dynamic payload
>           type for named events and another one dynamic
>           payload type for telephony tones .[I would like to
>           know what prompted you to ask this question(which
>           section in  RFC?).] 3. How to propose dynamic
>           payload types for events and telephoney tones
>           while establishing connection through SDP? I guess
>           u can get the answer for above question by reading
>           section 3.9 from RFC2833.    For example, if the
>           payload format uses the payload type number 100,
>              15) and the dial and ringing tones, it would
>           include the following description in its SDP
>           message:    a=fmtp:100 0-15,66,70 4. What is the
>           difference between header extension and redundancy
>           header? header extension and redundancy header
>           both are same..and all the redundancy information
>           for a packet in a header  extension would make it
>           easy for applications that do not implement
>           redundancy to discard it and just process the
>           primary encoding data. Your answer will be much
>           helpful to me Thanks and regards,
>           R.Ponraj
>

---

From: HK <[email-masked]>
Date: Thu, 20 Dec 2001 11:27:53 -0800 (PST)

Hi,
  I have general questions in this regard:
    1. When a packet is transmitted from the source is
there a time stamp for it? If so what is the
resolution?
    2. When the packet is received will it be time
stamped as Received time stamp and what is its
resolution?
Assuming 10msecs RTP packet!
    3. For adaptive jitter buffer scheme what are the
inputs Do we require Transmitted Time Stamps also?

Thanks in Advance
HK

--- "Suresh H.B" <[email-masked]> wrote:
> who have implemented the
> described in RFC2198.
> 32-49, 64-89 etc). Is
> include the following
> redundancy to discard it and
-----------------------------------------------------------------------------------------------------------------------
> Information transmitted by this E-MAIL is
> proprietary to Wipro and/or its Customers and
> is intended for use only by the individual or entity
> to which it is
> addressed, and may contain information that is
> privileged, confidential or
> exempt from disclosure under applicable law. If you
> are not the intended
> recipient or it appears that this mail has been
> forwarded to you without
> proper authority, you are notified that any use or
> dissemination of this
> information in any manner is strictly prohibited. In
> such cases, please
> notify us immediately at mailto:[email-masked]
> and delete this mail
> from your records.
>
------------------------------------------------------------------------------------------------------------------------

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

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