Subject: [dispatch] B2BUA charter/straw

From: "Khan, Sohel" <[email-masked]>
Date: Tue, 27 Mar 2012 11:59:49 +0000

Currently, a proxy can be statefull or stateless. The advantage of stateless is to have the proxy out of the path of a SIP call after initial session messages.  As I understand, currently deployed B2BUAs are " rigidly statefull". They remain in the call path until the end of the session and all the messages traverse through B2BUA.   Can we convert the B2BUA to be a pseudo-statefull--i.e., for certain SIP messages, the B2BUA is statefull for some messages and for other messages of the same call, the B2BUA is stateless? 
Can we add this in the current B2BUA charter initiative?

Sohel

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 27 Mar 2012 12:19:21 +0000

Sohel,

Could you please explain the advantage of those new B2BUA over stateful proxy.

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Khan, Sohel
>Sent: Tuesday, March 27, 2012 5:30 PM
>To: [email-masked]
>Subject: [dispatch] B2BUA charter/straw
>
>Currently, a proxy can be statefull or stateless. The advantage of
>stateless is to have the proxy out of the path of a SIP call after
>initial session messages.  As I understand, currently deployed B2BUAs
>are " rigidly statefull". They remain in the call path until the end of
>the session and all the messages traverse through B2BUA.   Can we
>convert the B2BUA to be a pseudo-statefull--i.e., for certain SIP
>messages, the B2BUA is statefull for some messages and for other
>messages of the same call, the B2BUA is stateless?
>_______________________________________________
>dispatch mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Khan, Sohel" <[email-masked]>
Date: Tue, 27 Mar 2012 12:26:00 +0000

Thanks Partha.
We want to take the advantage of topology hiding of the B2BUA; however, we want to save the B2BUA's implementation package (i.e., SBC) from excessive chatting to improve processing. In addition, for the persistent connection for incoming messages, we would like to pass the incoming new session messages bypassing the B2BUA.

________________________________________
From: Ravindran, Parthasarathi [[email-masked]]
Sent: Tuesday, March 27, 2012 6:19 AM
To: Khan, Sohel; [email-masked]
Subject: RE: B2BUA charter/straw

Sohel,

Thanks
Partha

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 27 Mar 2012 12:53:01 +0000

Sohel,

Topology hiding is not possible for the mid-dialog without dialog-stateful B2BUA. I'm not clear how stateless B2BUA entity helps here..

Also, Please explain in the separate mail thread about persistent connection usecase as discussed in Dispatch meeting today.

Thanks
Partha

>From: Khan, Sohel [mailto:[email-masked]]
>Sent: Tuesday, March 27, 2012 5:56 PM
>To: Ravindran, Parthasarathi; [email-masked]
>We want to take the advantage of topology hiding of the B2BUA; however,
>we want to save the B2BUA's implementation package (i.e., SBC) from
>excessive chatting to improve processing. In addition, for the
>persistent connection for incoming messages, we would like to pass the
>incoming new session messages bypassing the B2BUA.
>
>

---

From: "Khan, Sohel" <[email-masked]>
Date: Tue, 27 Mar 2012 13:03:55 +0000

Thanks Partha. 
In technological innovation, nothing is impossible. 
We will need to innovate something (e.g., a B2BUA)  with following requirements:
1. Topology hiding
2. pseudo-stateful.

For example, only SIP messages with offer-answer information and BYE passes the B2BUA. All other messages bypass B2BUA.

Sent: Tuesday, March 27, 2012 6:53 AM

Sohel,

Thanks
Partha

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 27 Mar 2012 13:34:48 +0000

Sohel,

Thanks for the clarification. You propose to introduce new SIP entity which is in between B2BUA and stateful proxy for Topology hiding and pseudo-stateful. IMO, your new entity is not B2BUA and pls define new entity for more discussion.

Thanks
Partha

>Sent: Tuesday, March 27, 2012 6:34 PM
>For example, only SIP messages with offer-answer information and BYE
>passes the B2BUA. All other messages bypass B2BUA.
>
>
>Topology hiding is not possible for the mid-dialog without dialog-
>stateful B2BUA. I'm not clear how stateless B2BUA entity helps here..
>
>Also, Please explain in the separate mail thread about persistent
>connection usecase as discussed in Dispatch meeting today.
>
>Thanks
>Partha
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Mar 2012 15:34:28 +0200

> In technological innovation, nothing is impossible.

Unfortunately too many people believe that.

> For example, only SIP messages with offer-answer information and BYE passes the B2BUA. All other messages bypass B2BUA.

IMO that makes no sense.
To receive any of the in dialog messages the B2BUA must be in the 
signaling path. That same signaling path is used for *all* the in-dialog 
messages, so they all go there.

OTOH, you are free to decompose the implementation of your B2BUA, into 
internal components that communicate with one another without regard to 
sip signaling. Then, if you like you can put your o/a handling into a 
*component* of the b2bua that is only invoked for messages containing 
offers and answers.

But that is an *implementation* issue, not an issue for IETF.

	Paul

---

From: "Khan, Sohel" <[email-masked]>
Date: Tue, 27 Mar 2012 13:46:29 +0000

Thank you Partha. Actually, proposing a new entity and creating new charter process will take a long time.
I am simply trying to see whether we can include it as a task in the new B2BUA charter.
The task may provide recommendation which messages must pass through B2BUA and which messages must not.

