#144 Message body has additional \r\n\r\n in message

v3.3
open
nobody
None
1
2014-08-20
2013-07-11
hughj
No

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[

  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

  ]]>

</send>

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.

Discussion

  • Rob Day
    Rob Day
    2013-07-11

    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.

     
  • hughj
    hughj
    2013-07-12

    Thanks Rob , I have tried that , and also placing the </send> immediately after the ]]/ on the same line . See below:-

    <send>
    <![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\x29]]>      
      </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!

     
    Attachments
  • hughj
    hughj
    2013-07-12

    Wireshark trace of above scenario

     
    Attachments
  • hughj
    hughj
    2013-07-12

    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.

     
  • hughj
    hughj
    2013-07-25

    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 ...