Subject: [Sipping] B2BUA and Session Timers

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 17 Mar 2005 14:10:16 -0500

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

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 18 Mar 2005 13:39:54 -0000

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

---

From: "Sreedhar Pampati" <[email-masked]>
Date: Fri, 18 Mar 2005 18:46:36 -0800

I want to add more to this discussion:

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

I see some use in trying to synchronize the session timers in the B2B
case. However this would require both the Refresh-Interval and Refresher
are negotiated synchronously. 

Easier scenario would be:
'A' proposes to be the refresher with 60(or some other) second refresh
interval.
'UAy' will carry out A's proposal, by presenting itself as the refresher
with 60 second interval to B.
 'B' will accept both the refresher and refresh-interval.
 'UAx' will agree to whatever A proposed.

Many other possible scenarios:
1. Both A and B want to be the refreshers.
2. A and UAx want to be the refreshers.
3. UAx and UAy want to be the refreshers.
4. ...

The flexibility of configurations on the B2B and the support (or the
lack) of session timers on A, B will lead to more and more use cases.

Cheers,
Sreedhar Pampati
net.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Arjun Roychowdhury
Sent: Friday, March 18, 2005 6:19 PM
To: Reinaldo Penno
Cc: [email-masked]; [email-masked]
Subject: Re: [Sip-implementors] RE: [Sipping] B2BUA and Session Timers

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

On Fri, 18 Mar 2005 15:48:33 -0500, Reinaldo Penno <[email-masked]>
wrote:
> 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?
> 
-- 
Arjun Roychowdhury
Flextronics Software Systems

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 21 Mar 2005 16:25:40 -0000

Exactly.

You cannot build a fully "transparent" B2BUA without understanding all extensions from the past and those to be made in the future.

It is the fundamental problem of trying to implement intermediate entities as B2BUAs rather than proxies.

The only B2BUA drafts that exist are those for specialist applications, e.g. transcoders and conference focus.

regards

Keith Drage

> Sent: 18 March 2005 20:49
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping] B2BUA and Session Timers
> 
> 
> So,
> 
> What I got from the answers I received is that both sides 
> should behave
> 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
> 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
> 
> 
> 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
> 
>

---

From: "Roy, Radhika" <[email-masked]>
Date: Mon, 21 Mar 2005 13:41:02 -0500

In addition, B2BUA is used other purposes as well:
 
"Adaptation capabilities between the UAs."
  
One may then develop the detail state machine of the B2BUA for proving transparent services mitigating the differences between the two SIP UAs. 
 
For example, one UA may be a simple basic SIP UA without supporting all the advance features while the other UA supports all the advance features. In this situation, a B2BUA will provide transparency, as if, both UAs are communicating at ease without any difficulties.
 
B2BUA is again implementation specific.
 
Best regards,
Radhika R. Roy
SAIC

________________________________

From: [email-masked] on behalf of Drage, Keith (Keith)
Sent: Mon 3/21/2005 11:25 AM
To: [email-masked]'
Subject: RE: [Sipping] B2BUA and Session Timers

Exactly.

regards

Keith Drage

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 21 Mar 2005 21:51:22 -0000

My point in the final sentence was that the only internet-drafts or RFCs (aside from various author drafts that have come, and duly gone) concerning B2BUA and their operation is for specialist applications, i.e. where the loss of the transparency at the intermediate point is by design rather than as a side effect of something the session requester has not requested.
 
And my point still stands that it is impossible to build a B2BUA that handles all future extensions without knowing about what they do. Therefore any B2BUA will always introduce a compatibility issue.
 
I know there are all sorts of other things out there on the market place. Some of them may be RFC 3261 conformant. 
 
And I still like Dean's original 10 rules of transparency - look back about 3 years in the archive. As soon as you start hitting the transparency, you have to consider whether the end justifies the means.
 
regards
 
Keith

-----Original Message-----
From: Roy, Radhika [mailto:[email-masked]]
Sent: 21 March 2005 18:41
To: Drage, Keith (Keith); [email-masked]
Subject: RE: [Sipping] B2BUA and Session Timers

  

 
Best regards,
Radhika R. Roy
SAIC

  _____  

Exactly.

regards

Keith Drage

> From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ]On
> Behalf Of Reinaldo Penno

---

From: "Roy, Radhika" <[email-masked]>
Date: Mon, 21 Mar 2005 17:37:08 -0500

Agreed.
 
As I mentioned, B2BUA (curse) is implementation-specific (almost impossible to have a common standard).
 
Radhika

From: Drage, Keith (Keith) [mailto:[email-masked]]
Sent: Mon 3/21/2005 4:51 PM
To: Roy, Radhika; [email-masked]
Subject: RE: [Sipping] B2BUA and Session Timers

 

regards
 
Keith

	-----Original Message-----
	From: Roy, Radhika [mailto:[email-masked]]
	Sent: 21 March 2005 18:41
	To: Drage, Keith (Keith); [email-masked]
	Subject: RE: [Sipping] B2BUA and Session Timers

	  

	 
	Best regards,
	Radhika R. Roy
	SAIC

	Exactly.

	
	
	regards
	
	Keith Drage