When I use get_body_part on a multipart body, it doesn't detect properly the ending of multipart headers:
For instance in: ``` --vvemeemm0wqr7ayc5h367f3v8e66mc9t Content-Type: application/sdp Content-Length: 479
v=0 o=- 3669362310 3669362310 IN IP4 192.168.2.4 [...] ```
"Content-Length: 479" is taken into get_body_part("application/sdp", "$var(sdp)");
I will try to provide more details later.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/564
I have no example of a multipart body in my pile of cool INVITE messages. Would it be possible for you to upload one full INVITE as an example for us to test with?
/O
On 11 Apr 2016, at 13:20, foucse notifications@github.com wrote:
When I use get_body_part on a multipart body, it doesn't detect properly the ending of multipart headers:
For instance in:
--vvemeemm0wqr7ayc5h367f3v8e66mc9t Content-Type: application/sdp Content-Length: 479
v=0 o=- 3669362310 3669362310 IN IP4 192.168.2.4 [...] "Content-Length: 479" is taken into get_body_part("application/sdp", "$var(sdp)");
I will try to provide more details later.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/kamailio/kamailio/issues/564 _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi,
Here is one example, the XML body is not standard (yet), so I had to remove it. Content-Length is to be checked
``` 2016/04/11 16:38:17.645936 192.168.2.2:5062 -> 192.168.100.1:5060 INVITE sip:bob@example.com SIP/2.0 via: SIP/2.0/UDP 192.168.2.2:5062;branch=z9hG4bK-18344-1-10 From: "alice" sip:alice@example.com;tag=183446416897 To: "bob" sip:bob@example.com Call-ID: alice-bob-call CSeq: 2 INVITE Contact: sip:alice@192.168.2.2:5062 Max-Forwards: 70 Expires: 3600 Content-Type: multipart/mixed;boundary=8920nv9wiwdnnsrnia9buoyci39qsi6x Content-Disposition: session User-Agent: SIPp/Linux Content-Length: 759
--8920nv9wiwdnnsrnia9buoyci39qsi6x Content-Type: application/some-random-mime+xml Content-Length: 290
<?xml version="1.0" encoding="UTF-8"?> <xxxxxxxx> <xxxxxxxxxxxxxxxx> <xxxxxxxxx>yyyyyyyy</xxxxxxxxx> <aaaaaaaaa>bbbbbbbb</aaaaaaaaa> </xxxxxxxxxxxxxxxx> </xxxxxxxx> --8920nv9wiwdnnsrnia9buoyci39qsi6x Content-Type: application/sdp Content-Length: 479
v=0 o=- 3669370665 3669370665 IN IP4 192.168.2.2 s=application-media t=0 0 c=IN IP4 192.168.2.2 m=audio 8000 RTP/AVP 106 96 a=rtcp:8001 IN IP4 192.168.2.2 a=sendrecv a=rtpmap:106 AMR-WB/16000 a=fmtp:106 octet-align=0; mode-set=4 a=ptime:20 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-16 m=application 9000 udp XXXXX 8920nv9wiwdnnsrnia9buoyci39qsi6x-- ```
The command get_body_part("application/sdp", "$var(sdp)"); writes the following content in $var(sdp):
``` Content-Length: 479
v=0 o=- 3669370665 3669370665 IN IP4 192.168.2.2 s=application-media t=0 0 c=IN IP4 192.168.2.2 m=audio 8000 RTP/AVP 106 96 a=rtcp:8001 IN IP4 192.168.2.2 a=sendrecv a=rtpmap:106 AMR-WB/16000 a=fmtp:106 octet-align=0; mode-set=4 a=ptime:20 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-16 m=application 9000 udp XXXXX ```
But the expected content is:
``` v=0 o=- 3669370665 3669370665 IN IP4 192.168.2.2 s=application-media t=0 0 c=IN IP4 192.168.2.2 m=audio 8000 RTP/AVP 106 96 a=rtcp:8001 IN IP4 192.168.2.2 a=sendrecv a=rtpmap:106 AMR-WB/16000 a=fmtp:106 octet-align=0; mode-set=4 a=ptime:20 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-16 m=application 9000 udp XXXXX ```
"Content-Length: 479" is a multipart header and should be ignored. From what I understand everything after a "Content-Type:" is considered as a body.
--- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/564#issuecomment-208383612
I finally had some time to look into the source code, the issue comes from the file textops/textops.c:2071
```C while (find_line_start("Content-Type: ", 14, &start, &len)) { end = start + 14; len = len - 14; if (len > (content_type.len + 2)) { if (strncasecmp(end, content_type.s, content_type.len)== 0) { LM_DBG("found content type %.*s\n", content_type.len, content_type.s); end = end + content_type.len; if ((*end != 13) || (*(end + 1) != 10)) { LM_ERR("no CRLF found after content type\n"); goto err; } end = end + 2; len = len - content_type.len - 2; body_headers_end = end; if (find_line_start(boundary.s, boundary.len, &end, &len)) { ```
Thanks to the pull "textops: Fix get_body_part() end of body headers #423" by smititelu, textops is now able to find the end of multipart headers in the simple case of just a "Content-type" header. But it is not able to handle more complex cases like this one for instance (from RFC 5621 https://tools.ietf.org/html/rfc5621#section-3.1):
``` INVITE sip:conf-fact@example.com SIP/2.0 Content-Type: multipart/mixed;boundary="boundary1" Content-Length: 619
--boundary1 Content-Type: application/sdp
v=0 o=alice 2890844526 2890842807 IN IP4 atlanta.example.com s=- c=IN IP4 192.0.2.1 t=0 0 m=audio 20000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 20002 RTP/AVP 31 a=rtpmap:31 H261/90000
--boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list
<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <list> <entry uri="sip:bill@example.com"/> <entry uri="sip:randy@example.net"/> <entry uri="sip:joe@example.org"/> </list> </resource-lists> --boundary1--
Figure 2: SIP message carrying a body ```
Here "Content-Disposition: recipient-list" would be taken into the second body because the variable body_headers_end would be set just after the content type header by find_line_start("Content-Type: ", 14, &start, &len).
I think that maybe something like: ```C body_headers_end = find_line_start("\r\n", 14, &start, &len); ``` Instead of: ```C body_headers_end = end; ``` Might help. Because a \r\n should always separate headers from the body as it is specified for instance in RFC 3261 (https://tools.ietf.org/html/rfc3261#section-7) for SIP headers:
``` generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line / Status-Line ```
I will test this solution as soon I will have more spare time.
--- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/564#issuecomment-213852048
Thanks for troubleshooting further. If you test your solution and works ok, make a pull request with the patch, to be reviewed and eventually merged.
--- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/564#issuecomment-214159755
@foucse can you try this changes?
--- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/564#issuecomment-219702915
If still an issue, reopen, the patch referenced above is more than 5 months old.
Closed #564.