2016-05-20 19:59:55 +00:00
|
|
|
|
|
|
|
===== test_crcx =====
|
|
|
|
composed:
|
|
|
|
-----
|
|
|
|
CRCX 1 17@mgw MGCP 1.0
|
|
|
|
C: 2a
|
|
|
|
L: p:20, a:AMR, nt:IN
|
|
|
|
M: loopback
|
|
|
|
|
|
|
|
-----
|
|
|
|
composed response:
|
|
|
|
-----
|
|
|
|
200 1 OK
|
|
|
|
I: 1
|
|
|
|
|
|
|
|
v=0
|
|
|
|
o=- 1 23 IN IP4 10.9.1.120
|
|
|
|
s=-
|
|
|
|
c=IN IP4 10.9.1.120
|
|
|
|
t=0 0
|
|
|
|
m=audio 16002 RTP/AVP 98
|
|
|
|
a=rtpmap:98 AMR/8000
|
|
|
|
a=ptime:20
|
|
|
|
|
|
|
|
-----
|
|
|
|
response cb received:
|
|
|
|
head.response_code = 200
|
|
|
|
head.trans_id = 1
|
|
|
|
head.comment = OK
|
|
|
|
audio_port = 16002
|
2017-10-05 16:49:24 +00:00
|
|
|
audio_ip = 10.9.1.120
|
2017-10-05 16:25:37 +00:00
|
|
|
|
|
|
|
Generated CRCX message:
|
|
|
|
CRCX 1 23@mgw MGCP 1.0
|
|
|
|
C: 2f
|
|
|
|
I: 11
|
|
|
|
L: p:20, a:AMR, nt:IN
|
|
|
|
M: sendrecv
|
|
|
|
|
|
|
|
Generated MDCX message:
|
|
|
|
MDCX 2 23@mgw MGCP 1.0
|
|
|
|
C: 2f
|
|
|
|
I: 11
|
|
|
|
M: sendrecv
|
|
|
|
|
|
|
|
c=IN IP4 192.168.100.23
|
|
|
|
m=audio 1234 RTP/AVP 255
|
|
|
|
|
|
|
|
Generated DLCX message:
|
|
|
|
DLCX 3 23@mgw MGCP 1.0
|
|
|
|
C: 2f
|
|
|
|
I: 11
|
|
|
|
|
|
|
|
Generated AUEP message:
|
|
|
|
AUEP 4 23@mgw MGCP 1.0
|
|
|
|
|
|
|
|
Generated RSIP message:
|
|
|
|
RSIP 5 23@mgw MGCP 1.0
|
|
|
|
|
|
|
|
Overfolow test:
|
|
|
|
|
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
|
|
|
|
I: 1
|
|
|
|
|
|
|
|
v=0
|
|
|
|
|
|
|
|
-----
|
2016-05-20 19:59:55 +00:00
|
|
|
Done
|