> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Brian Stucker wrote: > > > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > >> Sent: Friday, October 19, 2007 5:35 PM > >> To: Christer Holmberg > >> Cc: Stucker, Brian (RICH1:AR00); sip; Adam Roach; Michael Procter; > >> Elwell,John > >> Subject: Re: [Sip] INFO > >> > >> > >> > >> Christer Holmberg wrote: > >>> Hi, > >>> > >>> One potential issue: the stateful intermediate receives a > >> NOTIFY without any previous SUBSCRIBE. Is there a chance > it would act > >> on this, e.g. by sending a 4xx response, or are we sure it would > >> always simply forward the NOTIFY and assume the endpoint > will handle > >> it? > >> > >> Are you talking about a B2BUA or a proxy? > >> > >> If a B2BUA, it suffers the common problem that it needs to > be aware > >> of pretty much all the standards in use by those it is connecting. > > > > No it doesn't. A B2BUA does not need to understand a great > many things. > > One thing it does need to understand is how all of the > fundamental SIP > > methods interact with one another. A B2BUA could be doing > anything or > > nothing, but it always has to know when and how dialogs/usages are > > created, maintained and destroyed. That's the minimum requirement. > > > >> If it was not aware of this new extension, and it was trying to > >> enforce rules about what messages are allowed in what > contexts, then > >> yes it might cause trouble. But we specify stuff all the time that > >> has similar issues with B2BUAs. Its up to B2BUAs to figure > out how to > >> be transparent or else go away. > > > > Nice thought, but they aren't going to go away. It is currently the > > case, and going to continue to be the case, that a great > deal of the > > SIP endpoints in this world will only be addressable with a > B2BUA in > > the path for a wide variety of possible reasons. > > Note I said "*figure out how to be transparent* or else go away." > > A B2BUA ought to do the policy enforcement it was *intended* > to do, and not break anything else. If it was *intended* to > block all but a specific set of standard usage patterns, then > so be it. In that case as the specs evolve and the UAs that > use the specs evolve to use the new features, then the B2BUA > will have to evolve to allow the new usages that should now > be considered legal. > > A B2BUA (or proxy) that is in strict enforcement mode is as > likely to block new headers as it is to block messages sent > outside their expected context. So we will have similar > problems with them no matter what approach we take.
Yes, but allowing a new header is typically a matter of configuration. Changing the transaction model for a given method is probably not. > > > Before you flame me, go ask your system engineers how many SIP > > endpoints they've personally seen commercially deployed that were > > addressable via the Internet that were not protected by > some sort of > > ALG or B2BUA scheme that you'd be willing to post the > address of their > > SIP proxy and the usernames of several account holders there. > > > > There may be a few, but they're pretty rare, and that's why > it matters. > > > > It'd be a shame that, by not acknowledging this simple > fact, that we > > wind up building our own walled garden. We need to make things work > > the best we can in the environment we're given, not the one > we wish we had. > > I won't disagree. But we also have to assume that they will > evolve to fit the changing standards. That is one advantage > to standards relative to proprietary approaches. Eventually, but we need to be smart about how we go about fitting things in where there are options available to us and show others the value of supporting a particular standard that is important, etc. Just expecting everyone to blindly go off and implement everything we write down is obviously not realistic. > > At least I think we are, and should try to remain, in a > position where the SBCs follow the standards, as opposed to > where we are re NATs and FWs, where we have to go to > ridiculous extremes (ICE) to work around them. > Yes. We should strike a balance, where possible, for everyone's sake. Regards, Brian _______________________________________________ Sip mailing list https://www1.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
