[bugzilla-daemon@xxxxxxxxxxxxx]

Peter Wu changed bug 9840

What	Removed	Added
Status	UNCONFIRMED	CONFIRMED
CC		peter@lekensteyn.nl
See Also		https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9021
Ever confirmed		1

Comment # 1 on bug 9840 from Peter Wu

Currently (v2.3.0rc0-1622-g5721a87) the SIP dissector signals to the SDP
dissector (via setup_sdp_transport) whether a packet:

 - creates a new offer (requests)
 - an answer that rejects the offer (>= 4xx)
 - an answer that accepts the offer (2xx)

To handle early media, "provisional" 1xx responses
(https://tools.ietf.org/html/rfc3261#section-13.2.2.1) should probably also be
accepting an offer, otherwise early media might not be tracked.

(As a workaround for bug 9021, the first SDP from the offer is applied without
waiting for the answer (when sip.delay_sdp_change=FALSE (default)), but that
should probably be undone when 1xx is handled.)

Also note that 200 OK for OPTIONS or 488 for INVITE are just informative, they
are not answers to a previous offer
(https://tools.ietf.org/html/rfc6337#section-2.4). This is currently
mishandled. Similarly, Bug 5208 is about RTSP where there is also no
Offer/Answer model (and a mean is needed to export the media info to the parent
dissector, RTSP).

I *think* that the current approach of storing the current state in the SDP
dissector is appropriate since the Offer/Answer model is part of SDP.
Dissectors can signal via setup_sdp_transport the current status (new offer or
accepted/rejected offer).


Possibly helpful references:

An Offer/Answer Model with the Session Description Protocol (SDP)
https://tools.ietf.org/html/rfc3264

SDP Offer/Answer Examples
https://tools.ietf.org/html/rfc4317

Session Initiation Protocol (SIP) Usage of the Offer/Answer Model
https://tools.ietf.org/html/rfc6337

---

      You are receiving this mail because:

• You are watching all bug changes.