https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2368
Jörg Mayer <jmayer@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jmayer@xxxxxxxxx
--- Comment #12 from Jörg Mayer <jmayer@xxxxxxxxx> 2012-08-02 13:43:29 PDT ---
OK, I looked at this a bit using the first trace and it looks like comment #7
basically right (but note that I did not look at the spec but simply assume
that sending of t.38 packets is only allowed once a "200 <whatever>" is
received.
The problem is that the detection of the change request is inside sdp, while
the answer is a sip only answer.
So it looks like it would be necessary to add some state to the sip
request/response tracking structure to track the protocol change requests. The
format would probably be tristate: yes, requested, no.
For this particular bug, this would mean to move is_t38 and everything that
uses this variable into packet-sip.c and make is_t38 tristate as mentioned
above. By default is_t38 would be "no". Once the sdp dissector sees the invite
to change this communication to t38, it would change is_t38 of the sip
dissector to "requested" and do nothing else. Once the sip dissector matches a
response to the request in it's request/response matching code, the actual
response code would determine whether is_t38 is set to "yes" or "no". If the
answer is "yes", the code (currently in packet-sdp.c) to change the connection
type to t38 needs to be called.
I've never looked at the sip/sdp code in detail, but for someone who knows the
code:
a) does this approach sound right?
b) would it be that much work?
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
