Re: [Sip] B2BUA & Max-Forwards

[aroychow@hss.hns.com]

I've been following two threads on the B'to'BUA definition and looks like 
both are pretty similar. So Here are my 2c:

* First, hope I am not offending someone by using BtoBUA instead of B2BUA. 
Beleive it or not, this '2' also is another source
of confusion for many people who seem to think '2' means the number two 
and implies '1 UA and 1 UAS' and therefore should
be really called BnBUA :-)

* How a  BtoBUA functions depends on what application is being implemented 
by it. Therefore, it does not make sense
to me trying to dictate or suggest how the BtoB associates one or more UAS 
instances with one or more UAC instances.

Therefore, a BtoB can only be defined as how its seen from the 'outside' 
-> i.e. as Vijay points out, 

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

* How the BtoB 'associates' one or more UAS instances with one or more UAC 
instances is dependent on an algorithm
which MAY associate using defined SIP protocol semantics or some other 
application level semantic which cannot be standardized.

* 'transparent' , 'semi-transparent', 'evil' <and other such terms> 
BtoBUAs reflect different algorithms that a BtoB
applies to a message after a inbound SIP message is received and before an 
associated SIP message is sent out.

* Therefore, trying to define what a BtoBUA should do with a message 
without defining what is the application that is using this
model seems like it will simply add to the confusion instead of trying to 
solve it.

In summary, as suggested by some  others, the only way to 'describe' what 
a BtoB may do, makes sense only if we define
call-flows with specific applications in mind. Trying to generalize an 
application-specific entity is going to confuse implementors
much more. 

In addition, these call flows should describe how one can achieve certain 
end services (specific)  instead of trying to project the message 
that this is how a BtoB should really work (generic). 

Atleast now implementors know they can do what they want with the B2B 
internally as long as external interfaces are standard.
While this may seem like sacrilege, it makes a lot of sense to keep it 
this way . Opinions on what should or should not be done
really depends on a particular scenario and deployment case (as proven 
time and again by 3G CSCFs as well as FCPs, media proxies et al).


regds
arjun




--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301-212-7860        (M): 240-997-0066




"Vijay K. Gurbani" <vkg@lucent.com>
Sent by: sip-admin@ietf.org
12/03/2002 04:11 PM

 
        To:     Pete Cordell <pete@tech-know-ware.com>
        cc:     sip@ietf.org
        Subject:        Re: [Sip] B2BUA & Max-Forwards


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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip



_______________________________________________
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