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

From: "Padma Suresh" <[email-masked]>
Date: Tue, 03 Dec 2002 21:35:46 +0000

Vijay,

You are right -

A B2BUA needs to propagate some of the headers received in a request/response to the other endpoint.

Example: Require, Expires to name a few. This is because these headers actually are relevant end to end.

However, some of the other headers like Contact should be set by the B2BUA as itself.

Padma

>From: "Vijay K. Gurbani"

>To: Pete Cordell

>CC: [email-masked]

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

>Date: Tue, 03 Dec 2002 15:11:37 -0600

>Pete Cordell wrote:

>>One issue that the recent B2BUA discussion has raised in my mind is

>>what a

>>B2BUA (whatever its decided that should be) should do with

>>Max-Forwards.

>>This may have been discussed before, but while RFC 3261 says a

>>B2BUA is a

>>back to back UAS / UAC, and the coupling is not specified in the

>>RFC,

>>perhaps it ought to say that the max-forwards parameter MUST be

>>propagated

>>from the incoming request to the outgoing request using the same

>>rules as a regular proxy. This would seem helpful for the

>>avoidance of loops.

>I have a feeling that specialized handling of headers for B2BUAs is

>yet

>another nightmare in the making.

>A B2BUA is a UA, period. So long as the request made it to one half

>of the B2BUA before Max-Forwards reached 0, the protocol constraints

>on that request have been satisfied. What the other half of the

>B2BUA wants to do with the Max-Forwards header is entirely up to it.

>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

Add photos to your e-mail with MSN 8. Get 2 months FREE*.
_______________________________________________
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: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 04 Dec 2002 09:21:11 -0600

> 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 

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