Project

General

Profile

Actions

Bug #3431

closed

IP in SDP is reversed

Added by sammachin over 5 years ago. Updated over 5 years ago.

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

100%

Spec Reference:

Description

I'm trying to make a call from my GSM to the co-located asterisk box running an echo test application. I'm using the osmo-sip-connector and the call setup seems to go fine but there is no media, looking at the SDP for the invite the IP address in there is backwards, it should be 78.158.87.45 but its showing in SDP as 45.87.158.78.

Here's the INVITE:
PVS*PVv E@[NW-NW,INVITE sip::5060 SIP/2.0
Via: SIP/2.0/UDP 78.158.87.45:5069;rport;branch=z9hG4bKUN1Xjg18UaH9N
Max-Forwards: 70
From: <sip::5069>;tag=B4yjyp8am9QZD
To: <sip::5060>
Call-ID: a1fb000e-0dd0-1237-ed83-005056ac7620
CSeq: 935421206 INVITE
Contact: <sip:78.158.87.45:5069>
User-Agent: sofia-sip/1.12.11devel
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE
Supported: timer, 100rel
Content-Type: application/sdp
Content-Length: 128

v=0
o=Osmocom 0 0 IN IP4 45.87.158.78
s=GSM Call
c=IN IP4 45.87.158.78
t=0 0
m=audio 16004 RTP/AVP 0
a=rtpmap:0 GSM/8000

I'm running:
osmo-mgw 1.3.0
osmo-bsc & msc report Version UNKNOWN

Actions #1

Updated by laforge over 5 years ago

  • Assignee set to dexter

sammachin wrote:

I'm running:
osmo-mgw 1.3.0
osmo-bsc & msc report Version UNKNOWN

This is extremely odd and indicates you might be experiencing build issues. Please confirm your findings - if possible - using the latest osmocom:nightly packages.

Actions #2

Updated by keith over 5 years ago

I noticed this also, and I am wondering if it was a bug in the legacy code that was then worked around in the osmo-sip-connector (and also presumably, in the LCR when the gsm MNCC socket support was added)

See http://git.osmocom.org/osmo-sip-connector/tree/src/sdp.c#n168 in sdp_create_file().

You can quickly work around this for further testing by removing the ntohl() in line 168:

-       struct in_addr net = { .s_addr = ntohl(other->ip) };
+       struct in_addr net = { .s_addr = other->ip };

I also had to force the payload type here with

other->payload_type = 3

if using Full Rate

I have yet to track down the change that is causing the reversed IP to be sent to the MNCC socket.

Actions #3

Updated by keith over 5 years ago

This problem was obviously noticed at 34C3 and there were some patches made to deal with it.
http://git.osmocom.org/osmo-sip-connector/log/src?h=lynxis%2F34c3

Question is, Should the byte order in osmo-sip-connector be left as it is and should we fix the byte order being sent from osmoMSC, (which is possibly coming some way from osmoMGW?)

If we change osmo-sip-connector, it will break with legacy openbsc and also LCR will be broken, as LCR obviously is expecting the same byte order as unpatched osmo-sip-connector (LCR works with openbsc)

Actions #4

Updated by laforge over 5 years ago

Hi Keith,

On Mon, Aug 13, 2018 at 11:33:02AM +0000, keith [REDMINE] wrote:

This problem was obviously noticed with and there were some patches made to deal with it at 34C3:
http://git.osmocom.org/osmo-sip-connector/log/src?h=lynxis%2F34c3

Question is, Should the byte order in osmo-sip-connector be left as it is and should we fix the byte order being sent from osmoMSC, (which is possibly coming some way from osmoMGW?)

If we change osmo-sip-connector, it will break with legacy openbsc and also LCR will be broken, as LCR obviously is expecting the same byte order as unpatched osmo-sip-connector (LCR works with openbsc)

We should clearly use whatever method is the most compatible / least breaking one. Based on your
analysis, I would think one simple change to OsmoMSC should ensure best compatibility?

For real/proper codec negotiation from Um to SIP we'll likely need to change MNCC
at some not too distant point :(

Actions #5

Updated by kamilner over 5 years ago

If it's any use, I checked MGCP, and the IP addresses in the SDP appear to be correct.

Actions #6

Updated by dexter over 5 years ago

  • % Done changed from 0 to 90

I think fixing this in osmo-sip-connector is the wrong way since this is not a bug in osmo-sip-connector. The problem is in osmo-msc, which is populating the ip struct memeber of struct gsm_mncc_rtp in the wrong byte oder. In order to make sure that this assumption is correct I checked how the SDP in the sip messages looks like when osmo-nitb is used. The IP byteorder looks correct there. Correcting the byte order in osmo-sip-connector would break osmo-nitb so fixing it in osmo-msc seems to be the right place.

See also: https://gerrit.osmocom.org/#/c/osmo-msc/+/11139

Actions #7

Updated by dexter over 5 years ago

  • Status changed from New to In Progress
Actions #8

Updated by dexter over 5 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

The patch made it into master, so we can close this now. However, Its still not clear to me why it worked all the time on my local machine...

Actions #9

Updated by osmith over 5 years ago

I also had the issue, and I can confirm that it's fixed with @dexter's changes. Thank you!

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)