----- Original Message -----
From: "Guy Harris"
| On Jan 26, 2004, at 3:00 PM, Sean Schneyer (TX/EUS) wrote:
|
| > I tried setting the preferences as you suggested and that didn't
| > change the behavior.
|
| I.e., even with the preferences off, frame 248 is marked as an MMS
| m-send-req?
|
| That's what happens when I read the capture. Frame 248 is the
*LAST*
| packet with a TCP segment for the MMS m-send-req that starts in
frame
| 147 and includes frame 149.
If you open the TCP protocol tree on packets 147 and 149, you'll see
that the lastmost entry is a "Reassembled in" field which refers to
packet (or frame) 248. If you right-click on this field, and select
"Go to corresponding packet", you'll get to the reassembled MMSE in
packet 248. The way Ethereal handles fragmented protocol data is that
it first needs to reassemble the data before it can dissect the data.
With the heuristic MMSE-over-HTTP dissector this wasn't true but the
MMS message was not entirely dissected then. And packet 248 happens to
contain the last data fragment for the MMSE PDU.
| Frame 147 is the HTTP POST method line and headers. Frame 149 is
the
| first frame of the body of the HTTP POST, i.e. the first frame of
the
| MMS m-send-req.
|
| Prior to the addition of support for HTTP reassembly and dissection
| based on HTTP media types, the MMSE dissector was a heuristic
dissector
| atop HTTP, so it would be handed HTTP payload and thus would see
frame
| 149 as the beginning of an MMSE MMS m-send-req.
|
| Now, however, it's registered as a dissector for the
| "application/vnd.wap.mms-message" media type, which means the HTTP
| dissector will call it only if it knows that the media type is
| "application/vnd.wap.mms-message" - which it won't do unless it's
| reassembling the HTTP headers and data, because otherwise the
headers,
| including "Content-Type", are in one frame and the MMSE body is in
| another frame.
|
| So MMSE support isn't broken; it's just that HTTP support behaves
| differently (and better, as it can now dissect the *entire* MMSE
| message, for example).
|
| (BTW, Olivier, should application/smil be handed to the generic
| line-based text data dissector?)
This has already been checked in :)
| (Also, is the MMS message in that capture an indication that when I
get
| a mobile phone I should consider *not* getting an MMS-capable phone?
| Perhaps SMS is to MMS as text-based mail is to multimedia mail - I
| guess it's useful to have a multimedia-capable {mail reader, phone},
| but I fear it's a capability all too easy to abuse. I can image
that
| I'd probably even just get pretty tired after a while of having my
| phone play a few bars of "Misirlou" or "Romantist" or "London
Calling"
| every time it rings....)
Most of the people use MMS for transmitting a photo with some text to
some other users. It's more some sort of a postcard today. The MMS
message itself consists of a WSP multipart body which encapsulatates
all the entities that are part of the MMS. One can be very creative
with MMS though, as you can see from this capture :) The SMIL content
describes what should happen, when it should happen (and how) with the
other entities from the multipart.
Regards,
Olivier
