Subject: RE: [Rmt] EXT_TIME: a new HE for timing information in LCT

From: [email-masked]
Date: Wed, 1 Feb 2006 13:06:22 +0200

Hello Vincent and the rest of RMT WG,

Analyzing the current 3GPP, DVB and OMA specifications making use of
ALC/LCT, I found that the change you proposed does not break anything.
That is, the following specifications do not make use of either SCT or
ERT.

DVB Document A099, "IP Datacast over DVB-H: Electronic Service Guide
(ESG)"
 *
http://www.dvb-h-online.org/PDF/a099.tm3348r2.cbms1199r14.IPDC_ESG.pdf

DVB Document A101, "IP Datacast over DVB-H: Content Delivery Protocols
(CDP)"
 *
http://www.dvb-h-online.org/PDF/a101.tm3350r3.cbms1167r12.IPDC_Content_D
elivery_Protocols.pdf

Open Mobile Alliance, "Service Guide for Mobile Broadcast Services -
Draft Version 1.0"
 *
http://member.openmobilealliance.org/ftp/public_documents/bac/BCAST/Perm
anent_documents/OMA-TS-BCAST_Service-Guide-V1_0_0-20060106-D.zip

Open Mobile Alliance, "File Distribution and Stream Distribution - Draft
Version 1.0"
 *
http://member.openmobilealliance.org/ftp/public_documents/bac/BCAST/Perm
anent_documents/OMA-TS-BCAST-Distribution-V1_0_0-20060106-D.zip

The only specification I found using SCT and ERT is:

3GPP TS 26.346 V6.3.0 (2005-12), "3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects; Multimedia
Broadcast/Multicast Service (MBMS); Protocols and codecs (Release 6)"
 * http://www.3gpp.org/ftp/Specs/latest/Rel-6/26_series/26346-630.zip

In that spec:
 - The use of ERT is truly optional for both FLUTE client and FLUTE
server.
 - The use of SCT is optional for FLUTE server but mandatory for FLUTE
client.

However, the proposed change (i.e. EXT_TIME) does not remove the
LCT-inherent capability to signal SCT. It just does it in more generic
way. Therefore, I think it is just a matter of a very simple spec
maintenance issue to update the 3GPP spec TS 26.346 to refer to EXT_TIME
carrying SCT rather than using SCT field.

I very much support Vincent's initiative to generalize the time-related
signaling in LCT header. To me, this simplifies the design as well as
makes LCT more flexible and extensible.

Regards,
 Toni

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Vincent Roca
>Sent: 31 January, 2006 17:18
>To: [email-masked]
>Subject: [Rmt] EXT_TIME: a new HE for timing information in LCT
>
>Dear Mark et al.
>
>Here is the follow-up of a discussion we had in December on 
>the possibility of defining a new header extension for LCT to 
>carry several kinds of timing information.
>Cheers,
>
>    Vincent / Toni / Rod
>
>

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: <[email-masked]>
Date: Wed, 22 Feb 2006 14:15:37 +0200

1 note and 1 change...

Please note, FLUTE (§3.1) makes the TOI field mandatory (except for A flag packets with no payload), which basically mean ERT is only for objects/files in FLUTE and never for sessions. I am not sure that this is widely understood. Any problem with that? (Remember that ERT is now in seconds and not in milliseconds as before).

Also, in our proposed text §3 only mentions ERT for sessions (it should also mention objects) and §4.2 is fine (but a little confusing when you only think about FLUTE :). (§5.2.2 is correct and unambiguous).

I recommend this change to §3:
"the Expected Residual Time (ERT) conveys the amount of time the session will be continued for,..."
 -> 
"the Expected Residual Time (ERT) conveys the amount of time either the session or transmission object will be continued for,..."

Cheers, rod.