- From: 김성혜 <shkim@etri.re.kr>
- Date: Mon, 14 Sep 2015 07:55:22 +0000
- To: "HU, BIN" <bh526r@att.com>, Paul Higgs <paul.higgs@ericsson.com>
- CC: TV Control API Community Group <public-tvapi@w3.org>
- Message-ID: <609FE8B8E7BD1248A27BD3B8BC699ABD1D76DEA1@SMTP1.etri.info>
For [cas.notifications] & [cas.notifications.change] requirements, I have proposed to add event to the TVChannel.
I did not get any comments on this proposal.
Any comments are welcome. Thanks.
Regards,
Sung Hei Kim
[Changes to the TVChannel]
Interface TVChannel: EventTarget {
:
attribute EventHandler onCIcardchanged;
:
}
[New Event]
Event Handler: onCIcardchanged
Event name: CI_CHANGE
Event type: TVCICardChangedEvent
Description: Handles the information for the dynamically added/removed common interface (CI) cards.
XX. TVCICardChangedEvent Interface
The TVCICardChangedEvent interface represents the events related to the changes in the state of the CI cards.
Interface TVCICardChangedEvent : Event {
readonly attribute TVCICardState state;
readonly attribute DOMString? casSystemId;
}
enum TVCICardState {
"CIcard-inserted",
"CIcard-removed',
};
Enumeration description
CIcard-inserted : The state that CI Card is inserted
CIcard-removed : The state that CI Card is removed
-----------------------
________________________________
보낸 사람 : "HU, BIN" <bh526r@att.com>
보낸 날짜 : 2015-09-12 01:50:22 ( +09:00 )
받는 사람 : Paul Higgs <paul.higgs@ericsson.com>, 김성혜 <shkim@etri.re.kr>
참조 : TV Control API Community Group <public-tvapi@w3.org>
제목 : RE: tvapi-ACTION-38: Propose an api spec for conditional access systems
Thank you Paul and Sung Hei for the great work and discussion.
Have we had an agreement here?
Thank you and have a great weekend
Bin
From: Paul Higgs [mailto:paul.higgs@ericsson.com]
Sent: Thursday, September 03, 2015 5:45 AM
To: 김성혜
Cc: TV Control API Community Group
Subject: RE: tvapi-ACTION-38: Propose an api spec for conditional access systems
Hi Sung Hei
I could not see that a TVChannel needed more than just a single attribute indicating with CA system is in use (essentially the tuner can copy this from the received TS).
The caCardInUse for a channel is an index to the sequence of installed cards. It is an easy way for the WebApp to determine what CI card the STB has assigned to the channel. This could be useful when there are multiple CI cards in an STB
Paul
From: 김성혜[mailto:shkim@etri.re.kr]
Sent: Thursday, September 03, 2015 8:18 AM
To: Paul Higgs
Cc: TV Control API Community Group
Subject: Re: tvapi-ACTION-38: Propose an api spec for conditional access systems
I have used "TVCICardInformation dictionary" to consider extension for future version.
Anyway, it would much simplier to add “CA_system_ID” as an attribute.
I am OK with whatever type of API is used.
What is "caCardInUse"? Is it the index of the slot?
I do not know exactly how the STB know which card to use for decryption.
I am thinking (in common sense), STB is preconfigured with the CA card used for TV source.
For example, when STB is set to the DVB cable mode, it use CA Card only from slot n.
I think this should be checked anyway.
Regards,
Sung Hei Kim
2015. 9. 2., 오후 7:19, Paul Higgs <paul.higgs@ericsson.com<mailto:paul.higgs@ericsson.com>> 작성:
Hi Sung Hei
I agree that the CA_PID could be used by some WebApp based “protocol analyzer” but this is just one piece of information that such a WebApp would need.
My recommendation would be to add a CA_system_ID attribute to the TVChannel interface which denotes what CA system is currently needed/inuse to decrypt the channel. We could also add a CACard to the TVChannel to indicate which CA Card is currently being used to decrypt the channel (this CACard would be the index into the array of CACards in the system), however it may not provide anything useful – I think Kaz mentioned that in Japan some devices have 8 CA Card slots, but I don’t know if each card has a different CA_system_ID or not.
interface TVChannel : EventTarget {
Promise<sequence<TVProgram<http://w3c.github.io/tvapi/spec/#idl-def-TVProgram>>> getPrograms<http://w3c.github.io/tvapi/spec/#widl-TVChannel-getPrograms-Promise-sequence-TVProgram---TVGetProgramsOptions-options> (optional TVGetProgramsOptions<http://w3c.github.io/tvapi/spec/#idl-def-TVGetProgramsOptions> options);
Promise<TVProgram<http://w3c.github.io/tvapi/spec/#idl-def-TVProgram>> getCurrentProgram<http://w3c.github.io/tvapi/spec/#widl-TVChannel-getCurrentProgram-Promise-TVProgram> ();
readonly attribute DOMString networkId<http://w3c.github.io/tvapi/spec/#widl-TVChannel-networkId>;
readonly attribute DOMString transportStreamId<http://w3c.github.io/tvapi/spec/#widl-TVChannel-transportStreamId>;
readonly attribute DOMString serviceId<http://w3c.github.io/tvapi/spec/#widl-TVChannel-serviceId>;
readonly attribute TVSource<http://w3c.github.io/tvapi/spec/#idl-def-TVSource> source<http://w3c.github.io/tvapi/spec/#widl-TVChannel-source>;
readonly attribute TVChannelType<http://w3c.github.io/tvapi/spec/#idl-def-TVChannelType> type<http://w3c.github.io/tvapi/spec/#widl-TVChannel-type>;
readonly attribute DOMString name<http://w3c.github.io/tvapi/spec/#widl-TVChannel-name>;
readonly attribute DOMString number<http://w3c.github.io/tvapi/spec/#widl-TVChannel-number>;
readonly attribute boolean isEmergency<http://w3c.github.io/tvapi/spec/#widl-TVChannel-isEmergency>;
readonly attribute boolean isFree<http://w3c.github.io/tvapi/spec/#widl-TVChannel-isFree>;
readonly attribute unsigned short CA_system_ID;
readonly attribute unsigned short caCardInUse;
};
You are correct that we do not have a formal requirement for Events when the content stream changes from unscrambled -> scrambled etc.. The UA can certainly implement some specific “banner screen” for this – I presume the MediaSource output from the TVTuner can do this.
I leave it to the editor to determine if we should have such an event and allow the WebApp to inform the user.
Paul
From: 김성혜 [mailto:shkim@etri.re.kr]
Sent: Wednesday, September 02, 2015 4:07 AM
To: Paul Higgs; TV Control API Community Group
Subject: RE: tvapi-ACTION-38: Propose an api spec for conditional access systems
Thank you Paul for your comments.
I have made comments inline.
Also, I have made changes to the CAS APIs based on the meeting results and comment from Paul, which follows the in-line comments.
Please see the changes.
Regards,
Sung Hei Kim
________________________________
보낸 사람 : "Paul Higgs" <paul.higgs@ericsson.com<mailto:paul.higgs@ericsson.com>>
보낸 날짜 : 2015-09-02 02:58:44 ( +09:00 )
받는 사람 : 김성혜 <shkim@etri.re.kr<mailto:shkim@etri.re.kr>>, TV Control API Community Group <public-tvapi@w3.org<mailto:public-tvapi@w3.org>>
참조 : 구한승 <koohs@etri.re.kr<mailto:koohs@etri.re.kr>>, 박주영 <jypark@etri.re.kr<mailto:jypark@etri.re.kr>>
제목 : RE: tvapi-ACTION-38: Propose an api spec for conditional access systems
Hello Sunk Hei
I’ve had a chance to look at this again after your explanation during todays call, and would like to make the following points.
• The CA_system_ID is sufficient on its own to indicate which conditional access system is used by the content/channel and which is supported by a CI card. I don’t believe the CA_PID (from ISO 13818-1 definition of the conditional access descriptor) needs to be exposed to the WebApp.
Sung Hei >> CA_PID can be used for analyzing protocols of MPEG streams. CA_PID can be used in WebApps for MPEG protocol analyzer for debugging STB system.
However, I think maybe it is too specific information for the 1st version, and we maybe consider it for the next version.
o As you said in the call, there is already an isFree<http://w3c.github.io/tvapi/spec/#widl-TVChannel-isFree> attribute in the TVChannel<http://w3c.github.io/tvapi/spec/#tvchannel-interface>. This is a Boolean defined as “MUST indicate whether the TV channel is free to watch.” however it may be best defined as “MUST indicate whether the TV channel is currently free to watch.” It could be that a channel shows some free promotional material prior to paid/scrambled content being presented.
Sung Hei >> Although isFree is not defined by this CAS proposal, I think it needs to be changed.
• Knowing what CA Systems are supported by installed CA cards is useful (also helps to know some state information for each CA card).
o Perhaps your definition of getCICard is intended to do this, in which case I would suggest it being defined as Promise<sequence<TVCICard>> getCICards ();
o There would be as many elements in the sequence as there are CI card “slots” in the system
Sung Hei >> I will accept your proposal and change it.However, the CICard in TVManager can be defined as sequence, but in TVChannel only a single CI Card is used, it this correct?
o The TVCICard interface (at a system level) should include the following (these things are good for user level debugging/troubleshooting – see attached screen shots from my US CableCard based STB)
• CA_system_ID : as presently defined/used
• Card_State : one of { inserted, accepted, connected, removed, error }
• Num_Sessions : the number of concurrent sessions supported by the card
• System_Name : human readable string for the CA card
• Software_Version : human readable string of the software version on the CA card
• Region : string representing the country or region the CA is configured for.
• Pairing_State : one of { unknown, none, in-progress, ok, bad }
• There is a lot of other “diagnostic” information that the CA Card could supply to the content source (again see those screen shots). So an opaque JSONified string may be useful to carry it all to the provider (the WebApp need not decipher this)
Sung Hei >> Since I was focus on CI card for each TV channel, I did not consider information that is provided by the device (i.e. STB). But, I am not sure if every STB provides same type of information with same format. We may need to look into this.
I think middleware standard for STB such as OCAP, ACAP, MHP, can provide such information. But we need to study them.
For now, maybe information such as CA_system_ID and Card_State can be consider for our current requirements. For other information, I do not find any use. As you’ve mentioned it can be used for debugging/troubleshooting, but, I think maybe it is too detailed for the first version, unless the group think otherwise?
• Informing the WebApp that the scrambling state of a channel has changed is certainly important, and I presume that is what your [Proposal 2] aroundonCIcardchanged;is for.
o On a channel level there are two types of events that should be reported to the WebApp
• The content in the channel has transitioned from unscrambled to scrambled and the terminal has no permission to unscramble it
• The content in the channel has transitioned from unscrambled to scrambled and the terminal has no resource to unscramble it
Sung Hei >> Yes. Maybe we need this, however, it is not in the requirement.
During the last meeting (Aug.4th), I have suggested to add a new requirement to notify the webapps of the event regarding entitlement changes, such as availability of entitlement, service not subscribed, security not supported, resource not available, etc. However, it is not in our requirement, and I did not propose any APIs for this.
Maybe we can consider this in the next version?
o You may optionally want to inform the WebApp that the content has transitioned from scrambled (whether you have permission/resource to descramble or not) to unscrambled. I say optionally because there would be no user impact of this transition and no WebApp action to be taken.
ㅓ Sung Hei >> Same as previous comments
Paul
>>>>>>>> CAS APIs <<<<<<<<<<<<<<
[Changed summary]
1. Removed applyCICard() defined for [cas.descrypt] requirement.
-->Please note, [cas.descrypt] should be removed from the TV Control API Technical Requirements (TV Control API Technical Requirements)
2. Removed casPId in the TVCICardInformation.
3. Add [cas] requirements to the TVmanager with getCICards method
4. Changed getCICard method to getChannelCICard method from TVChannel.
5. Add state (inserted, accepted, connected, removed, error) to the TVCICardInformation and updated TVCICardState to support (inserted, accepted, connected, removed, error)
{Question}
I’m still not sure if we need to define a WebIDL interface for CI Card.
Currently, I’ve just defined it in form of a WebIDL dictionary, because, from our current requirements I do not see the need of defining separate WebIDL interface (class) for CI Card.
Any comments on this matter??
Please see the changes.
[TVCICardInformation dictionary]
The TVCICardInformation dictionary contains the information on the CI Card used to decrypt the encrypted TV channel.
dictionary TVCICardInformation {
readonly attribute Boolean isScrambled;
readonly attribute TVCICardState state;
readonly attribute DOMString? casSystemId;
};
isScrambled of type Boolean, readonly
MUST indicate whether the stream from this TV channel is currently encrypted(or scrambled).
casSystemId of type DOMString, readonly, nullable
MUST return the CAS system ID used to decrypt stream from the encrypted TV channel. Note, the value is null, if the value of isScrambled is false.
Note) isScambled is related to the isFree attribute in the TVchannel.
[Changes to the TVManager]
Interface TVManager EventTarget {
:
Promise<sequence< TVCICardInformation>> getCICards ();
attribute EventHandler onCIcardchanged;
:
}
getCICards
returns sequence of TVCICardInformation dictionary which provides meta information of the CI cards available in the system.
No parameters
Return type: sequence <TVCICardInformation>
[Changes to the TVChannel]
Interface TVChannel: EventTarget {
:
TVCICardInformation getChannelCICard();
attribute EventHandler onCIcardchanged;
:
}
getChannelCICard
returns a TVCICardInformation dictionary which provides meta information of the CI cards used in decrypting encrypted TV channel as long as the information are available.
No parameters
Return type: TVCICardInformation
[New Event]
Event Handler: onCIcardchanged
Event name: CI_CHANGE
Event type: TVCICardChangedEvent
Description: Handles the information for the dynamically added/removed common interface (CI) cards.
XX. TVCICardChangedEvent Interface
The TVCICardChangedEvent interface represents the events related to the changes in the state of the CI cards.
Interface TVCICardChangedEvent : Event {
readonly attribute TVCICardState state;
readonly attribute DOMString? casSystemId;
}
Enum TVCICardState {
“CIcard-inserted”,
“CIcard-accepted”,
“CIcard-connected”,
“CIcard-removed”,
“CIcard-error”
};
>>>>>>>> End of CAS APIs <<<<<<<<<<<<<<
From: 김성혜 [mailto:shkim@etri.re.kr]
Sent: Tuesday, September 01, 2015 6:41 AM
To: TV Control API Community Group
Cc: 구한승; 박주영
Subject: RE: tvapi-ACTION-38: Propose an api spec for conditional access systems
Dear All,
[Background]
I have studied the CAS requirements.
I have looked at two references, i.e., ATSC CAS for terrestrial broadcast, ISO 13818-1.
ATSC[1] from 4.1.3.5.1 (page 10) defines ATSC_CA_descriptor () as follows:
ATSC_CA_descriptor() {
descriptor_tag (8bits, value= 0x88)
descriptor_length (8bits, uimsbf)
CA_System_ID (16bits, uimsbf)
for ( i = 0 ; i < descriptor_length - 2 ; i++ ) {
private_data_byte 8 bslbf
}
}
The CA_System_ID is defined as This 16-bit unsigned integer indicates the type of CA system applicable for the information conveyed in this descriptor.
So “meta information” regarding CAS is CA_System_ID, which is usually identifies vendor of the CAS system which is used for encrypting/decrypting channels.
ISO[2] from 2.6.16 (page 69) defines Conditional access descriptor as follows:
CA_descriptor() {
descriptor_tag (8bits, uimsbf)
descriptor_length (8bits, uimsbf)
CA_system_ID (16bits, uimsbf)
reserved (3bits, bslbf)
CA_PID 13 uimsbf
for (i = 0; i < N; i++) {
private_data_byte (8bits, uimsbf)
}
}
CA_system_ID – This is a 16-bit field indicating the type of CA system applicable for either the associated ECM and/or EMM streams. The coding of this is privately defined and is not specified by ITU-T | ISO/IEC.
CA_PID – This is a 13-bit field indicating the PID of the Transport Stream packets which shall contain either ECM or EMM information for the CA systems as specified with the associated CA_system_ID. The contents (ECM or EMM) of the packets indicated by the CA_PID is determined from the context in which the CA_PID is found, i.e. a TS_program_map_section or the CA table in the Transport Stream, or the stream_id field in the Program Stream.
So “meta information” regarding CAS is can be CA_System_ID and CA_PID.
Also there is an important CAS related meta-information in the field of PES (Packetized Elementary Stream) which is called PES_scrambling_control (indicate the scrambling mode of the PES packet payload).
If “ PES_scrambling_control = 0x00 “ indicated not scrambled. Other value are user-defined which means the packet is scrambled.
[Reference]
[ATSC] ATSC Standard: Conditional Access System for Terrestrial Broadcast (A/70 Part 1:2010)
[ISO] ISO 13818-1, Information technology — Generic coding of moving pictures and associated audio information: Systems, 2000
Through this analysis, it is possible to define the APIs for CAS requirements.
The followings are the proposals for the APIs.
[Proposal 1] Meta information for CI Card
Proposal for “Meta information” for CAS CI card is as follows.
The TVCICardInformation dictionary contains the information on the CI Card used to decrypt the encrypted TV channel.
dictionary TVCICardInformation {
readonly attribute Boolean isScrambled;
readonly attribute DOMString? casSystemId;
readonly attribute DOMString? casPId;
};
isScrambled of type Boolean, readonly
MUST indicate whether the stream from this TV channel is encrypted(or scrambled).
casSystemId of type DOMString, readonly, nullable
MUST return the CAS system ID used to decrypt stream from the encrypted TV channel. Note, the value is null, if the value of isScrambled is false.
casPID of type DOMString, readonly, nullable
MUST return the CAS PID of ECM or EMM information for CA System. Note, the value is null, if the value of isScrambled is false or if the system does not support casPID.
Note) isScambled is equivalent to the isFree attribute in the TVchannel.
[Proposal 2] APIs for CAS Requirements
To support [cas], [cas.descrypt] [cas.notifications.change] requirements, it can be defined under TVChannel Interface, since CAS are applied for each TV channel.
But we need to discuss where the methods to support CAS requirements should be defined under TVSource interface or TVChannel interface.
Anyway, proposed methods are as follows.
Interface TVChannel: EventTarget {
:
TVCICardInformation getCICard();
void applyCICard (TVCICardInformation card);
attribute EventHandler onCIcardchanged;
:
}
[New Methods]
getCICard
returns a dictionary of TVCICardInformation which provides meta information of the CI cards used in decrypting encrypted TV channel as long as the information are available.
No parameters
Return type: TVCICardInformation
applyCICard
request the tuner to apply CI card with the card parameter.
Parameter (card)
Type: TVCICardInformation, Nullable(X), Optional(X)
Description: Specifies information of CI Card to be applied to the encrypted TV channel.
Return type: void
[Memo from Sung Hei Kim] I am not sure if the system (settop) can use(apply) the specified CI card from the webapp. Normally, CI card that can be used for decryption are already included in the TV stream.
[New Event]
Event Handler: onCIcardchanged
Event name: CI_CHANGE
Event type: TVCICardChangedEvent
Description: Handles the information for the dynamically added/removed common interface (CI) cards.
XX. TVCICardChangedEvent Interface
The TVCICardChangedEvent interface represents the event related to the changes to the CI cards, which can be occur with the add or removal of the CI cards.
Interface TVCICardChangedEvent : Event {
readonly attribute TVCICardState state;
readonly attribute DOMString? casSystemId;
}
23. Enumerations
Enum TVCICardState {
“CIcard-added”,
“CIcard-removed”
};
Regards,
Sung Hei Kim (ETRI)
[Note Requirements]
[cas] This API SHALL be able to provide the webapps with the meta information of the CI cards as long as those meta information is available. For example, the CAS standards such as DVB-CI, ARIB-CAS... etc.
[cas.decrypt] This API SHALL be able to enable the webapps to apply the CI cards to decrypt the encrypted channel.
[cas.notifications] This API SHALL be able to notify the webapps of the dynamically added/removed Common Interface (CI) cards.
The following event SHALL be supported
[cas.notifications.change] CI_CHANGE
________________________________
보낸 사람 : "TV Control API Community Group Issue Tracker" <sysbot+tracker@w3.org<mailto:sysbot+tracker@w3.org>>
보낸 날짜 : 2015-07-07 22:54:12 ( +09:00 )
받는 사람 : public-tvapi@w3.org<mailto:public-tvapi@w3.org> <public-tvapi@w3.org<mailto:public-tvapi@w3.org>>
참조 :
제목 : tvapi-ACTION-38: Propose an api spec for conditional access systems
tvapi-ACTION-38: Propose an api spec for conditional access systems
http://www.w3.org/community/tvapi/track/actions/38
Assigned to: Sung Hei Kim
Received on Monday, 14 September 2015 07:56:10 UTC