Re: [straw] WGLC: for draft-ietf-straw-b2bua-taxonomy-00

[Paul Kyzivat <[e-mail]>]

Sorry for the belated reply. I set it aside for the holidays and forgot 
to get back to it. Comments inline.

On 12/21/12 4:45 PM, Hadriel Kaplan wrote:
> Hi Paul,
> thanks for reviewing the draft!
> Comments/actions inline...
>
> On Dec 5, 2012, at 6:10 PM, Paul Kyzivat <[e-mail]> wrote:
>
>> I've only been looking at changes in this for awhile. Now that we are at WGLC I actually carefully read through it again. I have more comments than I thought I would.
>>
>> Section 3:

[snip]

>>
>>    Likewise, a one-armed
>>    third-party call control transcoder as described in section 3.1 of
>>    [RFC5369] is not a B2BUA; whereas an inline transcoder based on
>>    [RFC5370] is a B2BUA.
>>
>> IMO this is very subjective. There clearly *is* a distinction between the two cases, but that doesn't necessarily mean they aren't both B2BUAs. It would be very helpful to have both types of transcoders included so that it is possible to contrast the differences between the two.
>>
>> I think the problem here is that we don't have clear criteria for what to include and what to exclude. In this case I think the key distinction is whether or not the transcoder is on the signaling path between the caller and the UA that represents the callee. (Interestingly, that is also true of a conference focus, and for a UA that splits a multimedia call, sending the different media to different devices.) So maybe that is the criterion that matters. If so, it would be helpful to explicitly state this and ensure that the decisions are all made based on this.
>
> Right, exactly - it goes back to the debate we've had in the WG about whether a server acting as a UAS for multiple sessions (ie, is the target of them) is a "B2BUA" in the sense that we want to cover it with this doc, or not.
>
> I don't believe there's been resolution on that, has there?

No, I don't think there has. We have use cases that are topologically 
very similar that some seem to want to classify differently.

E.g. the 3rd party transcoder looks remarkably like a click-to-talk 3pcc 
controller.

IMO this indicates that we haven't yet found the key distinctions.

>> Section 3.1.1:
>>
>> As I brought up at the Atlanta meeting, a Proxy-B2BUA that generates in-dialog messages will need to "make room" in the progression of CSeq values for the messages it generates. This means, once it generates a message, that CSeq values will differ on the two "sides". The b2bua then must modify CSeq values to perform the mapping.
>>
>> (A Proxy-B2BUA that only generates a BYE message probably segments the session at that time, no longer forwarding messages, and so won't need to update CSeq values. But it will still need to know what CSeq value it can use for the BYE, so it will need to keep state.)
>>
>> This is a fairly significant issue, and IMO should be mentioned explicitly.
>
> Right, Brett Tate had brought this up as well, when the draft used to describe that a Proxy-B2BUA might send UPDATEs for session refresh/liveness.  So I deleted the sentence that said so, in order to avoid having to explain what all such a Proxy-B2BUA might need to do.
> But I'll put it in, as you've pointed out it's unavoidable.  :)

OK. Thanks.

>> Section 3.1.2:
>>
>> I have always considered that there is a major distinction between those b2buas that replace the Contact with one of their own, and those that leave the Contact and use Record-Route to stay in the call.
>>
>> For example, one that replaces the contact can potentially use callee-caps to represent its capabilities/features, while the other kind must use Proxy-Feature to identify itself. The Proxy-Feature draft danced all around this, pretending it was only talking about proxies when in fact we all know it was intending to cover B2BUAs. If it had been able to reference this draft then having that distinction available could have been important.
>
> What textual changes do you want made to the draft for the above?

I don't know. Does anyone else think this distinction is of any 
significance?

ISTM that if you *don't* replace the contact then you are really wish to 
be a proxy, but can't live with the limitations of proxies.

If you *do* replace the contact, then you are standing up and saying "I 
admit that I am a UA and claim all the capabilities and responsibilities 
that implies".

>> Section 3.2:
>>
>>    Such a B2BUA may or may not replace the
>>    Contact URI, modify or remove all Via and Record-Route headers,
>>    modify the To and From header fields, etc.
>>
>> I think you are saying that any of the Media-plane roles is compatible with any of the Signaling-plane roles. I wish you would say it explicitly.
>>
>> This would then mean that we could describe every B2BUA by naming both its signaling role and its media role.
>
> That as not my intention - I think any media-plane B2BUA has to modify the SDP, so the intention was that media-plane B2BUAs are a superset-of/go-beyond the SDP-modifying signaling level.

I need to think about this more.
It doesn't appear to me to fit a hierarchy very well.
It seems more two-dimensional, though not all combinations may apply.

>> Section 3.2.1:
>>
>>    Such a role may only
>>    support UDP or only TCP or both, as well as other transport types or
>>    not.
>>
>> Should these be different roles?
>
> Should what be different roles?  I'm confused by what you're referring to.

My point is that a Media-plane B2BUA may be classified into one of the 
sub-roles (relay, aware, termination, or bypass) independently for each 
media type.

You don't mention bypass here. If it uses bypass for all media types, 
then it is a Signaling-plane B2BUA.

So these sub-types are useful, but you can't always classify a server 
into just one of them.

>> What does it mean to *not* support some transport type? Does it mean that it is a signaling-only B2BUA wrt that media? Or that it blocks that media?
>> (ISTM blocking the media is a signaling-only function - a variant on the SDP-Modifying Signaling-only role.)
>
> In practice I've only ever seen such devices block TCP media (or even just fail calls with TCP-based media).  But I guess one could do a hybrid.  Does it matter though?  I mean if there's some new TCP-based media mechanism coming out of MMUSIC, that needs to say something about B2BUAs, can't they just say "Media-relay B2BUAs as defined in [RFCXXXX] need to support TCP and do X for our new mechanism to work"?

We shouldn't be using TCP as an example here, because there are 
*already* TCP-based mechanisms in SDP. So lets use something newer, like 
SCTP - e.g. in draft-ietf-mmusic-sctp-sdp-nn.

I'm suggesting that the description needs to be more like:

"A media-plane B2BUA (as defined in [RFCXXXX]) MUST apply one of 
media-plane roles (relay, aware, termination, or bypass) to this protocol."

We would want every draft that defines a new <proto> to include similar 
language.

	Thanks,
	Paul