Hi Klaus, did you find a solution to this problem? I'm working with SIP-I and having the same issue with Binary encoding. I need to encode a 0x00 value and when the config script gets to that point, it breaks. If I encode any other hex value it's fine. This is the config part I'm using:
route[INSERT_ACM]{ if(has_body()){ # Save the SDP body for future reference $var(sdp_body) = $rb; replace_body_atonce("^.+$", ""); remove_hf("Content-Type"); append_hf("MIME-Version: 1.0\r\n", "Content-Length"); append_hf("Content-Type: multipart/mixed; boundary=unique-boundary-1\r\n", "Allow"); replace_body_atonce("^.+$", "--unique-boundary-1\r\nContent-Disposition: signal; handling=optional\r\nContent-Type: application/isup; version=itu-t92+\r\n\r\n'\x06''\x02''\x04''\x01''\x29''\x01''\x01''\x00'\r\n-unique-boundary-1\r\n"); msg_apply_changes(); replace_body_all("\047", ""); append_body_part("$var(sdp_body)","application/sdp"); } return; } I tried with the escape character \0 which should be translated to ASCII hex value '00' but it's parsed as ASCII literal values \0... Thanks! Federico Federico San Martín e-mail : fsanmar...@telecentro.net.ar On 9/17/13 4:34 PM, Daniel wrote: > Hello, > > most of the functions for pseudo-variables work with string types, that > because a script variable can have only integer or string values. Even > the length can be higher, these functions truncate at first 0. But > internally all should be kept, just not passed to config variables. > > Have you tried exec_msg(), that should pass entire msg? > > Otherwise, I presume there is need for some C coding to make binary > values work with variables in config. > > Cheers, > Daniel On 9/17/13 4:03 PM, Klaus Feichtinger wrote: > Hello, > > I have an update to the side effects of receiving an INVITE message that > contains a MIME body with binary data: > - pseudo variables are affected, too > - the message buffer ($mb) does not include the whole message; it is > ending with the nul character > - as the message buffer does not include all data, the modification > cannot be done with an external script / program (e.g. perl, bash script) > > The behaviour was tested with kamailio 4.0.3, too - no difference! > > In general, the whole message is stored in a buffer, but parts of it are > inaccessible for parsing / text functions. > > Any idea, what could cause this problem? > > regards, > Klaus > >> Hello, >> >> I have a problem with Kamailio version 3.2.4 (tested also with 3.3.5) >> regarding "binary data" in message bodies. According RFC3261 it is >> explicitly allowed using binary data within MIME bodies: >> >> RFC 3261 section 7.4.1: SIP messages MAY contain binary bodies or body >> parts. When no explicit charset parameter is provided by the sender, >> media subtypes of the "text" type are defined to have a default charset >> value of "UTF-8". >> >> However, the Kamailio function "Regular Expression Transformation" >> (re.subst), which is based on the transformation class (exported by the >> textops module) is causing problems in our customer system. In regular >> scenarios, Kamailio is receiving SIP INVITE messages with a MIME body, >> which is containing following parts: >> - application/sdp (standard conform) >> - application/x-q931 (Cisco proprietary with BINARY data!) >> - application/gtd (Cisco proprietary with ASCII strings) >> >> The content of the "x-q931" and "gtd" body parts is depending on (UUS1) >> data that were received on the ISDN line. Kamailio has to forward >> User-User specific information from the ISDN line to SIP user agents (in >> form of the "User-to-User" header field). The content of these UUS1 data >> may contain also byte values "00", which is legitimate. In general, >> Kamailio is in every INVITE message searching specific content in the >> last body (application/gtd) and copying this content to a config >> variable. As soon as the x-q931 body contains nul values (0x00 in binary >> format), the parser stops at this position and cannot parse the rest of >> the message. Therefore, I am missing the information that should be >> copied to the SIP header field, as the parser stops before the end of >> the message body! >> >> As long as the message body does not contain 0x00, it is working fine! >> >> My question is: >> - is this a bug in Kamailio parsing functions? >> - is this a design issue of Kamailio text parsers (as binary data are >> allowed acc. RFC3261) - does anybody know a solution for this problem? >> This "bug" is causing big troubles.... >> >> Thanks in advance, >> Klaus Feichtinger >> >> >> P.S. trace data (1)...(3) of my problem >> >> (1) exemplary content of the x-q931 body >> ======================Sending: Binary Message Body >> Sep 13 10:50:19: Content-Type: application/x-q931 >> 08 01 B4 05 04 03 80 90 A2 18 01 89 1E 02 82 88 6C 05 B1 35 30 30 34 70 >> 05 B1 35 30 30 31 7D 02 91 81 7E 18 04 1D 42 75 25 92 43 31 62 94 00 00 >> 2C 68 20 64 00 62 F2 10 41 B9 D7 BD 0D 0A >> >> (2) SIP INVITE message (debugger view) >> =============================INVITE sip:115101@<ipv4>:5060 SIP/2.0 Via: >> SIP/2.0/UDP <ipv4>:5060;branch=z9hG4bK171164E >> From: <sip:1101015004@<ipv4>>;tag=29E16410-2541 >> To: <sip:115101@<ipv4>> >> Call-ID: 1DBCDACB-1B9911E3-8992FF70-D2BED293@<ipv4> >> Supported: timer,resource-priority,replaces,sdp-anat >> Min-SE: 90 >> CSeq: 101 INVITE >> Max-Forwards: 70 >> Contact: <sip:1101015004@<ipv4>:5060> >> Expires: 1800 >> P-Asserted-Identity: <sip:1101015004@<ipv4>> >> Content-Type: multipart/mixed;boundary=uniqueBoundary >> Mime-Version: 1.0 >> Content-Length: 820 >> >> --uniqueBoundary >> Content-Type: application/sdp >> Content-Disposition: session;handling=required >> >> v=0 >> o=CiscoSystemsSIP-GW-UserAgent 1770 5294 IN IP4 <ipv4> >> s=SIP Call >> c=IN IP4 <ipv4> >> t=0 0 >> m=audio 16384 RTP/AVP 8 0 >> c=IN IP4 <ipv4> >> a=rtpmap:8 PCMA/8000 >> a=rtpmap:0 PCMU/8000 >> >> --uniqueBoundary >> Content-Type: application/x-q931 >> Content-Disposition: signal;handling=optional >> Content-Length: 62 >> 4" l15004p15001}~Bu%C1b..,h d.brA9W >> --uniqueBoundary >> Content-Type: application/gtd >> Content-Disposition: signal;handling=optional >> >> IAM, >> PRN,isdn*,,, >> USI,rate,c,s,c,1 >> USI,lay1,ulaw >> TMR,00 >> CPN,08,,1,5001 >> CGN,08,,1,,,5004 >> UUS,3,1d427525924331629400002c6820640062f21041b9d7bd >> CPC,09 >> FCI,,,,,,,y, >> GCI,185ef1291b9911e381d500270dff3fa0 >> >> --uniqueBoundary-- >> >> (3) config excerpt >> ============if (has_body("multipart/mixed")) { >> if (filter_body("application/sdp")) { >> remove_hf("Mime-Version"); >> remove_hf("Content-Type"); >> append_hf("Content-Type: application/sdp\r\n"); >> } else { >> xlog("L_WARN", " <route> message body part 'application/sdp' not >> found\n"); >> } >> >> $var(UUS)=$(rb{re.subst,/^(.*)UUS,.,([a-z0-9,]*)..[A-Z][A-Z][A-Z],(.*)/\2/s}); >> append_hf("User-to-User: $var(UUS)\r\n", "CSeq"); >> >> if >> !(subst_body('/Content-Disposition..session.handling=required....//s')) >> { >> xlog("L_WARN", " <route> substituting Content-Disposition >> FAILED!!! \n"); >> } >> msg_apply_changes(); >> if (search_body("a=[a-z]+:.+[\r\n]{4}$")) { >> #!ifdef WITH_XLOGDEBUG >> xlog("L_INFO", " <route> double CRLF at the end of the message >> body detected - is reduced to one now. \n"); #!endif >> $var(sdp) = $(rb{s.striptail,2}); >> set_body("$var(sdp)", "application/sdp"); >> } >> } >> >> >> >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> sr-users at lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users at lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > -- > Daniel-Constantin Mierla - http://www.asipto.com > http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda > Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013 > - more details about Kamailio trainings at http://www.asipto.com - _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users