Subject: [Sipping] comments on draft-marjou-sipping-b2bua-01.txt

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 25 Jul 2007 23:24:59 -0400

Howdy,
Just read the draft and I have some comments (in no particular order):

1) I don't know of any hard requirement that a b2bua actually change the
call-id.  Frequently it's done by topology-hiding b2bua's in order to hide
ip addresses which are often found in call-id's, but to be as "transparent"
a b2bua as possible I think you should point out that call-id changing is
not necessary except for that one topology-hiding case, and should be
avoided otherwise. (likewise changing the tags)

2) Section 4.6.1: SIP and TLS.  Although it is obviously possible for a call
to be sips on one side of the b2bua and sip on the other, for a BCP of
transparent b2bua's I think you should strongly recommend that by default it
not be done - that a sips request stays sips and a sip request stays sip.  I
believe there was consensus to document that somewhere from the San Diego
IETF meeting as well.

3) Section 4.1.3 says: "When the UAS of the B2BUA receives a SIP request
from an upstream proxy or UA, it must check whether it supports the
extensions required that the UAC advertises in the Allow, Required,
Supported, and any other additional headers."  This is a bit confusing since
the next sentence says in practice many extensions can be accepted
transparently.  I think you need stronger guidance around what header the
b2bua must actually understand *everything* for, vs. which it may not.  For
example I think a transparent b2bua ought to know everything in a
Proxy-Require header, as if it were a proxy; whereas it may not need to know
everything in a Require header, depending on how transparent a b2bua it
truly is.

4) Section 4.1.2 says: "If a SIP 200 OK of INVITE with an SDP offer is sent
by Bob, it is necessary that the B2BUA forward the SIP 200 to Alice before
generating the ACK request towards Bob. Otherwise, Bob's UA will never
receive the SDP answer."  I am confused by this.  If you're a b2bua
forwarding messages, and the SDP offer is in the 200ok, why would you
generate an ACK on your own?  The only case I know of for this is 3pcc, in
which case you'd have the SDP to be sent back in the ACK, so that statement
doesn't apply.  I don't even know why you'd need to put this in the doc -
it's like saying "you should make calls work".  I think what you need to say
is "don't expect the invite to have the SDP offer", because many devices
make that assumption, and in the real world it's not always true.  But
that's really more of a general SIP-implementers problem not just b2bua's.

5) Section 4.5: Sending a BYE.  In general I don't know why this section is
in the doc - there is no recommendation to be made with being a transparent
b2bua in this regard.  It is what it is.

6) Section 5.1: you ask if the o= line is changed.  Answer: yes, AFAIK most
b2bua's that need to get media do that. 

7) Appendix A, table-1: I assume this table (and in fact the whole document)
is trying to convey what a b2bua should do to be as transparent as possible
by default - recognizing that much of this is totally override-able by local
configuration (as it is for some "proxies" too in the real world).  So under
those assumptions, I think:
a) call-id should NOT be changed
b) from and to tags should not be changed
c) max-forwards should be decremented, not reset

8) There are a large class of B2BUA's that do not do topology hiding, and a
class that do.  Which are you addressing in this doc?  I ask because by
definition one type can be much more transparent than the other, and the doc
seems to mix the actions both.

-hadriel

_______________________________________________
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: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 25 Jul 2007 20:51:42 -0700

> avoided otherwise. (likewise changing the tags)

Section 8.1.1 of RFC 3261 clearly states that it is forbidden to have
two UAs generating the same Call-ID.

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 26 Jul 2007 00:58:42 -0400

Yup, but 3261 didn't really envision the use of "transparent b2bua's".  And
since the goal of this draft is to recommend them to be as "transparent" as
possible, to maximize interoperability with future extensions, I recommend
it not mandate they modify the dialog identifiers. (since it avoids the
issues they describe in section 4.2 of the draft)

But it's not a biggie to me either way.

-hadriel

> -----Original Message-----
> From: Marc Petit-Huguenin [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2007 11:52 PM
> To: Hadriel Kaplan
> Cc: 'Xavier Marjou'; 'Ian Elz'; 'Peter Musgrave'; [email-masked]
> Subject: Re: [Sipping] comments on draft-marjou-sipping-b2bua-01.txt
> 
> Hadriel Kaplan wrote:
> > Howdy,

---

From: "Xavier Marjou" <[email-masked]>
Date: Thu, 26 Jul 2007 09:35:43 -0500

Hi,

Thank you for your comments.
Please find my answer in-line.

Xavier

> avoided otherwise. (likewise changing the tags)

I understand your point. However, it may not always be technically
feasible (eg: due to some SIP API limitations). In addition, RFC3261
mandates each UAC to ensure that its call-id,tag-from,tag-to be
unique. I also think it then becomes difficult for the newbye to make
the difference between a regular proxy and a transparent B2BUA.
However, I would also like to have more feedback to see if more people
share your point of view.

> believe there was consensus to document that somewhere from the San Diego

I agree

> everything in a Require header, depending on how transparent a b2bua it

Yes, I agree the text can be enhanced. However, we did not find better
wording. The problem is with future extensions: how to know whether
the B2BUA needs to understand it or not?

> that's really more of a general SIP-implementers problem not just b2bua's.

It may be obvious, but I've seen implementations where this case fails.

> b2bua in this regard.  It is what it is.

I think it depends on the scope of the draft. If included in the
draft, then we should discuss it (as the BYE may be challenged), if
not it can be removed.

> b2bua's that need to get media do that.

I tend to agree, as I've also seen many implementations doing that.
Here again, I would be happy to have other opinions on this topic.

> c) max-forwards should be decremented, not reset

a) and b) are related to the first question.
For c), I agree there's some interest to decrement it.

> seems to mix the actions both.

I hope we can cope with both cases with sentences like: "the B2BUA
should .... however if the B2BUA wants to retain privacy, it may ...".
There was also a comment from Paul who suggested to align with the
draft sip-munakata-sip-privacy-guideline. I don't know how we'll do
that in details, but we need to handle that too.

---

From: [email-masked]
Date: Thu, 26 Jul 2007 16:49:31 -0400

From: Marc Petit-Huguenin <[email-masked]>

But as another thread discussed, if the B2BUA (or better,
"quasi-proxy") wants/needs to pass through 401/407 authentication
challenges, it needs to use the same Call-Id and tags on both sides.

Since proxies pass on requests without changing the Call-Id and tags,
it's clearly possible to make an agent use this behavior without
breaking interoperability.

Dale

---

From: [email-masked]
Date: Thu, 26 Jul 2007 18:17:36 -0400

From: [email-masked]

The "other thread" is on the sip-implementors mailing list.  This URL
will give you a list of many of the messages:

http://search.gmane.org/?query=B2BUA+Problem+when+processing+401%2F407&group=gmane.ietf.sip-implementors

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 27 Jul 2007 00:03:43 +0100

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 26 July 2007 04:25
> To: 'Xavier Marjou'; 'Ian Elz'; 'Peter Musgrave'
> Cc: [email-masked]
> Subject: [Sipping] comments on draft-marjou-sipping-b2bua-01.txt
> 
> Howdy,
[JRE] Some B2BUAs perform 3PCC actions, such as call transfer by 3PCC.
As a result, one end of one call with particular call-ID, to-tag and
from-tag values could be connected to one end of a second call with
different call-ID, to-tag and from-tag values. Thus any subsequent
request on the resulting call (e.g., re-INVITE, UPDATE, BYE) will
require mapping of these values at the B2BUA. Of course, this can be
avoided by doing call control by some other means (e.g., with REFER),
but the fact remains that some B2BUAs do it in the way I have just
described.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2007 20:03:26 -0400

There are B2BUA haters, and maybe B2BUA lovers. I'm in the middle. To 
paraphrase:

    B2BUAs don't hurt SIP; improper uses of B2BUAs hurt SIP.

There are plenty of perfectly reasonable uses B2BUAs. For instance:
- conference foci
- message exploders
- RLS servers
- click-to-dial 3pcc controllers

I think a distinguishing characteristic of these is that they don't try 
to hide. They are first class participants. Even so, they can cause 
trouble if they aren't careful.

I think it is a useful service to write down those things that a B2BUA 
needs to do to avoid causing trouble. I don't think it is helpful to 
discuss "transparent" B2BUAs, since if they are transparent they don't 
need to be there and don't add any value.

(Even glass is only partially transparent - to certain frequencies of 
light. Its often a feature that it isn't transparent to ultraviolet, or 
to cold air or bugs.)

In the current conversation, being transparent to the Call-ID can work 
and makes sense in some contexts, but not in all contexts.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 27 Jul 2007 01:16:45 +0100

Exactly, it doesn't make sense in all circumstances.

John 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 27 July 2007 01:03
> To: Elwell, John
> Cc: Hadriel Kaplan; Xavier Marjou; Ian Elz; Peter Musgrave; 
> [email-masked]

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 27 Jul 2007 11:04:27 +0800

> but the fact remains that some B2BUAs do it in the way I have just
Parallel ua-forking of call that results to a conference is also one use 
case where call-id transparency is not feasible.

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 27 Jul 2007 02:31:56 -0400

> From: Elwell, John [mailto:[email-masked]]
> 

I'm not totally clear on what you mean by that - I mean I *think* I know the
type of device you mean but I don't think of them as b2bua's per se.  But
your point is taken.  Clearly if you're doing something that by definition
has to have new call-ids/tags, then you would have such.  

Maybe the draft should be re-worded to just point out that if call-id/tag
changing is not necessary, don't do it.  I.e., be as proxy-ish as possible,
with emphasis on "possible". (yeah, I know, 'Here be dragons')

-hadriel

---

From: "Ganesan Sam-W00184" <[email-masked]>
Date: Fri, 27 Jul 2007 04:11:30 -0400

A proxyish b2bua .... There is a turn up for the books.. 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, July 27, 2007 2:32 AM
To: 'Elwell, John'; 'Xavier Marjou'; 'Ian Elz'; 'Peter Musgrave'
Cc: [email-masked]
Subject: RE: [Sipping] comments on draft-marjou-sipping-b2bua-01.txt

> > 1) I don't know of any hard requirement that a b2bua actually change

> > the call-id.  Frequently it's done by topology-hiding b2bua's in 
> > order to hide ip addresses which are often found in call-id's, but 
> > to be as "transparent"
> > a b2bua as possible I think you should point out that call-id 
> > changing is not necessary except for that one topology-hiding case, 
> > and should be avoided otherwise. (likewise changing the tags)

I'm not totally clear on what you mean by that - I mean I *think* I know
the type of device you mean but I don't think of them as b2bua's per se.
But your point is taken.  Clearly if you're doing something that by
definition has to have new call-ids/tags, then you would have such.  

Maybe the draft should be re-worded to just point out that if
call-id/tag changing is not necessary, don't do it.  I.e., be as
proxy-ish as possible, with emphasis on "possible". (yeah, I know, 'Here
be dragons')

-hadriel

_______________________________________________
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