[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7615

--- Comment #23 from Anders Broman <anders.broman@xxxxxxxxxxxx> 2012-09-04 13:31:19 PDT ---
(In reply to comment #22)
> Why should we leave out the de facto standard format for these traces? Can you
> please elaborate a bit more?

The spec seems to group the MCS according to header type
3GPP TS 44.060 10.3a.3.1 Header type 1: header for MCS-7, MCS-8 and MCS-9
:
10.3a.3.2 Header type 2: header for MCS-6, MCS-5, DAS-5, DAS-6 and DAS-7

We have a proprietarry transport protocol where the "wrapping information"
states the header type not the MCS type and the MCS can be retrived from the
egprs data I think. So using header type seems more in line with the standard.

Also if you look at the actual code in rlcmac
        case RLCMAC_MCS1:
         case RLCMAC_MCS2:
         case RLCMAC_MCS3:
         case RLCMAC_MCS4:
            csnStreamDissector(rlcmac_tree, &ar,
CSNDESCR(DL_Data_Block_EGPRS_Header_Type3_t), tvb,
&data->u.DL_Data_Block_EGPRS_Header, ett_gsm_rlcmac);
           break;

         case RLCMAC_MCS5:
         case RLCMAC_MCS6:
            csnStreamDissector(rlcmac_tree, &ar,
CSNDESCR(DL_Data_Block_EGPRS_Header_Type2_t), tvb,
&data->u.DL_Data_Block_EGPRS_Header, ett_gsm_rlcmac);
             break;

         case RLCMAC_MCS7:
         case RLCMAC_MCS8:
         case RLCMAC_MCS9:
            csnStreamDissector(rlcmac_tree, &ar,
CSNDESCR(DL_Data_Block_EGPRS_Header_Type1_t), tvb,
&data->u.DL_Data_Block_EGPRS_Header, ett_gsm_rlcmac);
             break;

The function calls are based on headertype not MCS so providing the header type
seems more corect here too.

Best regards
Andrs

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.