Elwell, John wrote: > > IBC said: >> Since the B2BUA has detailed info of both legs A and B, it is >> capable of doing needed changes, as replacing call-id and to-tag in >> Event header. Also, the B2BUA could handle the SUBSCRIBE by its >> own, this is, becoming a dialog presence server instead of >> forwarding the SUBSCRIBE to the UA. B2BUA must handle all this >> stuff since they are, in fact, the end point, not the UA's behind >> them. > > [JRE] This reduces it to transitive trust, i.e., no better than > P-Asserted-Identity. The UA that receives the INVITE request has to > trust its local B2BUA to confirm that the INVITE request really did > come from the wherever it claimed to have come from. > >
Since the INVITE is coming from the SBC (even though the SBC was influenced by something else to get it to send the INVITE), I don't see a problem with this. Otherwise said, SBCs are always transitive trust unless we have end-to-end crypto, in which case we don't really have SBCs. So? -- Dean _______________________________________________ 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
