[mtp3] UPU enum value normalisation#52
Conversation
|
Note that this contains the commit from #51, so it should be merged after it. |
jacob-wg2
force-pushed
the
mtp-upu-enum-value-normalisation
branch
from
d01189b to
c3f1be0
Compare
| parse_unavailability_cause(?MTP3_UPU_CAUSE_UNEQUIPPED) -> unequipped_remote_user; | ||
| parse_unavailability_cause(?MTP3_UPU_CAUSE_INACCESSIBLE) -> inaccessible_remote_user. |
There was a problem hiding this comment.
Should we update the macro-names as well for clarity?
There was a problem hiding this comment.
Given that they sit in an exported hrl file we probably should.
| parse_user_part_id(?MTP3_SERVIND_MTP_TEST) -> mtp_test; | ||
| parse_user_part_id(?MTP3_SERVIND_BROADBAND_ISUP) -> broadband_isup; | ||
| parse_user_part_id(?MTP3_SERVIND_SATELLITE_ISUP) -> satellite_isup; | ||
| parse_user_part_id(R) -> {reserved, R}. |
There was a problem hiding this comment.
not exactly reserved, but spare. are you sure it's allowed?
Usually we make sure to crash in OTC for weird values e.g. spares set.
There was a problem hiding this comment.
This is just mirroring the otc_m3ua:parse_user_identity/compose_user_identity functions. It didn't crash before either, as just the integer was passed, and I didn't want to change semantics.
But I'm fine with crashing, like the other mapping functions in that module do.
There was a problem hiding this comment.
Didn't find an explicit Q.700 requirement for the handling of spare/reserved values. But I came across several quotes elsewhere indicating that related values should be ignored. So I'd rather keep this consistent with otc_m3ua for now.
| compose_user_part_id(sccp) -> ?MTP3_SERVIND_SCCP; | ||
| compose_user_part_id(tup) -> ?MTP3_SERVIND_TUP; | ||
| compose_user_part_id(isup) -> ?MTP3_SERVIND_ISUP; | ||
| compose_user_part_id(dup_call) -> ?MTP3_SERVIND_DUP_CALL; |
There was a problem hiding this comment.
ITU-T Q.704 15.17.4 says it's only DUP for this one and not the split as service indicator for DUP (call and circuit-related messages) and DUP (facility registration and cancellation messages). what are your thoughts on it, something to care about?
There was a problem hiding this comment.
Good question. I've used dup_call because it's encoded by the same integer, but I'm not sure there is a need to align the names with service indicator. DUPU user identity doesn't use either of them, so dup is probably fine.
There was a problem hiding this comment.
| compose_user_part_id(dup_call) -> ?MTP3_SERVIND_DUP_CALL; | |
| compose_user_part_id(dup) -> ?MTP3_SERVIND_DUP_CALL; |
still using the other macro. Should we rather have a separate set of macros for user part id?
2 participants
Currently
unavailability_causeuses different atoms to encode the same cause in otc_m3ua and otc_mtp3. otc_mtp3 also uses an integer user_part_id while otc_m3ua uses atoms for the corresponding field. The specs use identical text representations for both, similar to what otc_m3ua uses.{reserved, R}for unsupported values)