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

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Dec 2012 18:10:28 -0500

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:

    Within the context of this document, the terms refer to a B2BUA
    role, not a particular system type.  A given system type may change
    its role in the middle of a SIP session, for example when a Stateful
    Proxy tears-down a session by generating BYEs; or for example when
    an SBC performs transcoding or REFER termination.

The first example above is good. But I don't understand how the 
mentioned SBC demonstrates the point of this paragraph. How is this SBC 
changing role? A few more words to explain this would help.

Same section:

    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.

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.

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.

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.

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?

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.)

Section 4.4:

    ... Some transcoders
    save and remove SDP offers in INVITEs form the UAC, ...

s/form/from/

idnits reports:

    The document doesn't use any RFC 2119 keywords,
    yet seems to have RFC 2119 boilerplate text.

That's all.

	Thanks,
	Paul

On 11/27/12 10:39 AM, Victor Pascual wrote:
> Paul,
>
> would you be so kind to volunteer for this?
>
> Thanks,
> -Victor
>
> On 11/21/12 2:16 PM, "Christer Holmberg" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     [As co-chair]
>
>     Hi,
>
>     As indicated in Atlanta, we were going to initiate the *WGLC for
>     draft-ietf-straw-b2bua-taxonomy-00*.
>
>     Due to upcoming holidays (Thanksgiving etc) the WGLC will last for 3
>     weeks, until *12^th December*.
>
>     Everyone is encouraged to read the document and provide comments.
>
>     However, the chairs would also like to ask for at least a couple of
>     *volunteers*, who commit to thoughtfully reading the document.
>     Please contact the chairs if You can help with that :)
>
>     Best regards,
>
>     Victor & Christer
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Dec 2012 18:15:18 +0000

[As proxy-feature author]

Hi,

>when in fact we all know it was intending to cover B2BUAs.

Not really related to the b2bua-taxonomy draft, but Proxy-Feature does talk explicitly about both B2BUAs and proxies.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Dec 2012 21:45:46 +0000

Hi Paul,
thanks for reviewing the draft!
Comments/actions inline...

On Dec 5, 2012, at 6:10 PM, Paul Kyzivat <[email-masked]> 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:
> 
> The first example above is good. But I don't understand how the mentioned SBC demonstrates the point of this paragraph. How is this SBC changing role? A few more words to explain this would help.

OK I'll add them.

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

> 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.)
> 

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.  :)

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

> Should these be different roles?

Should what be different roles?  I'm confused by what you're referring to.

> 
> 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"?

>   save and remove SDP offers in INVITEs form the UAC, ...

Done.

>   yet seems to have RFC 2119 boilerplate text.

Right, I'm removing the 2119 boilerplate per someone else's review.

-hadriel