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

[Hadriel Kaplan <[e-mail]>]

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

OK I'll add them.

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

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


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


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


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

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


> 
> Section 4.4:
> 
>   ... Some transcoders
>   save and remove SDP offers in INVITEs form the UAC, ...
> 
> s/form/from/

Done.

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

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

-hadriel