Subject: [AVT] comments on draft-ietf-avt-rfc2833bis-06.txt

From: "Mundra, Satish" <[email-masked]>
Date: Tue, 30 Nov 2004 13:53:42 -0600

I have following comments on this draft:

1. Section 2.5.1.2 states:
   "Timing information is contained in the RTP timestamp, allowing 
   precise recovery of inter-event times.  Thus, the sender does not 
   need to maintain precise or consistent time intervals between event 
   packets." 

The section refers to "event packets" as those belonging to same event.
I 
think a sender needs to maintain consistent interval between event
packets 
as a receiver relies on the inter-arrival times to decide how long to
extend 
the tone when there are no event packets received. For e.g. if the
interval is 
changed from 10ms to 50ms then a receiver could timeout before the event
packet 
sent at new interval arrives. 

2. Section 2.5.1.4 states:
   "A sender MAY delay setting the "E" bit until retransmitting the last

   packet for a tone, rather than setting the bit on its first 
   transmission. This avoids having to wait to detect whether the tone 
   has indeed ended.  Once the sender has set the "E" bit for a packet, 
   it MUST continue to set the "E" bit for any further retransmissions 
   of that packet."

How is above different from a sender that does not re-transmit packets
with 
E-bit set? Assuming that receiver is using section2.5.2.2 alogorithm-2
for 
playout, isn't delaying the setting of E-bit going to cause tone
extension 
by 5*inter-arrival periods if the packet with E-bit set was lost ? 

3. Section 2.6.2 states:  
      "This approach allows dumb gateways that do not understand this

      format to function. See also the discussion in section 1."

This statement should be removed, as gateways first need to negotiate
the 
payloads via out-of-band means, hence the situation where dumb gateway
receives 
payload format that it does not understand should not arise.

4. Section 2.6.2 states:
   "The audio redundancy mechanism described in RFC 2198 [N-2] MAY be 
   used to recover from packet loss across events. For the suggested 
   packet gap of 50 ms, the effective data rate is r times 64 bits (32 
   bits for the redundancy header and 32 bits for the telephone-event 
   payload) plus 8 bits for the primary encoding every 50 ms or (r times

   1280 + 160) bits/second, where r is the number of redundant events 
   carried in each packet. The value of r is an implementation trade-
   off, with a value of 5 suggested."

I think calculations are for "effective increase in data rate" when
redundancy
is used and not effective data rate. The primary payload of 4 bytes is
not 
included in the above data rate.

5. Section 5.1 states:
   "Gateways which send signalling events via RTP MAY send both named 
   signals (section named) and the tone representation (section tones) 
   as a single RTP session, using the redundancy mechanism defined in 
   RFC 2198 [N-2] to interleave the two representations. It is generally

   a good idea to send both, since it allows the receiver to choose the 
   appropriate rendering." 
   
I think "a single RTP session" above should be changed to "in a single
RTP packet".

6. Section 5.2 states:
  "Events and Audio
      "The source sends events and encoded audio packets (e.g., PCMU or 
      the codec used for speech signals) for the same time instant. In 
      that mode, events are treated as redundant encodings for the 
      encoded audio stream."

As noted in section 2.5.2.2, encoded audio packets preceding the encoded

events can cause spurious digits/events and this mode allows the encoded

audio packets after the recognition of events and is probably going to 
increase the probability of spurious digits. Section 5.2 also recommends

using encoded tones rather than encoded audio for rendering tones. 
Why not disallow this mode?

7. Section 2.6 states: 
      "Section 2.6.2 describes how a summary of earlier events MAY be 
      carried in RFC 2198 redundancy payloads.  This is particularly 
      useful for sequences of short events, e.g., digits dialed by a 
      modem or autodialer or in-band tone signaling sequences (section 
      3.2 or 3.5)."

There is no section 3.5 in the new draft. What about redundancy when the

digits are not dialed by auto-dialer or modem and inter-digit interval
and 
dialing duration are not small, for e.g., calling card calls ? 

Regards,

Satish Mundra

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

---

From: "Mundra, Satish" <[email-masked]>
Date: Fri, 3 Dec 2004 08:22:48 -0600

Hi Tom,

Thanks your for your response to my previous comments/questions. 
[Sorry about double posting of earlier mail, my subscription id did not
mtach 
 the id I used for first posting and I forgot to withdraw that when I
did a repost.]

Please see below for some follow up comments/questions. 

