> El Miércoles, 29 de Octubre de 2008, Dan Wing escribió: > > > Would the SBC not have to handle the SUBSCRIBE request > locally? After > > > all, since it is a terminal UA for the call, it also knows > > > about all the > > > dialog states. The end-user UA would never even see the SUBSCRIBE. > > > > If that's a problem, just use some different method that goes end to > > end. The always-loved INFO comes to mind. > > Anyway, you need to carry in the INFO body (or headers) data > about the current > dialog, but this data changes in both legs of the B2BUA, so > it will fail. > It's exactly the same case as if the SUBSCRIBE is "forwarded" > between B2BUA > legs without replacing the dialog data (from leg B to leg A).
And that is why there are two proposals that use something that can't change -- the certificate fingerprint of the endpoint: draft-fischer-sip-e2e-sec-media (expired) draft-wing-sip-identity-media (expired) They expired due to lack of interest. Let's talk about the meta-issue: do we want assurance of a "From:" over SBCs? If so, let us please convince the ADs in Minneapolis and let us please get a new SIP milestone. -d _______________________________________________ Sip mailing list https://www.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
