One issue, which was raised in mmusic, is that RFC 4145 links together directionality of TLS and directionality of the TCP connection. Here, you are using RFC 4145 JUST to indicate TLS directionality. This causes things to get messed up with ICE; ICE will establish the TCP connections using its own attributes to indicate directionality, and furthermore allows for simultaneous opens. Thus, the direction of TCP connection opening can be independent from the TLS roles.
Its not clear to me we should be reusing the comedia directionality attributes.
-Jonathan R. Hannes Tschofenig wrote:
Hi Francois, Francois Audet wrote:I agree with Eric. More on the "it doesn't matter who is the caller" stuff: On the RFC 4474 side, RFC 4474 allows for the sender of the request to provide the identity assertion. Yes, indeed, this is the calling party. There is no "response" identity. However, the callee may send its ownrequest in the reverse direction to provide it's own identity, as per draft-ietf-sip-connected-identity-05.txt.In other words, in SIP also there is no implied "direction" to this,even if technically, the origin of the protocol used a client/server model (asin, request/response). I think we'll have to write up a "high level" description on how these pieces fit together.http://tools.ietf.org/id/draft-fischl-sipping-media-dtls-02.txt is meant to provide how these pieces fit together. Do you think that there is something missing that needs to be added?Ciao Hannes
-- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@xxxxxxxxx FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com