Hello Pavel,
I recently had a problem with binary content in the body (for
application/ISUP support) and it seem like the fix
to add support by using "\xx" notation works as long as the body content
(with binary data) doesn't need to be changed (by injection).
In my case I could send static binary content in a first INVITE but if
this get rejected (e.g. by a 401) and I add authentication
in the second INVITE the "auth" stuff gets internally injected. This causes
SIPP to recalculate the body location (in memory) and this operation uses
'strlen', which of cause reads a binary content \00 as string termination,
causing body size/location to be misinterpreted. I guess your case is similar
in the sense that the body size/location need to be recalculated after
injection of the file content. I believe I fixed my problem (in a 3.3.990
release) replacing one of the 'strlen' in a memmove operation; I made the
changes indicated below...
I'm not sure this solves your problem but I think it at least gives a hint
where to look. I'm still to get registered to GitHub and
potentially get this fix added ;-)
Changes in call.cpp method createSendingMessage:
Change1:
char* call::createSendingMessage(SendingMessage *src, int P_index, char
*msg_buffer, int buf_len, int *msgLen)
{
char * length_marker = NULL;
char * auth_marker = NULL;
MessageComponent *auth_comp = NULL;
bool auth_comp_allocated = false;
int len_offset = 0;
char *dest = msg_buffer;
bool supresscrlf = false;
unsigned int content_length = 0; //fix for binary content/StefanE
Change2:
/* Fix up the length. */
if (length_marker) {
if (auth_marker > body) {
ERROR("The authentication keyword should appear in the message
header, not the body!");
}
if (body && dest - body > 4 && dest - body < 100004) {
char tmp = length_marker[5];
// Save content length for eventual move after authentication
injection/StefanE
content_length = (unsigned)(dest - body - 4 + len_offset);
sprintf(length_marker, "%5u", content_length);
length_marker[5] = tmp;
} else {
// Other cases: Content-Length is 0
sprintf(length_marker, " 0\r\n\r\n");
}
}
Change3:
// The message body may contain binary data (e.g. containing '\0'),
move using actual length of data/StefanE
unsigned int move_bytes =
body-auth_marker+auth_marker_len+content_length;
/* Shift the end of the message to its rightful place. */
// memmove(auth_marker + authlen, auth_marker + auth_marker_len,
strlen(auth_marker + auth_marker_len) + 1);
memmove(auth_marker + authlen, auth_marker + auth_marker_len,
move_bytes+1);
Hope this helps...
Best Regards
Stefan
-----Ursprungligt meddelande-----
Från: sindelka [mailto:sinde...@ttc.cz]
Skickat: den 18 oktober 2015 09:47
Till: sipp-users@lists.sourceforge.net
Ämne: Re: [Sipp-users] SIPp: binary body part
Hello SIPp team,
I'm coming back to this old thread with an extended need, which is a
possibility to inject the binary bodies from file, to support dynamic test
scenarios where the contents of the binary body needs to be chosen from a set
of predefined values.
When the \xdd syntax is used in the injection file and then the reference to
the field is used in the scenario file, the body contains literally
"\","x","d","d".
When the \xdd syntax is used in the scenario file to fill an in-memory
injection file with the required values, like
<insert file="binbody.table"
value="[$binbody_id];\x03\x02\x03\x00\x05\xc3"/>
the body contains the binary characters as needed but only up to the first null
one.
The tested equipment doesn't understand other than binary-encoded body so use
of Content-Transfer-Encoding is not an option.
Lacking knowledge about the internal interpretation of the string variables, I
don't know what requires less effort to implement, whether interpretation of
the \xdd syntax as late as when expanding [field1 file="binbody.table"
line="[$binbody_id]"] or changing the string handling to allow the in-memory
files (and string variables in general) to contain binary zero octets
mid-string. In my current case, the number of body variants is up to ten so
filling the in-memory injection file from inside the scenario is OK, but maybe
someone else would need hundreds of different bodies, or would even like to
compose the binary body dynamically from parts?
Thank you for ideas or even solutions
Pavel
------------------------------------------------------------------------------
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
------------------------------------------------------------------------------
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
