Re: francois' comments and why RFC4474 not used in the field
Dean Willis <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
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