Subject: RE: [Sipping] B2BUA and Session Timers

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 18 Mar 2005 15:48:33 -0500

So,

First of all, sorry for the cross posting and thanks for the answers.

What I got from the answers I received is that both sides should behave
like a UA in face of unrecognized/unsupported headers.

Reading RFC3261, the following is said about unrecognized headers:

"8.2.2 Header Inspection

   If a UAS does not understand a header field in a request (that is,
   the header field is not defined in this specification or in any
   supported extension), the server MUST ignore that header field and
   continue processing the message.  A UAS SHOULD ignore any malformed
   header fields that are not necessary for processing requests."

Now, if both sides should behave like UA, it does not make much sense
from a UA behavior perspective to "bridge" a header to the UAC side that
the UAS side does not understand. I mean, does it make any sense for an
UAC to insert an unknown header in its own request?

I'm not saying it should not be done, I'm just pointing out that it does
not seem UA behavior since an UAC would not originate a request with an
unknown header or asking for an extension that it does support.

It's like "I'm putting this session-timer and other unknown headers in
this INVITE but I do not really support any of these...". 

Now, since phones (or endpoints) would most probably incorporate new
features faster than elements in the network such as B2BUAs, bridging
all unknown/unsupported headers might be the only way. Anyway, it seems
the B2BUA behavior in relation to SIP call flows and headers s should be
studied on a case by case basis.

Is there a B2BUA call flows draft in the works somewhere?

Thanks,

Reinaldo

-----Original Message-----
From: Drage, Keith (Keith) [mailto:[email-masked]] 
Sent: Friday, March 18, 2005 8:40 AM
To: Reinaldo Penno; [email-masked]'
Subject: RE: [Sipping] B2BUA and Session Timers

The only existing normative requirement on a general B2BUA is to provide
UA functionality.

Therefore it needs to provide (in both or more directions) the
appropriate UA functionality specified in session-timer. Or if it does
not support session-timer, treat the unknown headers (and any usage of
the Require and Supported headers) in accordance to the UA behaviour
specified in RFC 3261.

How it relates those two or more sides is entirely up to implementation,
and may well depend on application. For example, a conference focus made
up of SIP dialogs is formally a B2BUA, but I would not necessarily want
to bridge session-timer flows between any of the multiple dialogs.

regards

Keith

Keith Drage
Lucent Technologies
[email-masked]
tel: +44 1793 776249

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Reinaldo Penno
> Sent: 17 March 2005 19:10
> To: [email-masked]
> Subject: [Sipping] B2BUA and Session Timers
> 
> 
> Hello,
> 
> If both final endpoints of a call support session-timers but the B2BUA
> does not, what should be the B2BUA behavior? Should it pass the timer
> tag in the 200OK back to the caller? Or should it strip it 
> off since it
> does not support it?
> 
> This brings the more general question on how (de)coupled are the two
> dialogs that the B2BUA maintain. For example, the same 
> question could be
> posed regarding PRACK and other cases. 
> 
> In other words, should the two dialogs be considered two completely
> separate dialogs, so if the B2BUA itself does not support an
> extension/feature it should adjust the message accordingly, 
> or it should
> it just "bridge" the messages (of course making any mandatory 
> changes)? 
> 
> Thanks,
> 
> Reinaldo
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Arjun Roychowdhury <[email-masked]>
Date: Fri, 18 Mar 2005 21:18:58 -0500

I think you are applying the text too literally to a usage which is
essentially abstract (ie a B2B). Though it is expected that a B2B
behaves outwardly as a UAC/UAS, there is no specification that says
how a UAC/S component of a B2B gathers what its capabilities are. This
would be a policy that is dependant on what you are building.

As an example, if you are creating a B2B that acts like a message
forwarder but mangles SDP as a message passes along its logic, then,
you might feel better assuming this:

A<--->UAx:UAy<--->B

where your 'policy' dictates:
UAy (in UAC mode) will form a message that honors headers from A
(nothing wrong with this - its a UA at the end of the day, and my
policy decides what constitutes its 'capabilities')
UAx (in UAC mode) will form a message that honors headers from B
(nothing wrong with this - its a UA at the end of the day, and my
policy decides what constitutes its 'capabilities')

That should address your concern.

Do note that it still may be needed for you to process/change certain
headers such as session-timer/max-forwards etc - that depends on what
your intent is (transparent/non-transparent) - thats yet another epic
alltogether.

OTOH if you are creating a B2B that hosts an application such as
conferencing etc, then the UAs there may have more 'traditional' ideas
of what its capabilities are.

regds
arjun

-- 
Arjun Roychowdhury
Flextronics Software Systems