[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] Re: RFC 2833: Is there a way to handle tones with a dur ation over 8 a pproximately seconds?
Also, if we follow same logic, we set marker bit only for the first packet.
Also the time-stamp should be changed to reflect where the next duration is
referenced from.
Correct ?
-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent: Tuesday, October 22, 2002 6:48 PM
To: Prabhu, Raghavendra; avt@ietf.org
Subject: Re: [AVT] Re: RFC 2833: Is there a way to handle tones with a
dur ation over 8 a pproximately seconds?
The basic question you raise is whether to set the E bit only at the end
of the long event. I think that makes sense. The idea of the bit is to
signal to the application that it's safe to hand the event to the
next-higher layer. Clearly, this is a rare corner case, at least for
DTMF. (It might occur for some of the line events.)
Prabhu, Raghavendra wrote:
> Hi ,
>
> I agree that this will not likely happen in the real world. However, the
> reverse consequence maybe realistic. An example: Lets say a user wants to
> dial '91' with legal interdigit spacing, the '1' lasting approx 16 secs at
> 8000Hz sampling rate.
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | digit |E R| volume | duration |
> | 9 |1 0| 10 | 1600 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> | Interdigit time |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | digit |E R| volume | duration |
> | 1 |1 0| 10 | 0xFFFF |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> | No gap |
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | digit |E R| volume | duration |
> | 1 |1 0| 10 | 0xFFFF |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> According to approach (1), this should be deciphered as 2 events: '9'
> followed by '1' since there was no gap between the two '1' events. To do
> this, the receiving end should ignore the End bit (End bit means 'End of
> event') when there is no gap between two events. Is this the general
> understanding (or) should the E-bit not be set ?
>
>
> Thanks
> Raghavendra
>
> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Tuesday, October 22, 2002 5:20 PM
> To: Prabhu, Raghavendra
> Cc: avt@ietf.org
> Subject: Re: [AVT] Re: RFC 2833: Is there a way to handle tones with a
> dur ation over 8 a pproximately seconds?
>
>
> For real DTMF digits, there is a minimum interdigit spacing. I believe
> it's somewhere between 20 and 50 ms. Thus, such contiguous digits should
> never occur in the PSTN.
>
> Prabhu, Raghavendra wrote:
>
>>If using approach (1) below, How do you distinguish between two same
>
> Events
>
>>like digit '1' in '911' with no (noticeable) gaps between the events ? If
>>bis-01 went with approach (1), implementations would(should ?) recognize
>>'91'.
>>
>>
>>-----Original Message-----
>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
>>Sent: Monday, October 21, 2002 1:11 PM
>>To: Paul Smith; avt@ietf.org
>>Subject: [AVT] Re: RFC 2833: Is there a way to handle tones with a
>>duration over 8 a pproximately seconds?
>>
>>
>>(Cc'ing AVT, for general input)
>>
>>There are, I believe, two approaches:
>>
>>(1) have two or more contiguous tones of 8 seconds each. You will be
>>able able tell from the timestamps that there was no gap, i.e., that
>>this is one tone instead of two;
>>
>>(2) define a different, lower sampling rate for the event 'codec' if it
>>is anticipated that tones could last longer than 8 seconds.
>>
>>I'm adding wording on (1) to bis-01.
>>
>>How common is this, btw?
>>
>>Paul Smith wrote:
>>
>>
>>
>>>Mr. Schulzrinne,
>>>Since a DTMF tone can last longer than 8 seconds: How should this be
>>>handled?
>>>
>>>>From RFC 2833:
>>>3.5 Payload Format
>>>duration: Duration of this digit, in timestamp units. Thus, the event
>>>began
>>>at the instant identified by the RTP timestamp and has so far lasted
>>>as long
>>>as indicated by this parameter. The event may or may not have ended. For
a
>>>sampling rate of 8000 Hz, this field is sufficient to express event
>>>durations of up to approximately 8 seconds.
>>>E: If set to a value of one, the "end" bit indicates that this packet
>>>contains the end of the event. Thus, the duration parameter above
measures
>>>the complete duration of the event.
>>>
>>>Thank you for your time,
>>>Paul Smith
>>
>>
>>
>>_______________________________________________
>>Audio/Video Transport Working Group
>>avt@ietf.org
>>https://www1.ietf.org/mailman/listinfo/avt
>>_______________________________________________
>>Audio/Video Transport Working Group
>>avt@ietf.org
>>https://www1.ietf.org/mailman/listinfo/avt
>
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt