> -----Original Message-----
> From: Adam Roach [mailto:[EMAIL PROTECTED]
>
> In theory, you're talking about To, From, Call-ID, CSeq, Date, Contact,
> and the request body. Proxies aren't allowed to change those (with the
> exception of To and From, which are done only in the context of 4474 and
> RFC 4916), and user agents set them before the 4474 signature goes on
> them.
>
> In practice, the elephant in your elephant (or small hairy predator) is
> the body. You're talking about SBCs, and the thing that SBCs want to
> change that breaks RFC 4474 is the body.

Actually, lots of things change the To and From.  If you built a "proxy" that 
can't be configured to change 'em, you're probably not in business long.  Of 
course you're not a 3261 proxy at that point, but more of a b2bua.  Heck, lots 
of things change Call-id and Cseq and Contact, too.  You're talking like the 
whole mammal class that changes at least one of those 
To/From/Call-id/Cseq/Contact things, not just elephants.


> And that was kind of a
> necessary hack back before user agents did much in the way of NAT and
> firewall traversal. But any real, commercial user agent I've played with
> in the past five years or so has at least rudimentary support in this
> area, such that body tweaking is mostly unnecessary.
> In other words: there's a better solution than body mangling, and it's
> supported by most modern SIP clients. Let's not gut 4474 to maintain our
> older, broken network architectures.

It's really not a secret that SBC's change SDP for a whole bunch of reasons 
that have nothing to do with NATs.  And the list of reasons is actually 
growing, sadly, not getting smaller.  But that's not the point.  Sign SDP if 
you feel you need to.  Don't sign something you don't feel you need to.

-hadriel
_______________________________________________
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

Reply via email to