Re: [sipcore] #29: B2BUAs passing H-I through?

I think I know what he's talking about.  Since a B2BUA is a UAC and UAS, one might think it should follow the rules for a UAC and UAS in this draft, restarting/clearing the H-I on each side.  Section 4.1 has one line which mentions B2BUA's may act "proxy-like" for this header, but in that paragraph it says a UAC MUST add a H-I with an index of 1 if it adds one at all, so a B2BUA would actually do *that* - presumably not what one would want of a B2BUA.

What you really want is a sentence/para saying a B2BUA would follow the rules for a Proxy with regards to H-I for requests which it forwards, unless local policy says otherwise; while for requests it generates itself it should act as a UAC.  For example if it generates a dialog-creating INVITE due to receiving a REFER, it would act as a UAC per the 4424bis draft, but if it is merely forwarding a dialog-creating INVITE (i.e. generating one due to receiving one) then it should follow the rules for a Proxy and copy the received H-I and add an entry, etc.  Right?

-hadriel

On Aug 31, 2010, at 3:42 PM, Mary Barnes wrote:

> I'm not sure what you mean about "explicitly authorizing" - we don't
> have anything normative for B2BUAs defined, so I don't see how we can
> do anything authoritative in this document. What are the known
> problems you would like highlighted?
> 
> On Tue, Aug 31, 2010 at 12:51 PM, sipcore issue tracker
> <trac@tools.ietf.org> wrote:
>> #29: B2BUAs passing H-I through?
>> ---------------------------------+------------------------------------------
>>  Reporter:  worley@…             |       Owner:
>>     Type:  enhancement          |      Status:  new
>>  Priority:  major                |   Milestone:  milestone1
>> Component:  rfc4244bis           |     Version:
>>  Severity:  In WG Last Call      |    Keywords:
>> ---------------------------------+------------------------------------------
>>  In sections 4.1 and 4.2.1 there is text suggesting that B2BUAs that are
>>  functioning as "quasi-proxies" may want to copy the incoming H-I into the
>>  outgoing request (as if they were a proxy).  This seems like a good idea
>>  to me, but it would be wise to have a short section explicitly authorizing
>>  this behavior and perhaps listing any known problems with this.
>> 
>> --
>> Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/29>
>> sipcore <http://tools.ietf.org/sipcore/>
>> 
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore