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