Actions
Bug #2835
closedNewline handling of libosmo-mgcp-client needs to be more lenient
Start date:
01/17/2018
Due date:
% Done:
100%
Spec Reference:
Description
The code in mgcp-client assumes certain different line endings on MGCP reponses.
e.g. These don't parse (there's more options):
"200 5 OK\r\nI: 10A96B45\r\n\nv=0\r\no=- foo 21 IN IP4 127.0.0.1\r\ns=-\r\nc=IN IP4 127.0.0.1\r\nt=0 0\r\nm=audio 1000 RTP/AVP 98\r\na=rtpmap:98 AMR/8000\r\na=ptime:20\r\n" ^^^^^^ "200 5 OK\r\nI: 10A96B45\r\n\r\nv=0\r\no=- foo 21 IN IP4 127.0.0.1\r\ns=-\r\nc=IN IP4 127.0.0.1\r\nt=0 0\r\nm=audio 1000 RTP/AVP 98\r\na=rtpmap:98 AMR/8000\r\na=ptime:20\r\n" ^^^^^^^^
Only the following is correctly parsed:
"200 5 OK\r\nI: 10A96B45\n\nv=0\r\no=- foo 21 IN IP4 127.0.0.1\r\ns=-\r\nc=IN IP4 127.0.0.1\r\nt=0 0\r\nm=audio 1000 RTP/AVP 98\r\na=rtpmap:98 AMR/8000\r\na=ptime:20\r\n"
This has to do with the way different parts of the parser search for newlines or double newlines and how they replace parts of the string with NULL.
See parse_head_params(), for_each_non_empty_line and mgcp_response_parse_params() in mgcp_client.c
Updated by dexter about 6 years ago
- % Done changed from 0 to 90
See patch: https://gerrit.osmocom.org/5867
Updated by dexter about 6 years ago
- % Done changed from 90 to 100
Also osmo-mgw was generating inconsistant messages. There were missing \r chars on some variable. Also just having an \n to separate the SDP block is inconsistant. This is now also an \r\n as it should be.
See patch: https://gerrit.osmocom.org/5980
Actions