On Mar 31, 2009, at 5:31 PM, Cullen Jennings wrote:
On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote:
I'm worried this is only a wishful thinking. While perfectly
logical, still even in such constrained setups some bizzar
ALGs do in my experience appear in the middle, change SDP
and make thus the identity worthless.
The thing I keep asking is can we make a list of reason why SDP and
headers get changes and in what scenarios they do this. I think it
will be hard to sort how to fix this without being clear what needs
to be fixed.
For example, one of the things we might want to say is something
like: the Phone is behind a NAT and connects to it's proxy /
registrar for its' domain. That proxy/b2bua whatever mucks with IP/
ports in the SDP for NAT traversal. Then we could ask if 4474 is
broken in this case or not and what might be a good way of solving
the problem of having UAs behind NATs.
You seem to be trying to construct an argument for "why 4474 isn't
broken" based on being able to transform every use case where RFC 4474
breaks to one where it doesn't, generally by mandating a different
approach to solving problems (TURN vs, SDP fixup, for example). You
seem to expect this to prove that RFC 4474 is fine as-is, needing no
modification to its A/M signing.
It might be useful to counter this with "If RFC 4474 isn't broken, why
isn't it being deployed?" I expect that the answer is "because users
currently expect to correct their topological issues using SBCs
instead of the tools that work with 4474. You might not think they
have legitimate reasons for doing it this way, but the fact remains --
that's how they do it. Technically correct or not, ordering this to
flow out is likely to give you wet feet.
--
Dean
_______________________________________________
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