> > 1. Section 2.5.1.2 states: "Timing information is contained 
.......
> [PTT begin]
> Good point.  How about if I add the following text to that paragraph:
> 
> "However, depending on the playout algorithm used, any 
> increase in time interval between sending of event packets 
> may result in gaps in or premature termination of tone 
> playout.  As a result, a new event packet for a continuing 
> event SHOULD be sent before the receiving end might be 
> expected to complete playout of the duration indicated by the 
> packets already sent.  Moreover, the duration reported in the 
> initial event packet SHOULD be larger than the expected 
> inter-event packet interval, to provide a buffer against 
> packet delays at the receiving end."
> [PTT end]
> 
Ok.

> > 2. Section 2.5.1.4 states: "A sender MAY delay setting the "E" bit 
......
> [PTT] I think that's just 3*inter-arrival periods, based on 
> the advice in 2.5.2.2. 
>   Don't forget that the final packet and its retransmissions 
> will all indicate the same total event duration, regardless 
> of the setting of the E-bit.  I agree that if the E-bit 
> appears in the first packet reflecting the end of the event 
> and that packet is not lost, there will be NO tone extension. 
>  How about if I modify the text above to say that:
> 
> "A sender MAY delay setting the "E" bit until the first 
> retransmission of the final packet of a tone, ..."
> 
> This is slightly more precise, and results in the E-bit being 
> set for both retransmissions.  If one packet is lost, the 
> worst-case extension is now just 2xinter-arrival interval.
> 

I see that motivation for this change is to avoid sender having to wait
to see 
if the tone has indeed ended. Does this mean that a sender can send
consecutive 
packets with same duration "X" and then find out that tone has not
really ended 
and start incrementing the duration ? 
If this is the case then, the receiver still has to rely on E-bit, the
above change 
effectively reduced the number of E-bit retransmissions to two ? I don't
see benefit
of this change.  

> > 
> > 3. Section 2.6.2 states: "This approach allows dumb 
..... 
> [PTT] OK with me.  This is original RFC 2833 text, but 
> perhaps these days we have a clearer idea of our architecture.
> 
Agreed.

> > 4. Section 2.6.2 states: "The audio redundancy mechanism 
> 
> [PTT] Agreed.
> 
OK.

> > 
> > 5. Section 5.1 states: "Gateways which send signalling 
> 
> [PTT] Agreed.
> 
OK.

> > 
> > 6. Section 5.2 states: "Events and Audio "The source sends 
....
> [PTT] The apparently contradictory advice at the end of 5.2 
> actually refers to 
> receiver behaviour, where the earlier part refers to sender 
> strategy.  I would 
> expect the type of situation where you would send both tones 
> and events would be a 
> data transmission case such as transmission of V.21 bits, 
> where the receiver is 
> going to have to make a transition to audio anyway and the 
> combined encoding 
> allows it to pick the point at which it does that.  Another 
> point to consider: by 
> an argument you made earlier, combinations like this will 
> occur only with the 
> receiver's consent (as a result of out-of-band negotiation).
> 
It was not clear that this mode is to be used only if negotiated.
May be some examples of negotiation mechanism to be used or reference 
to same or an Offer/Answer section in the draft would really help.

> I'd suggest that maybe I should add a few words to say that 
> where the RTP packet 
> contains both audio and event data, the receiver must decide 
[You mean when sender transmits both event data and audio data for 
same time instant ?] 

> when to transition to 
> event playout and when to audio based on consideration of the 
> type of events being 
> reported.
> 

I have another related question on above. Assuming that this mode was
not negotaited, can a receiver use of recetion of audio packets (with
higher seq#)
to conclude that event has ended ? This way a sender can choose between
re-transmissions
Of E-bit packets or switching to audio endcoding and either behavior
would 
terminate the event.   

> > 
> > 7. Section 2.6 states: "Section 2.6.2 describes how a 
......
> [PTT] Thanks for the catch -- the 3.5 reference goes out.  To 
> justify the 
> reference to section 3.2 I'll add some mention of data 
> signals.  As to your main 
> point, I'm not sure how much extra information redundancy 
> gives you when most of 
> it is just earlier reports of the same event.  This does let 
> you catch 'M' and 'E' 
> bits that might otherwise be lost, but in between, the latest 
> event report pretty 
> well tells you all you need to know.  So redundancy is less 
> useful in the case of 
> spread-out events than when they have short duration and 
> follow one another at 
> short intervals.
> > 
Consider an example of calling card calls. You would first reach a
IP-IVR host, and 
then there may be password and 10-12 digit destination number that you
want to reach. 
I think the manual dialing typically would have inter-digit times that
could be 3-4 
seconds. 

Another comment on Section 5.4.2:

The example uses 16383 as offset to represent a named event that started
7.5 seconds earlier.
I believe this topic came up earlier and as per Colin Perkins "I don't
think this is appropriate, 
since it overloads the semantics of the RTP timestamp.".
The new draft does not define named event code for ringback, so I am not
sure if the 
example should use that.  

Thanks and regards,

Satish Mundra