https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14328
--- Comment #4 from Jeannot Langlois <jeannot.langl...@mitel.com> ---
"
For now Wireshark selects SRTP exclusively based on the media protocol RTP/SAVP
and not RTP/AVP + crypto attribute.
"
I see -- this explains the current behavior seen.
"
>From what I understand, considering that SRTP should be selected when RTP/AVP +
crypto is present would be wrong also in case the request is rejected by the
peer.
"
Theoretically yes. But with "RTP/AVP"+crypto is used chances of request being
accepted are much greater (at least as far as encryption is concerned) - but it
can be reject for other reasons (e.g. no common codecs, etc).
Essentially, when doing "RTP/AVP"+crypto:
If both endpoints involved in the SDP offer/answer provide a crypto attribute
then streaming packets will be SRTP in both Tx/Rx directions.
Otherwise the streaming packets will be RTP in both Tx/Rx directions.
"
Accoprding to what you explained the 10.46.30.122 machine is not compliant with
RFC as the 200 OK contains a RTP/SAVP + crypto instead of RTP/AVP + crypto
"
Well that is not correct: RTP/SAVP+crypto *IS* how RFC3311/RFC4568 does
things; it's the most common implementation.
What happened in the scenario I've highlighted is that the 10.46.30.122 machine
offered to use "RTP/AVP"+crypto, and the gateway decided to use
"RTP/SAVP"+crypto. In the end, it's the exact same SRTP packets being
exchanged as if both endpoints had said "RTP/AVP"+crypto or "RTP/SAVP"+crypto.
All that matters for SRTP to happen is that both ends need to indicate support
for SRTP and provide a crypto attribute.
If one of them does not then SRTP cannot take place.
The RFC rules, when followed, are just a bit stricter in expecting both
endpoints would indicate the same protocol but in practice it does not make a
difference since once crypto attributes have been exchanged the SRTP packets
are the same no matter what the protocol is.
--
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
