What Scott says seems reasonable. In his case, if the feature is turned
off it really is a proxy. If the option is turned on, and SDP is
updated, then the best you can say is that it is a proxy with
non-compliant behavior.
Thanks,
Paul
Scott Lawrence wrote:
> On Wed, 2009-01-07 at 16:17 +0100, Victor Pascual Ávila wrote:
>
>>> If it breaks these rules, it is no longer acting as a proxy.
>> When a caller is behind a NAT, rewriting SDP in INVITE to include an
>> RTP relay's address in it is a pretty common practice.
>> Leaving RFC3261 fundamentalism aside-- do we consider it then still
>> legitimate enough to call it a "SIP proxy"?
>
> To be fair to your customers, call it a "SIP Proxy*" with an explanation
> for the '*', or "A SIP Proxy with additional NAT Traversal
> functionality". That's what we're doing at the sipXecs project (which
> is based around a true proxy that now has the ability to mangle SDP for
> NATs, but since we can turn that off we still call it a proxy).
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
