Vijay, > > 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)
RFC 3261 section 8.1.1 states: "A valid SIP request formulated by a UAC MUST, at a minimum, contain the following header fields: To, From, CSeq, Call-ID, Max-Forwards, and Via; all of these header fields are mandatory in all SIP requests. These six header fields are the fundamental building blocks of a SIP message, as they jointly provide for most of the critical message routing services including the addressing of messages, the routing of responses, limiting message propagation, ordering of messages, and the unique identification of transactions." Even if all these header fields are not strictly needed by entities that support sipsec, I think we should continue to mandate them, even if they contain dummy values. Otherwise it might have unnecessary impact on SIP stacks or might lead to unexpected responses (e.g. 400). John _______________________________________________ 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
