OsmoSTP re-orders M3UA fields of routed messages
When a M3UA DATA message with correct order of information elements (routing context, protocol data) is routed by OsmoSTP, the output message is re-ordered: (protocol data, routing context).
The reason for this is that the new routing context is added "after the fact" during the m3ua_tx_xua_as() function.... and it's added at the end of the list of IEs as xua_msg_add_u32() is using xua_msg_add_data() which in turn uses llist_add_tail().
Updated by laforge almost 3 years ago
- Status changed from In Progress to Rejected
Actually, this is a non-issue. RFC4666 states:
Where more than one parameter is included in a message, the
parameters may be in any order, except where explicitly mandated. A
receiver SHOULD accept the parameters in any order.