> Hi Dan and John, > > I actually do have a counter-example which makes me a bit > worried -- NATs.
I've heard about them. > (not meaning to disagree ... just trying to understand the > evolution cycle) > Think of IP addresses in application payload with NATs. That appears > remarkably > similar as reference to a call in SUB/NOT in DERIVE, which -- if not > translated > by the B2BUA that translates it in callid/to/from > header-field -- will fail. > Obviously ignoring NATs didn't work quite well. > > I would tend to be pragmatic and like to make DERIVE > B2BUA-resilient, I'm > just failing to see how. If a UA can be smart and robust > enough to deal > with strange things in the network, why don't we do that. The > problem is > really I don't see a clear way of doing that. To my best > knowledge, there > is not a single piece of SIP message which a B2BUA would guarantee to > deliver to the other party. The notion of B2BUA is largely unspecified > in its behaviour. > > We could try to guess a behaviour of a "resonable B2BUA". For > example we > could assume that if we don't put dialog references in > payload (e.g. by > using > an in-dialog new-method IS-IT-YOU request), the dialog > reference will be > translated like for the initial INVITE and things will work. > > So in summary these are IMO the options to deal with it: > a) ignore B2BUA traversal in anticipation if they break something, > they will be motivate to fix it > b) align the design to something we guess has a better chance > to get through B2BUAs without a normative reliance on their > behaviour (but what could it be???) > c) in addition to a/ or b/, do B2BUA-BEHAVE :) > > > Aside from architectural and evolution arguments on both a > and b, does anyone > have an opinion on what can safely get through the B2BUAs? RTP, after the call is set up. Everything else is problematic to varying degrees. If SBC vendors and SP see it is possible to provide (some sort of) "identity", while still preserving the reasons they deploy SBCs, they will do it. Especially when spammers start stealing identities and reducing the effectiveness of whitelists beause of those stolen identities. -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
