Agreed. Basically, say the "CONNECT" ended up in 3 different directions after a 3XX with 3 contacts. The UAC would set up the end-to-end TLS connections from the UAC to the 3 contacts.
Then the INVITEs have no intermediaries, so they can't fork. > -----Original Message----- > From: Elwell, John [mailto:[EMAIL PROTECTED] > Sent: Monday, June 18, 2007 23:53 > To: Vijay K. Gurbani; Paul Kyzivat; Audet, Francois (SC100:3055) > Cc: IETF SIP List > Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 > > Vijay, > > > And finally, forking a non-INVITE request at a proxy should still > > result in one 2xx, or a best non-2xx being returned to the UAC. So > > user agents can inherit much of the current transaction-related > > behavior for CONNECT and augment it with the certificate and tunnel > > behavior. > [JRE] I just don't get how this would work. The UAC receives > only one 2xx and as a result initiates one TLS handshake with > the UAS concerned. > The UAC never gets to hear about any of the other forked-to > UASs that might have sent a 2xx, so can never establish a > tunnel with those. > > 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
