Vijay,
An initial comment: it seems wasteful to keep all proxies that are used to
discover a path towards the UAS in the path of all signaling, acting as
pass-throughs. Rather, there should be some mechanism to keep only the
proxies that are needed to traverse NAT boundaries (e.g. those with an
outbound flow towards the UAS)
I imagine a two-phase approach: CONNECT as you have, let proxies that "know"
they need to stay in Record-Route, then send a second CONNECT across the
discovered Route
Also, I would suggest to make CONNECT a well formed SIP request (possibly
with dummy values). That would allow current proxies to participate in phase
1 of CONNECT without change (although they might Record-Route since CONNECT
would be an unknown method - would need to strip such proxies from the
discovered Route, e.g. by mandating a special tag to use for R-R for proxies
that know what they're doing, removing all other entries)
Regards,
Jeroen
Vijay K. Gurbani wrote:
Hello: The notion of STARTTLS-like functionality in SIP has been
mentioned on the list many times, in conjunction with end-to-
end authentication that goes beyond the hob-by-hop model of sips.
draft-gurbani-sip-sipsec-00 explored a possible way to accomplish
this, without dvelving into too much of the details.
The latest revision (-01) provides more details on the mechanism.
A review of the draft and any comments would be much appreciated
by the authors.
Until it becomes available in the archives, you can get a copy
from:
https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.txt
https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.html
Thank you.
- vijay
_______________________________________________
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
