1156146 - [B2G][CBS] Revise the CBS Message formats to support different layout of CDMA/GSM CBS Messages.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: RIL, defect)

Description

[Bevis Tseng[:bevis][:btseng](Exited)]

As commented in bug 1113466 comment 8, the structures of CBS messages in CDMA/GSM seems quite different, and a proposal is provided to notification of the CBS message with 2 different callbacks.

In addition, based-on this proposal, we could also define 2 different types of Cellbroadcast messages in Web API. [1]
For example,
We could revise 'MozCellBroadcastMessage' for GSM and define 'MozCdmaCellBroadcastMessage' for CDMA as followed with new enum attribute 'CellBroadcastBearer' in these 2 interfaces for App Developer to identify the bearer of the received CBS message.

Note: This is a "nice-to-have" changes. The CDMA/GSM CBS messages works in current design but could be improved with better API design.

NI Carol for the feedback of these API changes.

--

enum CellBroadcastBearer {"gsm", "cdma"}

interface MozCellBroadcastMessage
{
  readonly attribute CellBroadcastBearer bearer;
  readonly attribute unsigned long serviceId;
  readonly attribute CellBroadcastGsmGeographicalScope gsmGeographicalScope;
  readonly attribute unsigned short messageCode;
  readonly attribute unsigned short messageId;
  readonly attribute DOMString? language;
  readonly attribute DOMString? body;
  readonly attribute CellBroadcastMessageClass messageClass;
  readonly attribute DOMTimeStamp timestamp;
  readonly attribute MozCellBroadcastEtwsInfo? etws;
}


interface MozCdmaCellBroadcastMessage
{
  readonly attribute CellBroadcastBearer bearer;
  readonly attribute unsigned long serviceId;
  readonly attribute unsigned short serviceCategory;
  readonly attribute DOMString? language;
  readonly attribute DOMString? body;
  readonly attribute DOMTimeStamp timestamp;
  readonly attribute MozCdmaCmasInfo? cmasInfo;
}

/**
 * According to 4.3 CMAS Message in TIA-1149-0-1, CMAS over CDMA in [2]
 */
enum CdmaCmasCategory {'geo', 'met', ...}
enum CdmaCmasResponseType { ... }
enum CdmaCmasSeverity { ... }
enum CdmaCmasUrgency { ... }
enum CdmaCmasCertainty { ... }
interface MozCdmaCmasInfo
{
  readonly attribute CdmaCmasCategory category;
  readonly attribute CdmaCmasResponseType responseType;
  readonly attribute CdmaCmasSeverity severity;
  readonly attribute CdmaCmasUrgency urgency;
  readonly attribute CdmaCmasCertainty certainty;
}

[1] https://dxr.mozilla.org/mozilla-central/source/dom/webidl/MozCellBroadcastMessage.webidl
[2] http://ftp.tiaonline.org/tr-45/tr-45.5/incoming/2009/20091207__Maui/TR-455/WG2/520-09120806__Editor_TIA-1149-0-1_CMASoverCDMA_Baseline.pdf

Comment 1

[Bevis Tseng[:bevis][:btseng](Exited)]

Also NI Steve for the feedback of Web API changes.

Comment 2

[Steve Chung [:steveck]]

Looks fine to me, just wondering if it's reasonable to have another 'type' attribute to classify the GSM/CDMA message directly instead of checking the GSM/CDMA specific attribute like serviceCategory/messageId ?

Comment 3

[Carol Yang [:cyang]]

Hi Bevis,

Overall looks good to me. Had a few questions though:

1) Can MozCellBroadcastMessage be renamed to MozGsmCellBroadcastMessage so the name is self-explanatory for the type of message it contains?
2) A little curious about the need for the new CellBroadcastBearer attribute. Depending on whether you get MozCellBroadcastMessage/MozGsmCellBroadcastMessage or MozCdmaCellBroadcastMessage, you would already know if the message is for GSM/CDMA. What is the use case for needing this particular attribute?

Thanks,
Carol

Comment 4

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to Carol Yang [:cyang] from comment #3)
> Hi Bevis,
> 
> Overall looks good to me. Had a few questions though:
> 
> 1) Can MozCellBroadcastMessage be renamed to MozGsmCellBroadcastMessage so
> the name is self-explanatory for the type of message it contains?
> 2) A little curious about the need for the new CellBroadcastBearer
> attribute. Depending on whether you get
> MozCellBroadcastMessage/MozGsmCellBroadcastMessage or
> MozCdmaCellBroadcastMessage, you would already know if the message is for
> GSM/CDMA. What is the use case for needing this particular attribute?
Yes, you are right, we could use "instance of window.MozGsmCellBroadcastMessage" and "instance of window.MozCdmaCellBroadcastMessage" to identify this and remove the attribute of "bearer" from these 2 interfaces.

BTW, this change becomes necessary if we are going to introduce more CDMA specific attributes into CBS message such as the attributes in 'MozCdmaCmasInfo'.

Currently, the priority of this bug is low.

> Thanks,
> Carol

Comment 5

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to Bevis Tseng[:bevistseng][:btseng] from comment #4)
> Yes, you are right, we could use "instance of
> window.MozGsmCellBroadcastMessage" and "instance of
> window.MozCdmaCellBroadcastMessage" to identify this and remove the
> attribute of "bearer" from these 2 interfaces.
> 
Just recall that currently, both system message & eventListener will be used by the NetworkAlert & System Apps to receive CBS message and there is no specific prototype available for the object sent from system message unless we create a wrapper of nsISystemMessagesWrapper for these webidl interfaces. [1][2].
Compared to the wrapper, it's easier and more handy to have "bearer" attribute available for both implementation and access in App side.
Hence, the "bearer" is still required but we can rename 'MozCellBroadcastMessage' to 'MozGsmCellBroadcastMessage' as you suggested.

[1] https://dxr.mozilla.org/mozilla-central/source/dom/messages/SystemMessageManager.js#80-96
[2] https://dxr.mozilla.org/mozilla-central/source/dom/telephony/gonk/TelephonyService.js#1676-1706

Comment 6

[Carol Yang [:cyang]]

(In reply to Bevis Tseng[:bevistseng][:btseng] from comment #5)
> (In reply to Bevis Tseng[:bevistseng][:btseng] from comment #4)
> > Yes, you are right, we could use "instance of
> > window.MozGsmCellBroadcastMessage" and "instance of
> > window.MozCdmaCellBroadcastMessage" to identify this and remove the
> > attribute of "bearer" from these 2 interfaces.
> > 
> Just recall that currently, both system message & eventListener will be used
> by the NetworkAlert & System Apps to receive CBS message and there is no
> specific prototype available for the object sent from system message unless
> we create a wrapper of nsISystemMessagesWrapper for these webidl interfaces.
> [1][2].
> Compared to the wrapper, it's easier and more handy to have "bearer"
> attribute available for both implementation and access in App side.
> Hence, the "bearer" is still required

Sure sounds good. So if I'm understanding this correctly, the bearer attribute really only benefits the non-CMAS messages as those are handled by system apps. Is that correct? I vaguely remember there being a bug created in an effort to move handling of all messages (CMAS and non-CMAS) to Network Alerts but maybe that was just in comments and not an actual bug. If that's still the case, then this attribute could be removed when that happens.

Comment 7

[BMO Automation]

Firefox OS is not being worked on