Jeroen van Bemmel wrote:
Vijay,
Jeroen: Thanks for reading the draft. More inline.
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
That could be an optimization to consider. As I see it, there are three network topologies where this would be useful: 1) IETF rfc3261-type ecosystems: I suspect that here we'll have two, at most three proxies in such ecosystems; so such an optimization can be avoided. 2) IMS-type ecosystems: Given the high number of intermediaries that will field a request, the optmization may be helpful here. 3) P2P-type ecosystems: If recursive routing is being used to reach the peer, the optimization may be helpful here as well.
Also, I would suggest to make CONNECT a well formed SIP request (possibly with dummy values).
The current draft does not limit the headers that can appear in a CONNECT request. From intermediary transaction idenitification point of view, only a Via is needed. Dialog usage that requires To, From and Call-ID is an endpoint function, and in this case, the endpoint has other means to establish that dialog (i.e., set up the TLS tunnel and then send a dialog-establishing request over it.)
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)
Would not the current option tag suffice? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: [EMAIL PROTECTED],bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ 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
