Subject: Re: [Sip] B2BUA & Max-Forwards

From: "Padma Suresh" <[email-masked]>
Date: Wed, 04 Dec 2002 16:50:42 +0000

A B2BUA is an intermediate network element and MUST maintain the expectations of the endpoints involved in the session.

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.

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: [email-masked], [email-masked]

>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 [email-masked] for questions on current sip

>Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 05 Dec 2002 08:48:57 -0500

--On Wednesday, December 04, 2002 4:50 PM +0000 Padma Suresh 
<[email-masked]> wrote:

>
>
>
> A B2BUA is an intermediate network element
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.

Calling a B2BUA an intermediate network element is probably where most of 
the nonsense on this thread originates. Perhaps that's the basic 
clarification we need in the description to avoid these incorrect 
expectations?

>and MUST maintain the
> expectations of the endpoints involved in the session.
>
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.

> Not forwarding the Require or Expires headers (and some more) would break
> the above which would not be quite acceptable.
>
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...).

> 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.

> which not, could be well avoided.
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.

Dave.

> __________________________________________________
> 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 [email-masked]
> for questions on current sip Use [email-masked] 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: [email-masked]