I like the direction this is headed. I have a few questions and
observations:
There seem to be some constraints for support of sipsec that I didn't
see mentioned explicitly:
- The UAC and each proxy must ensure that the transport used
for the next hop is a connection-oriented, congestion-controlled
transport. That is mentioned in the overview, but not specifically
for the UAC and Proxy.
- For the tunneling to work I don't think there can be shared use
of the connection. That is something special here. (In case of
SCTP, I guess it would be sufficient to reserve a stream.)
There are some things that is is desirable to do that may be hard with
sipsec, or at least need to be figured out. A couple that come to mind are:
- best effort security
- forking
For best effort security, one option seems to be to delay the CONNECT
until you know the capabilities of the callee. For instance, a session
could be established with SIP or SIPS, including supported:sipsec. If
the session is established, then it could be followed up with a
CONNECT/Replaces.
If you want to call an AOR that results in forking, CONNECT doesn't seem
to work very well. I This may be a good reason to replace forking at a
proxy with redirect. The proxy could return 3xx with the alternatives,
which might be either SIP, SIPS, or SIPSEC. There are a lot of details
to work our for this.
Thanks,
Paul
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
