There really isn't any single answer to your questions that is applicable to all B2BUAs in the situation you describe. The answers depend on what your B2BUA is trying to achieve.
For instance, it could be that it is trying to be a "transparent" B2BUA, being almost as unobtrusive as a proxy, but reserving the right to send a BYE to both sides.
Or, it could be that the B2BUA is operated on behalf of B's user. E.g. Perhaps B is a particularly stupid 2543 compatible phone, and the B2BUA is being used as a frontend for it, to enhance it for compatibility with 3261, to add security, etc.
Or, the B2BUA could be at the boundary of a service provider domain, enforcing all sorts of rules for the domain.
Each of these is likely to result in different answers to your questions. If you can precisely define your objectives, then people may be able to help you answer the questions. But probably by the time you have done that you will be able to answer them yourself.
Paul
Andreas Bystr�m wrote:
Hi all,
I have some questions about how a B2B should behave. The scenario is : A - proxy 1 - B2B - proxy 2 - B
1) Should all fields be kept from the incoming request to the new request sent out (in the B2B). I will remove (or change) via-list, call-id, record-route and contact. All other headers, should they be kept? As an example we can take the User-Agent sent from A via proxies and B2B to B.
2) When B sends BYE, is the B2B supposed to answer with 200 OK or sould it forward the BYE first and wait for a 200 OK from A before it sends the 200 OK back to B
And in the end a short question about 407 authentication. If A sends Invite to a proxy where it has to authenticate itself, is it OK or not OK for the proxy to first send 100 Trying and then send 407? As I understand it, it is OK according to the RFC since the first is a provisional response and the second a final response. Just want to check with you since I have never seen this behavior before.
Thanks in advance!
// Andreas
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
