https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14328
--- Comment #2 from Jeannot Langlois <jeannot.langl...@mitel.com> ---
Hi Pascal:
"
Do you know why the first INVITE is using RTP/AVP? Does the 200 OK with
RTP/SAVP is supposed to change the protocol used for both directions of this
UDP connection?
"
There are actually two ways to do SRTP that I know of:
1) "All-or-nothing" -- RFC3711+RFC4568:
- Use of "RTP/SAVP" as the protocol
- Presence of a "crypto" attribute in both the SDP offer and answer.
- Both the offerer and answerer MUST support "RTP/SAVP" for the session to
succeed with 200 OK (otherwise an error code like "488 Not Acceptable Here" is
emitted by the answerer).
2) "Best Effort SRTP" --
https://tools.ietf.org/html/draft-kaplan-mmusic-best-effort-srtp-01:
- Use of "RTP/AVP"
- *BUT* a "crypto" attribute is *still* included in the SDP offer.
- Depending on whether it supports usage of encryption (or not) the answerer
responds _with or without_ a "crypto" attribute -- but always with the
"RTP/AVP" protocol.
- This allows to "downgrade" to regular unencrypted RTP if encryption is not
supported to perform SRTP and still succeed with 200 OK instead of rejecting
with "488 Not Acceptable Here" if encryption is not supported by the answerer.
.
.
.
>From this one can see a number of possible permutation cases for the messages
exchanged on each side of the gateway.
In the specific case at hand which I've reported here, the gateway was
configured in a way where it always offers or answers with "RTP/SAVP" (no
matter that the side is); so yes -- it did change the protocol of the INVITE
from one side to the other.
This gateway is a B2BUA (Back To Back User Agent) gateway so this is allowed
with the INVITE request -- both gateway sides are independent "call legs": one
side thinks it is talking with the server while in fact, the gateway is acting
on beyond of the original client when talking with the server on its other side
-- and vice versa.
Next, one might argue that changing from "RTP/AVP" to "RTP/SAVP" on the *same*
side by the gateway from the offer in the INVITE to the answer in the 200 OK is
questionable (and I would somewhat agree).
However, from my experience in the field with many devices/endpoints of
multiple vendors of various implementation qualities, I see many vendors do not
pay too much attention to these little details and still do things of the kind
even if not officially allowed by RFCs.
We're allowing our gateway to be configured by an administrator to do things
like that to maximize chances of proper interoperability when someone hooks up
third party endpoints that have not been certified and find out too late that
they have poor quality implementations that do not quite behave properly
according to RFC rules -- but still require a get-out-of-jail-fast method to
get their systems in a working state.
So my opinion on this is that if an endpoint is able to perform SRTP encryption
(either with RFC3711/RFC4568 or the draft-kaplan-mmusic-best-effort-srtp-01
draft) it should not really matter if the protocol is "RTP/AVP"+crypto or
"RTP/SAVP" -- it's the same SRTP packets that get exchanged in the end, so they
should be recognized as such by the dissection.
--
You are receiving this mail because:
You are watching all bug changes.
___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
