<brainstorming>
One way of dealing with this is, as we have discussed, to include
sertificate information in the signalling. In the example above, Alice
would be told to check for the name "relay.biloxi.com", instead of
"sbc.atlanta.com".
Another way of dealing with this is of course to say that the
intermeidate MUST terminate TLS in this case. If BOTH Alice and Bob
open
TCP connections (since Bob is behind a relay, I assume he would ALWAYS
be "active"), the intermeidate may need to terminate TLS anyway, in
order to avoid the handshake collision?
Now, one could claim that it is difficult to know what intermediates
will do, since they are not standardized. Jon also asked whether we
would need to specify a new kind of TLS intermediate.
If we want to specify something, I am not sure we need to talk
specifically about intermeidates. I think we can be more generic, and
e.g. talking about "entities which generate SDP for MSRP". That would
then apply to any type of entity.
"An entity which inserts its authority part in the URI of the a=path
header needs to ensure that a matching certificate is provided to
other
entities which connect to it. This can be achieved by terminating TLS
connections (instead of being TLS transparent) or by providing correct
certificate information in the signalling to other entities which
connect to it."
...or something like that. I think that applies to all kind of MSRP
entities - including intermediates.