> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Iñaki Baz Castillo > Sent: 28 October 2008 17:52 > Cc: [email protected] > Subject: Re: [Sip] Comment on DERIVE and B2BUAs > > 2008/10/28 Elwell, John <[EMAIL PROTECTED]>: > > Viktor, > > > > An interesting draft addressing a known problem space. Dan > Wing has already pointed out similarities with > draft-wing-sip-e164-rrc (now expired). I fear the present > draft will not work in the presence of B2BUAs along the path > of the INVITE request, since these tend to change things like > call-ID, to-tag and from-tag. Since B2BUAs, and SBCs in > particular, are the main reasons why RFC 4474 will not work, > any solution has to be able to work through these devices. > > 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.
John _______________________________________________ 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
