-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxx]
Sent: Tuesday, June 12, 2007 11:53 AM
To: Hannes Tschofenig
Cc: Francois Audet; Eric Rescorla; Lakshminath Dondeti; Dan
Wing; ietf-rtpsec@xxxxxxx; Sam Hartman; Tim Polk;
jon.peterson@xxxxxxxxxxx
Subject: Re: Additional use cases? (Re: Plan for moving forward)
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 own
request 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 (as
in,
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.tx
t 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