On Apr 1, 2009, at 9:09 AM, Dwight, Timothy M (Tim) wrote:
John,
In my experience, service providers (such as the one I work for)
sometimes change the SDP in situations like this, and sometimes don't.
It depends on whether the service providers' VoIP infrastructure is in
the public Internet address space, or a private address space (e.g.,
MPLS/BGP -based VPN). Use of the latter configuration requires NAT
and
SIP ALG functionality "at the edge". In the diagram below there is an
"edge" everywhere you draw an arrow. Typically the devices that
implement the NAT and SIP ALG functions do other things, like topology
hiding and steering the media to a device that will then monitor
("police") its arrival rate.
One might argue that we know how to do NAT without ALG -- we use ICE
to discover candidates for the offer/answer, and the media finds the
path that works using STUN probes.
Could we use ICE to get to the steering points? Do we really need
them, or is this just a brute-force way to solve a problem to which
other tools should have been applied?
Topology-hiding is another question. Does it benefit the Internet
architecture? Do we need to warp our protocols to allow it?
Alternatively, if the SP's infrastructure is in the public address
space, you typically don't see NAT / SIP ALG or topology hiding or
media
steering. You may (often do) still see "border devices" doing things
like traffic aggregation and policy based routing.
Do we need SDP editing to allow these functions, or is there a cleaner
way to do it?
In either case, it's not uncommon that the border elements modify
other
aspects of the SIP signaling for reasons of interoperability. For
example it's sometimes [believed to be] necessary to modify response
codes due to differing implementations - e.g., to break an
infinite-retry loop.
Do such modifications break RFC 4474?
--
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
