no it isn't. It's one or more UA's in the same box communicating with each other using some private machinery, such as an API+application code.A B2BUA is an intermediate network element
Also incorrect. Since the B2BUA is at least 2 UA's its job is to SEPARATELY maintain the expectations of EACH endpoint it is talking to. This does not infer ANY transitivity properties across a B2BUA at all; in fact, if you wanted well-defined transitivity you would have put in a proxy instead.and MUST maintain the expectations of the endpoints involved in the session.
Disagree vociferiously. As others have pointed out, it is crucial to NOT forward any headers. You MUST consume them and process them on receipt. You must GENERATE and send them on transmit. What happens in between is whatever algorithm or algorithms the application doing the B2BUA functions deems appropriate. If there is any relationship at all between the input and the output, that relationship is established by the the application logic. If the application logic performs the identity mapping, then that is what the application thinks is the appropriate thing to do. If the application logic (for example) decrements Max-Forwards by 42 because Douglas Adam's probate attorney wrote it, that's ok too (as long as the result is >0 of course...).Not forwarding the Require or Expires headers (and some more) would break the above which would not be quite acceptable.
However, yes, the B2BUA can choose to step out of the signalling path by setting the contact header to the appropriate endpoint.
It is not *in* the signaling path.
If this level of misunderstanding of SIP persists by having the spec talk about B2BUAs, then perhaps the best this to do is the radical step of simply removing all references to them and banning the term from the lexicon.Vijay I agree that the ambiguity of choosing which header to pass on and which not, could be well avoided. Regards Padma
From: "Vijay K. Gurbani" To: Padma Suresh CC: pete@tech-know-ware.com, sip@ietf.org Subject: Re: [Sip] B2BUA & Max-Forwards Date: Wed, 04 Dec 2002 09:21:11 -0600 Padma Suresh wrote:Vijay, You are right - A B2BUA needs to propagate some of the headers received in a request/response to the other endpoint.Choosing which headers should be passed by a B2BUA and which not is exactly the ambiguity that we should AVOID, as I pointed out in my my response to the original poster. As others have expressed, we may try to taxonomize different types of B2BUAs, but each will have a different manner of handling the headers (depending on the application being realized by that particular B2BUA). An anonymizer B2BUA may change To, From, Contact, etc, for instance (and maintain internal state). A network-hiding B2BUA may scrap all Via headers coming in and only expose one Via header going out. The possibilities are endless.Example: Require, Expires to name a few. This is because these headers actually are relevant end to end.A B2BUA may decide to consume the Require and change the Expires header (maybe decrease its value) before sending it downstream, thus causing havoc with the expectations of the sending UAC.However, some of the other headers like Contact should be set by the B2BUA as itself.Likewise, I can imagine a B2BUA which rendezvous two users and steps out of subsequent signaling. Thus the Contact it sends to each of the users is that of the other peer. I would strongly *stay away* from prescribing which headers must be passed by a B2BUA and which must not. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip__________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8._______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip