Project

General

Profile

Bug #4232

OsmoSTP re-orders M3UA fields of routed messages

Added by laforge about 2 months ago. Updated about 2 months ago.

Status:
Rejected
Priority:
Normal
Assignee:
Target version:
-
Start date:
10/18/2019
Due date:
% Done:

0%


Description

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().

History

#1 Updated by laforge about 2 months ago

  • Status changed from New to In Progress

#2 Updated by laforge about 2 months 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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)