Hi Peter,
I share your concerns about SBCs modifying SIP messages. That
shouldn't happen. If an access network does this they are not
providing true Internet service. However, I think it is the
actual imposition of the kinds of policies discussed in the
draft, rather than the actual mechanism, that is the violation
of the end-to-end principle that will lead to more fragile,
less flexible architectures. I.e., adding explicit signaling
to a middlebox so it doesn't have to modify the SIP messages
does little to address the larger architectural question.
the point I am trying to make is that it does not matter whether or not
you or I like the fact that operators enforce local policies. We don't
like it, but they do it and they will continue doing it. That is a fact.
That is the reality of VoIP deployments.
Now, architecturally, it is much better to have explicit signalling
between the middlebox and the UA than just having the middlebox change
things without informing anyone (like NATs do).
Your proposal of not providing the explicit signalling mechanism will
not keep operators from enforcing local policies but will keep them from
signalling them explicitly. The consequence will be that you will have a
NAT-like device modifying messages without informing anyone.
Therefore, it seems that by not standardizing the mechanism we would be
worse off.
I don't understand at all why an access network would care about
the codec used by a particular application. That seems strictly
a matter for end-to-end negotiation between the participants in a
call.
Some networks can make use of codec-specific optimizations or restrict
codec usage based on bandwidth consumption. When you are managing a busy
cellular network, you do not want terminals using G.711 on it... and you
need a mechanism to tell them that the maximum bandwidth they can use is
well below 64 kpbs. So, they'd better use AMR.
I'll let Russ decide whether he wants to bring the issues I've raised
to the attention of the IESG.
Sure, that sounds sensible.
Thanks,
Gonzalo
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
