2016-05-20 19:59:55 +00:00
|
|
|
|
2017-10-05 16:25:37 +00:00
|
|
|
Generated CRCX message:
|
|
|
|
CRCX 1 23@mgw MGCP 1.0
|
|
|
|
C: 2f
|
|
|
|
I: 11
|
2018-06-07 16:51:31 +00:00
|
|
|
L: p:20, a:GSM, nt:IN
|
|
|
|
M: sendrecv
|
|
|
|
|
|
|
|
Generated CRCX message (two codecs):
|
|
|
|
CRCX 2 23@mgw MGCP 1.0
|
|
|
|
C: 2f
|
|
|
|
I: 11
|
|
|
|
L: p:20, a:GSM;AMR, nt:IN
|
|
|
|
M: sendrecv
|
|
|
|
|
|
|
|
Generated CRCX message (three codecs, one with custom pt):
|
|
|
|
CRCX 3 23@mgw MGCP 1.0
|
|
|
|
C: 2f
|
|
|
|
I: 11
|
|
|
|
L: p:20, a:GSM;AMR;GSM-EFR, nt:IN
|
2017-10-05 16:25:37 +00:00
|
|
|
M: sendrecv
|
|
|
|
|
|
|
|
Generated MDCX message:
|
2018-06-07 16:51:31 +00:00
|
|
|
MDCX 4 23@mgw MGCP 1.0
|
2017-10-05 16:25:37 +00:00
|
|
|
C: 2f
|
|
|
|
I: 11
|
|
|
|
M: sendrecv
|
|
|
|
|
2018-01-22 16:31:10 +00:00
|
|
|
v=0
|
|
|
|
o=- 2f 23 IN IP4 127.0.0.1
|
2018-01-31 15:44:00 +00:00
|
|
|
s=-
|
2017-10-05 16:25:37 +00:00
|
|
|
c=IN IP4 192.168.100.23
|
2018-01-22 16:31:10 +00:00
|
|
|
t=0 0
|
2018-06-07 16:51:31 +00:00
|
|
|
m=audio 1234 RTP/AVP 3
|
|
|
|
a=ptime:20
|
|
|
|
|
|
|
|
Generated MDCX message (two codecs):
|
|
|
|
MDCX 5 23@mgw MGCP 1.0
|
|
|
|
C: 2f
|
|
|
|
I: 11
|
|
|
|
M: sendrecv
|
|
|
|
|
|
|
|
v=0
|
|
|
|
o=- 2f 23 IN IP4 127.0.0.1
|
|
|
|
s=-
|
|
|
|
c=IN IP4 192.168.100.23
|
|
|
|
t=0 0
|
|
|
|
m=audio 1234 RTP/AVP 3 112
|
|
|
|
a=rtpmap:112 AMR/8000/1
|
|
|
|
a=ptime:20
|
|
|
|
|
|
|
|
Generated MDCX message (three codecs, one with custom pt):
|
|
|
|
MDCX 6 23@mgw MGCP 1.0
|
|
|
|
C: 2f
|
|
|
|
I: 11
|
|
|
|
M: sendrecv
|
|
|
|
|
|
|
|
v=0
|
|
|
|
o=- 2f 23 IN IP4 127.0.0.1
|
|
|
|
s=-
|
|
|
|
c=IN IP4 192.168.100.23
|
|
|
|
t=0 0
|
|
|
|
m=audio 1234 RTP/AVP 3 112 96
|
|
|
|
a=rtpmap:112 AMR/8000/1
|
|
|
|
a=rtpmap:96 GSM-EFR/8000/1
|
|
|
|
a=ptime:20
|
2017-10-05 16:25:37 +00:00
|
|
|
|
|
|
|
Generated DLCX message:
|
2018-06-07 16:51:31 +00:00
|
|
|
DLCX 7 23@mgw MGCP 1.0
|
2017-10-05 16:25:37 +00:00
|
|
|
C: 2f
|
|
|
|
I: 11
|
|
|
|
|
|
|
|
Generated AUEP message:
|
2018-06-07 16:51:31 +00:00
|
|
|
AUEP 8 23@mgw MGCP 1.0
|
2017-10-05 16:25:37 +00:00
|
|
|
|
|
|
|
Generated RSIP message:
|
2018-06-07 16:51:31 +00:00
|
|
|
RSIP 9 23@mgw MGCP 1.0
|
2017-10-05 16:25:37 +00:00
|
|
|
|
2018-08-23 14:36:48 +00:00
|
|
|
Generate X-Osmo-IGN message:
|
|
|
|
CRCX 11 23@mgw MGCP 1.0
|
|
|
|
C: 2f
|
|
|
|
I: 11
|
|
|
|
L: p:20, a:GSM, nt:IN
|
|
|
|
M: sendrecv
|
|
|
|
X-Osmo-IGN: C
|
|
|
|
|
2019-04-24 20:06:22 +00:00
|
|
|
Generate X-Osmo-Osmux message:
|
|
|
|
CRCX 13 23@mgw MGCP 1.0
|
|
|
|
C: 2f
|
|
|
|
I: 11
|
|
|
|
L: p:20, a:GSM, nt:IN
|
|
|
|
M: sendrecv
|
|
|
|
X-Osmux: *
|
|
|
|
|
|
|
|
Generate X-Osmo-Osmux message (fixed CID 2):
|
|
|
|
CRCX 15 23@mgw MGCP 1.0
|
|
|
|
C: 2f
|
|
|
|
I: 11
|
|
|
|
L: p:20, a:GSM, nt:IN
|
|
|
|
M: sendrecv
|
|
|
|
X-Osmux: 2
|
|
|
|
|
2019-05-10 14:49:59 +00:00
|
|
|
Generate X-Osmo-Osmux message (MDCX):
|
|
|
|
MDCX 17 23@mgw MGCP 1.0
|
|
|
|
C: 2f
|
|
|
|
I: 11
|
|
|
|
L: p:20, a:GSM, nt:IN
|
|
|
|
M: sendrecv
|
|
|
|
X-Osmux: 2
|
|
|
|
|
2017-10-05 16:25:37 +00:00
|
|
|
Overfolow test:
|
2020-08-28 18:21:55 +00:00
|
|
|
IPv6 test:
|
|
|
|
MDCX 19 23@mgw MGCP 1.0
|
|
|
|
C: 2f
|
|
|
|
I: 11
|
|
|
|
M: sendrecv
|
|
|
|
|
|
|
|
v=0
|
|
|
|
o=- 2f 23 IN IP6 ::1
|
|
|
|
s=-
|
|
|
|
c=IN IP6 2001:db8:1::ab9:c0a8:102
|
|
|
|
t=0 0
|
|
|
|
m=audio 1234 RTP/AVP 3
|
|
|
|
a=ptime:20
|
|
|
|
|
2017-10-05 16:25:37 +00:00
|
|
|
|
mgcp_client: add transaction cleanup
So far, if an MGCP message is sent, the transaction gets enqueued, but there is
no way to end the transaction other than receiving a valid reply. So, if the
caller decides that the transaction timed out and tears down the priv pointer
passed to mgcp_client_tx, and if then a late reply arrives, the callback will
dereference the invalid priv pointer and cause a segfault. Hence it is possible
to crash an mgcp_client program by sending a late response.
Furthermore, if no reply ever arrives, we would keep the pending response in
the list forever, amounting to a "memory leak".
Add mgcp_client_cancel() to discard a pending transaction. The caller can now
decide to discard a pending response when it sees fit (e.g. the caller's
timeout expired). This needs to be added to OsmoMSC and OsmoBSC.
Add mgcp_msg_trans_id() to provide an obvious way to obtain the transaction id
from a generated MGCP message.
No public API is broken; but refine the negative return code from
mgcp_client_rx(): return -ENOENT if no such transaction ID is found, and still
-1 if decoding failed. This is mainly for mgcp_client_test.
Implement a test for mgcp_client_cancel() in mgcp_client_test.c.
Tweak internal mgcp_client_response_pending_get() to take only the transaction
id as argument instead of the entire mgcp message struct.
Found-by: dexter
Related: OS#2695 OS#2696
Change-Id: I16811e168a46a82a05943252a737b3434143f4bd
2017-11-30 12:43:11 +00:00
|
|
|
|
|
|
|
test_mgcp_client_cancel():
|
|
|
|
composed:
|
|
|
|
-----
|
|
|
|
CRCX 1 23@mgw MGCP 1.0
|
|
|
|
C: 2f
|
|
|
|
I: 11
|
|
|
|
L: p:20, a:AMR, nt:IN
|
|
|
|
M: sendrecv
|
|
|
|
|
|
|
|
-----
|
|
|
|
composed response:
|
|
|
|
-----
|
|
|
|
200 1 OK
|
2018-09-03 19:07:26 +00:00
|
|
|
I: 1
|
|
|
|
|
mgcp_client: add transaction cleanup
So far, if an MGCP message is sent, the transaction gets enqueued, but there is
no way to end the transaction other than receiving a valid reply. So, if the
caller decides that the transaction timed out and tears down the priv pointer
passed to mgcp_client_tx, and if then a late reply arrives, the callback will
dereference the invalid priv pointer and cause a segfault. Hence it is possible
to crash an mgcp_client program by sending a late response.
Furthermore, if no reply ever arrives, we would keep the pending response in
the list forever, amounting to a "memory leak".
Add mgcp_client_cancel() to discard a pending transaction. The caller can now
decide to discard a pending response when it sees fit (e.g. the caller's
timeout expired). This needs to be added to OsmoMSC and OsmoBSC.
Add mgcp_msg_trans_id() to provide an obvious way to obtain the transaction id
from a generated MGCP message.
No public API is broken; but refine the negative return code from
mgcp_client_rx(): return -ENOENT if no such transaction ID is found, and still
-1 if decoding failed. This is mainly for mgcp_client_test.
Implement a test for mgcp_client_cancel() in mgcp_client_test.c.
Tweak internal mgcp_client_response_pending_get() to take only the transaction
id as argument instead of the entire mgcp message struct.
Found-by: dexter
Related: OS#2695 OS#2696
Change-Id: I16811e168a46a82a05943252a737b3434143f4bd
2017-11-30 12:43:11 +00:00
|
|
|
v=0
|
|
|
|
|
|
|
|
-----
|
2018-02-21 14:36:45 +00:00
|
|
|
|
|
|
|
test_sdp_section_start() test [0]:
|
|
|
|
|
|
|
|
test_sdp_section_start() test [1]:
|
|
|
|
|
|
|
|
test_sdp_section_start() test [2]:
|
|
|
|
|
|
|
|
test_sdp_section_start() test [3]:
|
|
|
|
|
|
|
|
test_sdp_section_start() test [4]:
|
|
|
|
|
|
|
|
test_sdp_section_start() test [5]:
|
|
|
|
|
|
|
|
test_sdp_section_start() test [6]:
|
|
|
|
|
|
|
|
test_sdp_section_start() test [7]:
|
|
|
|
|
|
|
|
test_sdp_section_start() test [8]:
|
|
|
|
|
|
|
|
test_sdp_section_start() test [9]:
|
2020-08-28 18:21:55 +00:00
|
|
|
|
|
|
|
test_sdp_section_start() test [10]:
|
|
|
|
|
|
|
|
test_sdp_section_start() test [11]:
|
|
|
|
|
|
|
|
test_sdp_section_start() test [12]:
|
|
|
|
|
|
|
|
test_sdp_section_start() test [13]:
|
|
|
|
|
|
|
|
test_sdp_section_start() test [14]:
|
|
|
|
|
|
|
|
test_sdp_section_start() test [15]:
|
|
|
|
|
|
|
|
test_sdp_section_start() test [16]:
|
|
|
|
|
|
|
|
test_sdp_section_start() test [17]:
|
|
|
|
|
|
|
|
test_sdp_section_start() test [18]:
|
2024-01-11 19:40:27 +00:00
|
|
|
110 => 96
|
|
|
|
111 => 97
|
|
|
|
112 => 98
|
|
|
|
113 => 99
|
|
|
|
96 <= 110
|
|
|
|
97 <= 111
|
|
|
|
98 <= 112
|
|
|
|
99 <= 113
|
|
|
|
|
|
|
|
0 => 0
|
|
|
|
3 => 3
|
|
|
|
8 => 8
|
|
|
|
18 => 18
|
|
|
|
0 <= 0
|
|
|
|
3 <= 3
|
|
|
|
8 <= 8
|
|
|
|
18 <= 18
|
|
|
|
|
|
|
|
110 => 96
|
|
|
|
111 => 97
|
|
|
|
112 => 98
|
|
|
|
113 => 113
|
|
|
|
0 => 0
|
|
|
|
96 <= 110
|
|
|
|
97 <= 111
|
|
|
|
98 <= 112
|
|
|
|
2 <= 2
|
|
|
|
100 <= 100
|
|
|
|
|
2020-06-25 18:16:22 +00:00
|
|
|
ds/e1-1/s-15/su64-0@mgw
|
|
|
|
ds/e1-2/s-14/su32-0@mgw
|
|
|
|
ds/e1-3/s-13/su32-4@mgw
|
|
|
|
ds/e1-4/s-12/su16-0@mgw
|
|
|
|
ds/e1-5/s-11/su16-2@mgw
|
|
|
|
ds/e1-6/s-10/su16-4@mgw
|
|
|
|
ds/e1-7/s-9/su16-6@mgw
|
|
|
|
ds/e1-8/s-8/su8-0@mgw
|
|
|
|
ds/e1-9/s-7/su8-1@mgw
|
|
|
|
ds/e1-10/s-6/su8-2@mgw
|
|
|
|
ds/e1-11/s-5/su8-3@mgw
|
|
|
|
ds/e1-12/s-4/su8-4@mgw
|
|
|
|
ds/e1-13/s-3/su8-5@mgw
|
|
|
|
ds/e1-14/s-2/su8-6@mgw
|
|
|
|
ds/e1-15/s-1/su8-7@mgw
|
2016-05-20 19:59:55 +00:00
|
|
|
Done
|