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

From: Tom Taylor <[email-masked]>
Date: Fri, 07 Jan 2005 09:21:07 -0500

Hi, Satish:

Sorry for the long gap: business travel, vacation, holidays ...
I've deleted the items we agree on.  Maybe we can clear up the others.

Mundra, Satish wrote:
...
> 
>>> 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.
> 
[PTT]
The "waiting" to set the E-bit extends only so far as the retransmission interval.
  The E-bit is set as of the first retransmission, and I'll make sure the text says
that.  That ends the tone as far as the receiver is concerned (2.5.2.2).  I agree
that the number of E-bit transmissions is limited to two.  Would you prefer that
the text require a total of three E-bit transmissions, even if that means that the
final event is sent a total of four times?

...

> ....
> 
>> [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 ?]

[PTT] Yes
> 
> 
>> 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.
>
[PTT] At the most, I would bless this with a MAY at the receiver's end, and 
continue to make E-bit setting a MUST at the sender's end (with the 
mutually-exclusive state exception).  I think to do otherwise would complicate the 
sender unnecessarily.

> 
>>> 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.
> 
[PTT] Not worth arguing over.  I'll delete the sentence beginning: "This is 
particularly worthwhile ...".

> 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.
> 
[PTT] I'll rework the offsets in the example.  Perhaps I can justify the use of 
the ringback event by saying: "Suppose that an event has been defined for 
ringback."  It does have the virtue of being something that can realistically last 
for a long time.

> Thanks and regards,
> Satish Mundra

-- 
Tom Taylor
Carrier VoIP Standards Development
Nortel Networks
Phone +1 613 763 1496  (ESN 393-1496)
E-mail: [email-masked]

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

---

From: "Mundra, Satish" <[email-masked]>
Date: Sat, 8 Jan 2005 13:48:29 -0600

My comments inline (deleted older comments for clarity)...

> -----Original Message-----
> From: Tom Taylor [mailto:[email-masked]] 
> Sent: Friday, January 07, 2005 9:21 AM

....
>   The E-bit is set as of the first retransmission, and I'll 
> make sure the text says that.  That ends the tone as far as 
> the receiver is concerned (2.5.2.2).  I agree that the number 
> of E-bit transmissions is limited to two.  Would you prefer 
> that the text require a total of three E-bit transmissions, 
> even if that means that the final event is sent a total of four times?
> 

Clarifying text should be fine. 
I just wanted to point out that the delay of one retransmission 
interval for setting E-bit may help only those receivers that use 
first algorithm of section 2.5.2.2 for playout. For receivers using
the second algorithm, it has opposite effect. Increasing the number 
of re-transmission is not required as the tone would not be extended 
for more than three interarrival periods and would end anyway.   
     
> > 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.
> >
> [PTT] At the most, I would bless this with a MAY at the 
> receiver's end, and continue to make E-bit setting a MUST at 
> the sender's end (with the mutually-exclusive state 
> exception).  I think to do otherwise would complicate the 
> sender unnecessarily.
> 

Yes, MAY at the receiver's end should be fine. The choice for sender 
would be between RE-transmissions or switch to audio payload, and not 
the original transmission which is a MUST. 

> particularly worthwhile ...".

Ok. 
 
> ringback."  It does have the virtue of being something that 

Ok.

Regards,

Satish