Subscribe/Notify is an example. Can we recommend Subscribe message passing through B2BUA but Notify bypasses B2BUA. You may say it is an implementation method not a responsibility of the IETF. The issue is that multiple providers/implementations creates interoperability issues. Thus, an IETF guideline/recommendation will be very helpful.

Sent: Tuesday, March 27, 2012 7:34 AM

Sohel,

Thanks
Partha

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Mar 2012 16:03:46 +0200

> Subscribe/Notify is an example. Can we recommend Subscribe message passing through B2BUA but Notify bypasses B2BUA. You may say it is an implementation method not a responsibility of the IETF. The…

If the SUBSCRIBE establishes a new dialog, then your "B2BUA" may elect 
to act as a proxy and not Record-Route. It will than not be in the 
signaling path for the dialog.

But in that case you will not be able to do topology hiding.

There are other possibilities with different tradeoffs.
None of this requires any changes to existing standards.

	Paul

---

From: "Khan, Sohel" <[email-masked]>
Date: Tue, 27 Mar 2012 14:06:02 +0000

Thank you Paul.
The "very bad" B2BUA is sitting in the border of two providers using different implementations. For a provider's internal implementation, your recommendation is valid. In  additino, it will be helpful for IETF to provide a guideline/recommendation to providers/vendors with options to anchor some messages in the B2BUA while providing options not to anchor some other messages in the B2BUA. SIP Subsribe/notify is such an example.

Sohel

________________________________________
From: [email-masked] [[email-masked]] on behalf of Paul Kyzivat [[email-masked]]
Sent: Tuesday, March 27, 2012 7:34 AM
To: [email-masked]
Subject: Re: [dispatch] B2BUA charter/straw

IMO that makes no sense.

        Paul

---

From: "Khan, Sohel" <[email-masked]>
Date: Tue, 27 Mar 2012 14:11:26 +0000

Thank you Paul.
How about  "innovative" B2BUAs.
The Border B2BUA provides its "outbound" address to the Internal B2BUA acting as a "Internal Switch".
The Internal B2BUA sends "Outbound" address instead of "internal address" in the notify message.
In a such a case the outside provider sees both the B2BUAs as one virtual B2BUA.
Does it make any sense?

Sohel
________________________________________
From: [email-masked] [[email-masked]] on behalf of Paul Kyzivat [[email-masked]]
Sent: Tuesday, March 27, 2012 8:03 AM
To: [email-masked]
Subject: Re: [dispatch] B2BUA charter/straw

        Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 27 Mar 2012 10:10:49 -0400

> From: Khan, Sohel [[email-masked]]
> 
> initial session messages.

Actually, proxies can be:

- transaction stateless (and thus necessarily dialog stateless)
- transaction stateful but dialog stateless
- dialog stateful (and thus necessarily transaction stateful)

Dialog-stateful proxies need to Record-Route themselves into all
dialogs.  (Unless for a particular dialog, the proxy decides that it
does not need to retain the dialog's state.)

The first two types can Record-Route themselves (and thus remain in
the path of the call) for various reasons.  One reason is to control
the path that future requests take.  Another possibility is that the
proxy puts some sort of state or long-term information in the
Record-Route URI that will be useful in the handling of later
requests.

> As I understand, currently deployed B2BUAs are " rigidly
> statefull". They remain in the call path until the end of the
> session and all the messages traverse through B2BUA.

And this is often considered to be a goal in itself, as well as a
means to other goals.

> Can we convert the B2BUA to be a pseudo-statefull--i.e., for certain
> SIP messages, the B2BUA is statefull for some messages and for other
> messages of the same call, the B2BUA is stateless?  Can we add this
> in the current B2BUA charter initiative?

It depends on what you mean by "statefull"...  Given that a B2BUA (by
definition) is addressed by the Contact URIs that it generates for the
dialogs on each side, it unavoidably remains in the signaling path.
Given the need to rewrite the requests as they pass through and the
desire for the B2BUA to hide topology, it would be very hard to
implement a B2BUA without having it retain dialog state (to feed into
the rewriting process), although a clever Ph.D. thesis might figure
out how to do so.

I would back up and ask for a more detailed explanation of the sort of
behavior you are interested in, and what the benefits would be.

Dale

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 27 Mar 2012 18:02:31 +0200

Essentially you are attempting to label something that is undefined. Hadriels usage of the term B2BUA is still referencing something that implements the UA state machine on each side.

Given that the idea of the new group is to define behaviour on top of such an entity you must understand its underlying behaviour.

That means either you must define that underlying behaviour to include it (and then see Dale's reponse which I entirely agree with) or that we cannot do it.

Regards

Keith

> Sent: 27 March 2012 15:11
> To: Paul Kyzivat; [email-masked]
> > Subscribe/Notify is an example. Can we recommend Subscribe message
> passing through B2BUA but Notify bypasses B2BUA. You may say it is an
> implementation method not a responsibility of the IETF. The issue is that
> multiple providers/implementations creates interoperability issues. Thus,
> an IETF guideline/recommendation will be very helpful.
> 
> > Thanks for the clarification. You propose to introduce new SIP entity
> which is in between B2BUA and stateful proxy for Topology hiding and
> pseudo-stateful. IMO, your new entity is not B2BUA and pls define new
> entity for more discussion.
> >
> > Thanks
> > Partha
> >
> >>> Could you please explain the advantage of those new B2BUA over
> stateful
> >>> proxy.
> >>>
> >>> Thanks
> >>> Partha
> >>>