Just to synchronize with a parallel universe...
about five minutes after completing WGLC on MEDIACTRL requirements, we
started wondering about scenarios where there's an SBC/B2BUA between the
Application Server and Media Server.
We're having The Usual Discussion where some people are saying "SBCs can
change our dialog identifier components (local-tag/call-ID/remote-tag), so
we need a new header" and other people are saying "SBCs can drop new
headers, so we DON'T need a new header".
Hilarity ensues.
I was especially pleased to see Paul's note:
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.
... at least I don't think we're missing something obvious (although it
would have been nice if we were).
I strongly agree with Paul's final paragraph.
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
Thanks,
Spencer
_______________________________________________
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
