https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6844
--- Comment #25 from Lars Ruoff <Lars.Ruoff@xxxxxxxxxxxxxxxxxx> 2012-05-30 00:42:59 PDT ---
(In reply to comment #21)
> The uasip dissector is registered to the media_type "application/octet-stream".
>
> I certainly have no experience with SIP and NOE protocols, but this
> registration catches my eye.
>
> Surely the media_type "application/octet-stream" covers far more than SIP/NOE
> ??
>
> When (in what protocol) would an octet-stream media type mean SIP/NOE ??
> (Is that the right question ?)
>
> (Wireshark currently has no other registration for this media_type so I guess
> the question is, at this point, a bit theoretical).
There is no way to tell wether SIP payload is UA/NOE or something else.
So i guess it should be enabled/disabled via a preference setting.
Actually there *is* a preference setting "Protocols/UASIP/Try to decode SIP
NOE", but this is used only at a higher level:
The current dissection hand-off is like this:
- SIP
... handed-off via Content-Type: application/octet-stream
- UASIP
... handed-off via "Protocols/UASIP/Try to decode SIP NOE"
... (also needs the "Protocols/UASIP/Proxy IP Address" setting to get it
right")
- UA
- NOE
The above setting enables/disables the hand-off between UASIP and the following
protocols.
So there probably needs to be another setting for handling the hand-off between
SIP and UASIP.
Actually, i think the above setting could be changed and recycled to mean just
that, because it makes little sense to decode the SIP body as UASIP without
decoding also the rest of the protocol family.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
