You'll get very significant pushback from nework operators because
of increase demand on proxies.
It also means that it's unsecure at answer time.
Er, I don't think so. If you offer RTP/SAVP, and it's rejected by the
answerer (called party), the called party's phone won't ring at all.
It's a valid mechanism, but I don't think it's the best we can do.
Due to HERFP, I consider re-inviting a mechanism that cannot work. Unless
we fix HERFP or deprecate forking.
I think IKR is right: we need to answer the very basic question
about do we "HAVE to use SAVP" to mean best effort.
The draft that Hadriel and I did assume "No".
Flemming's draft assume "Yes".
A correction: both drafts put RTP/AVP in the "m=" line.
The offer in draft-andreasen-mmusic-sdp-capability-negotiation-01.txt, on
page 16, is here (I show the interesting lines with "**"):
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
** m=audio 3456 RTP/AVP 0 18
a=sqn: 0
** a=cdsc: 1 audio RTP/AVP 0 18
** a=cdsc: 3 audio RTP/SAVP 0 18
a=capar: 1 a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg: c=3,4 a=1
a=pcfg: c=1,2
The answer is described and shown on page 17:
Bob receives the SDP offer from Alice. Bob supports RTP, but not
SRTP, and hence he accepts the potential configuration for RTP
provided by Alice:
v=0
o=- 24351 621814 IN IP4 128.96.41.2
s=
c=IN IP4 128.96.41.2
t=0 0
** m=audio 4567 RTP/AVP 0 18
a=acfg: c=1,2