Menu
▾
▴
#144 Message body has additional \r\n\r\n in message
When trying to send hex representation of DTMF in NOTIFY message body ( CISCO proprietary) , an additional 4 bytes are added to the message body 0x0a,0x0d,0x0a,0x0d.
For Example:-
<send>
<![CDATA[</send>
NOTIFY [next_url] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
Record-[routes]
To:[$From_Content]
From:[$To_Content]
[last_Call-ID:]
CSeq: 5 NOTIFY
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Event:telephone-event
Content-Type: audio/telephone-event
Content-Length: 4
\x0b\x00\x00\x28
]]>
This fails to pass through Kamailio as its flagged as incorrect length. If the content length is changed to 8 , it passes through kamailio but is ignored by a CISCO gateway as the content length is now invalid for the content type .
A Notify message sent from a Cisco ISR has a content length of 4 , but no additional \r\n\r\n bytes on the end of the message body.
Out of interest, does it work if you have the following?
<![CDATA[
NOTIFY [next_url] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
Record-[routes]
To:[$From_Content]
From:[$To_Content]
[last_Call-ID:]
CSeq: 5 NOTIFY
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Event:telephone-event
Content-Type: audio/telephone-event
Content-Length: 4
\x0b\x00\x00\x28]]>
As it stands, you do actually have two newlines between \x0b\x00\x00\x28 and the end of the CDATA, which may be your problem. I've taken a very quick look through the code and can't immediately see anything which would add a "\r\n\r\n" otherwise.
Thanks Rob , I have tried that , and also placing the immediately after the ]]/ on the same line . See below:-
<send>
<![CDATA[</send>
Ive attached the script and the wireshark trace for the result.
Ive gone through RFC3261 and section 7 contains the following :-
"messages consist of a start-line, one or more header fields, an
empty line indicating the end of the header fields, and an optional
message-body."
"The start-line, each message-header line, and the empty line MUST be
terminated by a carriage-return line-feed sequence (CRLF). Note that
the empty line MUST be present even if the message-body is not."
I think that the empty line at the end of the header fields is being applied to the end of the message body as well , although when I check the SDP in the 200 OK the message body doesn't have the empty line ......
I'm digging around in sipp.cpp and call.cpp looking at where the string "\r\n\r\n" is used , and trying to work out which use causes the problem .... not getting very far at the moment!
Wireshark trace of above scenario
Ok I seem to have fixed the issue in call.cpp by changing the following code around line 4119
/ Fix: Remove extra "\r\n" if message body ends with "\r\n\r\n" /
tmplen = (len) - 1;
if ((dest[tmplen] == dest[tmplen-2] && dest[tmplen] == '\n')
&& (dest[tmplen-1] == dest[tmplen-3] && dest[tmplen-1] == '\r'))
{
hdrbdry = strstr(dest, "\r\n\r\n");
if (NULL != hdrbdry && hdrbdry != dest+(tmplen-3))
{
len = (*len) - 2;
}
}
to be:-
/ Fix: Remove extra "\r\n" if message body ends with "\r\n\r\n" /
tmplen = (len) - 1;
if ((dest[tmplen] == dest[tmplen-2] && dest[tmplen] == '\n')
&& (dest[tmplen-1] == dest[tmplen-3] && dest[tmplen-1] == '\r'))
{
hdrbdry = strstr(dest, "\r\n\r\n");
if (NULL != hdrbdry && hdrbdry != dest+(tmplen-3))
{
len = (*len) - 4;
}
}
Seems like somebody already had a go at this but didn't quite crack it.
Not sure if this has side effects anywhere else . Doesn't seem to affect SDP in requests and responses they still have \r\n on the end of the message body. Haven't checked authorisation responses though.
Unfortunately the fix described above appears to do what I require for the Message body in a NOTIFY method , and the CISCO ISR returns a 200 OK but if I use an INFO method then the absence of the \r\n\r\n causes an internal server error #500 response from the CISCO ISR. The fix will have to be applied only to a NOTIFY Method , somehow ...