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.
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.
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.
Paul
_______________________________________________
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
