Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 1716] Unable to decode SIP-T encapsulation with "white spa

Date: Thu, 9 Aug 2007 09:09:22 +0000 (GMT)
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1716





------- Comment #5 from anders.broman@xxxxxxxxxxxx  2007-08-09 09:09 GMT -------
Hi,
It looks to me like the first body part is wrongly encoded
http://www.ietf.org/rfc/rfc2046.txt?number=2046
5.1.  Multipart Media Type

   In the case of multipart entities, in which one or more different
   sets of data are combined in a single body, a "multipart" media type
   field must appear in the entity's header.  The body must then contain
   one or more body parts, each preceded by a boundary delimiter line,
   and the last one followed by a closing boundary delimiter line.
   After its boundary delimiter line, each body part then consists of a
   header area, a blank line, and a body area.  Thus a body part is
   similar to an RFC 822 message in syntax, but different in meaning.
---
The First body header:
MIME Multipart Media Encapsulation, Type: Boundary: unique-boundary-1\r\n
0000   4d 49 4d 45 20 4d 75 6c 74 69 70 61 72 74 20 4d  MIME Multipart M
0010   65 64 69 61 20 45 6e 63 61 70 73 75 6c 61 74 69  edia Encapsulati
0020   6f 6e 2c 20 54 79 70 65 3a 20 42 6f 75 6e 64 61  on, Type: Bounda
0030   72 79 3a 20 75 6e 69 71 75 65 2d 62 6f 75 6e 64  ry: unique-bound
0040   61 72 79 2d 31 0d 0a                             ary-1..
is followed by CRLF making the rest the body i.e 
Content type etc is considered data.

The second body should be decoded that it's not is a BUG...


-- 
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.