Project

General

Profile

Bug #2837

Missing sdp fields in libosmo-mgcp-client

Added by daniel over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
01/18/2018
Due date:
% Done:

100%


Description

When generating an MDCX the code in mgcp_msg_gen doesn't include the following mandatory SDP fields:
(v)ersion,(o)rigin,(s)ession,(t)ime

Version, session and time can probably be static. Only origin needs our IP address and a unique ID.
See https://www.ietf.org/rfc/rfc2327.txt chapter 6 for more info.

History

#1 Updated by dexter over 1 year ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 50

I have implemented the missing fields into the MGCP client. I see that we already generate those fields on the server side, so I copied the static values which we use from there.

The only field that contains dynamic values is the -o field. There we need to supply a session id and a local IP address. On the server side we use the connection ID as session id and the local ip on which osmo-mgw runs. On the client side I implemented it so that it determines the IP-Address on which the client runs and I use the Call-Id as session identifier.

I might be wrong, but I think what osmo-mgw now should do is to extract the session id that the client supplies and store it so that it can be used in the responses (instead of the Connection Id, which I think is wrong).

@Daniel, maybe it is the best if you just try the patch and see what the TTCN3 MGW emulation returns?

See also patch: https://gerrit.osmocom.org/5994

#2 Updated by dexter over 1 year ago

  • Status changed from In Progress to Feedback
  • Assignee changed from dexter to daniel
  • % Done changed from 50 to 60

The patch is now merged. Can you see if this solved your problem?

#3 Updated by dexter over 1 year ago

There was also a problem with the ordering of the parameters. Technically the ordering should not matter at all since each parameter has its identifier, but the specification specifies a certain order and that is why TTCN3 still does not accept our SDP. This problem is now fixed and the patch is merged, see also: https://gerrit.osmocom.org/#/c/6217/

#4 Updated by dexter over 1 year ago

  • % Done changed from 60 to 100

#5 Updated by dexter over 1 year ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)