Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Uncomment processing of APC_CONSTRAINTS (line 75)
- Loading branch information
Uncomment processing of APC_CONSTRAINTS (line 75)
5fa129c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi,
I am from the openairinteface team and this change breaks our CU/DU split.
I can provide more information later, but what motivates this change ?
Thanks.
Regards,
Cédric.
5fa129c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
5fa129c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change broken decoding at oai of S1AP setup response from SRS EPC.
5fa129c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the faulty encoder's fault, or a decoder problem?
Reason I'm asking: if constraints were defined - should they not be respected and taken into account? The code before this change simply ignored constraints, aka (IMH) accommodated encoders that did not do a good job.
What is supposed to be the semantic meaning of
cval->range_bits
?Edit
Looking at the code, the
asn1c
APER encoder always setscval->range_bits
to 8 forASN_OSUBV_STR
, regardless. I wonder what other values other encoders setcval->range_bits
to. In any case, forASN_OSUBV_STR
it seems that 8 is the only legal and reasonable value.@KIN92, please reply with info: what encoder produced the APER that required
cval->range_bits
setting other than 8. Without that info I'm going to revert this commit.@vladislav1q I'm about to push a change to
skeletons/OCTET_STRING_aper.c
that fixes some problems in theswitch() {}
in both encoder and decoder. I'll let you know when I finish that - and will appreciate if you could test the new code then.5fa129c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I've reverted this commit - it appears to be wrong, as for APER each encoded octet is supposed to be padded to to 8 bits, not the entire string.
5fa129c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these 8 bits mentioned in the standard document? I just tested vlm_master and it can encode and decode XML normally. After encoding PrintableString, it is one byte less than the old version.
5fa129c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
5fa129c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this file ITU-Z.14 14.15.1chapter, Octet is set 8 Bitstring.
So please confirm if it is always set to 8 bits in 5fa129c。