Subject: [Sipping] draft-marjou-sipping-b2bua-01

From: "Xavier Marjou" <[email-masked]>
Date: Mon, 9 Jul 2007 20:24:39 +0200

We've submitted an update of the draft on transparent B2BUA.

Until it appears in the archives, you can pick it up here:
http://www.who-elz.com/drafts/draft-marjou-sipping-b2bua-01.txt

The main differences with the previous version are:
- discussion about Replaces, Join, Target-Dialog header-fields,
- some examples of flows.

Xavier

_______________________________________________
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: "Peter Musgrave" <[email-masked]>
Date: Thu, 12 Jul 2007 12:39:57 -0600

Hi Ranjit, 

Thanks for the feedback.

Our collective (and some individual) comments are in-line.

We look forward to your additional comments...

Peter/Ian/Xavier

-----Original Message-----
From: Avasarala Ranjit-A20990 [mailto:[email-masked]] 
Sent: Tuesday, July 10, 2007 7:07 AM
To: Xavier Marjou
Cc: Ian Elz; Peter Musgrave
Subject: RE: [Sipping] draft-marjou-sipping-b2bua-01
Importance: High

Hi 

My initial comments

1.  In Sec 3, it is mentioned as B2BUA modifies the call ID. Instead it
would be better to say, its first UA terminates the incoming call and
its second UA generates a new Call-ID. 

[All: The draft is trying to discuss a 'transparent' B2BUA where the
B2BUA is doing the least amount of header manipulation possible. Words
like terminating and generating a new dialog imply the message is fully
digested and re-generated - which we would term an 'opaque' B2BUA. We do
agree that a new dialog is being created. We will try to make our intent
clearer]. 

2.  I think the RFC 3725 - BCP for 3pcc already discusses 3pcc
applications. So I don't think the last 3 points are required. It can be
mentioned as 
     However, being a B2BUA enables the transparent B2BUA to:
        *  behave as a 3rd party call controller 
[Xavier: I think that the transparency of a B2BUA that performs 3pcc
should be investigated. So for the moment I'm not convinced that RFC3725
is enough.]

3.  Sec 4.1.1 Motivation - What is b2bua doing extra to minimise impact
on SIP messages. The sentence says: "b2bua should forward all SIP
messages" - but b2bua does this anyway similar to proxy. 
     I think it can be rephrased as: "In order to minimise impact on SIP
messages exchanged between two users, the B2BUA should forward all
messages taking care to preserve the integrity of headers and body"
[All: Your suggestion is okay with us although in some case (e.g.
privacy/topology hiding) the headers will be deliberately modified.]

4.  The second paragraph is already taken care by proxy. So is b2bua
doing something extra?

5.  OPTIONS:  Since OPTIONS method is sent for requesting capabilities,
I think b2bua will not have any role to play. Unless it is behaving as a
proxy for sending the capabilities on behalf of users.
[Peter: I think that the B2BUA should either respond to the options
itself (if is 'opaque' - or pass through the OPTIONS *but* remove
references to any methods or event packages which will not go through
the B2B].
[Xavier: I think it depends who is the target of the OPTIONS: whether it
is sip:b2bua.foo.com or sip:usera.b2bua.foo.com. However I think that
only the B2BUA can know whether the OPTIONS is targeted to istelf or to
a "back" end-user]

6.  REGISTER: For register too, b2bua may not have any role as b2bua
will not be accepted any registration requests - unless it is configured
to behave as a registrar to accept registrations
[Peter: This is a topic which we have not really tackled yet. In cases
where the REGISTERs are going through, I think proxying them will make
more sense. This likely deserves its own thread and a list of use cases.
We have deferred this for the next spin of the draft].
     
More comments will follow....

Regards
Ranjit

-----Original Message-----
From: Xavier Marjou [mailto:[email-masked]] 
Sent: Monday, July 09, 2007 11:55 PM
To: [email-masked]
Cc: Ian Elz; Peter Musgrave
Subject: [Sipping] draft-marjou-sipping-b2bua-01

Xavier

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Fri, 20 Jul 2007 11:24:56 +0300

Hi,

what is the purpose of this draft? Is it to define how certain features 
can be implemented using a B2BUA? Or is it to give general guidelines on 
how to build B2BUAs that do not break too many things?

The draft lists modifying the SDP as one of the features of a 
transparent B2BUA. Doing this breaks a set of things. Is it the 
intention of the draft to condone this behavior (e.g., to treat it as a 
necessary evil)?

Cheers,

Gonzalo

---

From: "Xavier Marjou" <[email-masked]>
Date: Fri, 20 Jul 2007 13:30:20 +0200

Hi,

> how to build B2BUAs that do not break too many things?

The goal is really to give general guidelines on how to build B2BUAs
that do not break too many things in end to end SIP signalling.

> intention of the draft to condone this behavior (e.g., to treat it as a

The draft gives examples of what happens in current deployments
(Section 3). Without doing so, it may be difficult to understand the
reason why there are so many B2BUAs. However, as said before, the goal
is not to promote, nor to condone, these behaviors, but to give BCP
for B2BUAs so that not too many things are broken (Section 4).

Cheers,
Xavier