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