A B2BUA is a user agent, not a proxy. It acts as a user agent on behalf of other user agents (so it is involved in registration, call setup / teardown, etc.). Unfortunately the RFCs don't give a lot of direction to their specific implementation.
That said, to me, a B2BUA should act so that any alteration of header fields or parameters should be within the spirit of maintaining the call flow originated by the UAs being served by the B2BUA. They should be as transparent as possible and not interfere with or disallow any features attempted by the UAs. Jeffrey Wright System Test Engineering Manager Aztek Networks -----Original Message----- From: [EMAIL PROTECTED] on behalf of Stephan Steiner Sent: Sun 2/17/2008 4:34 AM To: [email protected] Subject: [Sip-implementors] Header fields in the B2BUA scenario Hi I have a SIP PBX which works in B2BUA mode and I've noted that when it comes to dealing with Header fields, it doesn't stick to the table 2 in chapter 20.1 of RFC 3261. Specifically, it is modifying some header fields which according to that table may not be modifed by a proxy. I contacted the manufacturer and they claim that since a B2BUA isn't a proxy, they don't have to follow the rules established in the RFC and I'm having a hard time countering that since to me, a B2BUA is a proxy seeing as it does what a proxy does (even if the RFC doesn't spell that out) but I'm wondering: Is there any type of UAS to which the header processing rules mentioned before do not apply? Is B2BUA really a loophole to not do things a proxy should do just because it isn't a real proxy per definition (even though it basically does the same things.. it just does more than a proxy does)? Regards Stephan _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
