Howdy.

I have been selected as the Applications Area Review Team reviewer for 
this draft (for background on apps-review, please see 
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.


Title:  A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back
         User Agents
I-D:    draft-ietf-straw-b2bua-taxonomy-02

By:     D. Crocker <dcrocker@bbiw.net>
Date:   7 July 2013



NOTE:  Because this has just been moved up for tomorrow's IESG
        telechat, I'm copying the IESG directly.  Unfortunately there is
        no time for issues to first be discussed and resolved with the
        authors prior to that.  /d



Summary:

SIP exchanges can transit complex arrangements of functional components. 
Some of these perform classic "gatewaying" functions, by terminating 
portions of the session and initiating new ones.  That is, they are 
specialized relays operating with detailed application knowledge and 
potentially imposing extensive modifications to the control or payload 
data.  In the SIP context, these components are called back-to-back user 
agents (B2BUAS). Given the complexity of the SIP architecture, B2BUAS 
cover a wide range of possible functions.  The current draft provides 
some structure to that range and offers terminology to label the structure.

The document has utility in its current form.  However, a diligent 
editing pass could make portions of it more easily understood and, 
overall, make the document more accessible to readers less expert in SIP 
architecture and deployment intricacies.


For example, the abstract should be tweaked to make it more readable for 
non-experts.  The current text assumes very large amount of SIP 
background, such as by using an acronym soup.  Better to use fewer 
acronyms in abstract, unless they have extensive familiarity to /casual/ 
readers.

To the extent that this document can only reasonably be read by first 
having familiarity with specific RFCs, the requirements need to be 
stated early in the Introduction.  Equally, the terminology section 
should cite the documents from which it is importing terms.  And every 
acronym should be expanded the first time it is used and/or have a 
citation to its technical details.




Detailed Comments:


> Abstract
>
>    In many SIP deployments, SIP entities exist in the SIP signaling path
>    between the originating UAC and final terminating UAS, which go

define acronyms at first occurrence, but better not to use them in an 
abstract, unless highly familiar to non-experts


>    beyond the definition of a Proxy, performing functions not defined in
>    standards-track RFCs.  The only term for such devices provided in
>    [RFC3261] is for a Back-to-Back User Agent (B2BUA), which is defined
>    as the logical concatenation of a User Agent Server (UAS) and User
>    Agent Client (UAC).

In the spirit of multi-cultural exchange, it might be worth comparing 
B2BUA to its email equivalent, which is 'mediator'. (RFC 5598).

{As a sanity check: I think this draft's purpose compares with section 5 
of RFC 5598? /d }


>    There are numerous types of SIP Back-to-Back User Agents (B2BUAs),
>    performing different roles in different ways.  For Example IP-PBXs,
>    SBCs and Application Servers.  This document identifies several

Cite SBC definition.


>    common B2BUA roles, in order to provide taxonomy other documents can
>    use and reference.
>



> 1.  Terminology
>
>    B2BUA: a SIP Back-to-Back User Agent, which is the logical
>    combination of a User Agent Server (UAS) and User Agent Client (UAC).
>
>    UAS: a SIP User Agent Server.
>
>    UAC: a SIP User Agent Client.

provide citations to definitions of these.

I'm used to having the Introduction be the first section, with something 
like Terminology following.  And, yes, that means the Introduction can't 
assume familiarity with the terms.


> 2.  Introduction
>
>
>
> Kaplan & Pascual       Expires November 11, 2013                [Page 2]
> 
> Internet-Draft             Taxonomy of B2BUAs                   May 2013
>
>
>    In current SIP deployments, there are numerous forms of B2BUAs,
>    operating at various layers of the protocol stack, and for various

Normal models cast UAs at the top of the technical stack.  So I've no 
idea what it means to have B2BUAs "operating at various layers of the 
protocol stack".  The following sentence's don't clarify this issue.


>    purposes, and with widely varying behavior from a SIP protocol
>    perspective.  Some act as pure SIP Proxies and only change to the
>    role of B2BUA in order to generate BYEs to terminate dead sessions.

This really calls for some text that explicitly clarifies the difference 
between a SIP proxy and a B2BUA, especially given that a number of B2BUA 
'roles' look quite a bit like classic proxy behavior.


>    Some are full User Agent stacks with only high-level event and
>    application logic binding the UAS and UAC sides.  Some B2BUAs operate
>    only in the SIP signaling plane, while others participate in the
>    media plane as well.

It would be quite helpful to have a diagram (or pointer to one) that 
places all of these in relationship to each other.


>    As more and more SIP domains get deployed and interconnect the

delete: "and more"

interconnect -> interconnected


>    probability of a single SIP session crossing multiple B2BUA's at both
>    the signaling and media planes increases significantly.

Note that this means than SIP isn't end-to-end.  B2BUAs are 'gateways' 
in that they terminate one connections/session and start another.


>    This document provides a taxonomy of several common B2BUA roles, so
>    that other documents may refer to them using their given names
>    without re-defining them in each document.
>
> 3.  B2BUA Role Types
>
>    Within the context of this document, the terms refer to a B2BUA role,

"the terms"?  what terms?  The reference lacks context.


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

I hadn't heard the term transcoding before; I like it. Since it's in 
wikipedia, I'll assume it's well-established and doesn't need defining 
here? Or should RFC 5369 be cited here?


>    Furthermore, this document defines 'B2BUA' following the definition
>    provided in [RFC3261], which is the logical concatenation of a UAS
>    and UAC.  A typical centralized conference server, for example, is
>    not a B2BUA because it is the target UAS of multiple UACs, whereby
>    the UACs individually and independently initiate separate SIP
>    sessions to the central conference server.  Likewise, a 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.

What is an "inline" transcoding?  The term does not appear in RFC5370.


> 3.1.  Signaling-plane B2BUA Roles
>
>    A Signaling-plane B2BUA is one that operates only on the SIP message
>    protocol layer, and only with SIP messages and headers but not the
>    media itself in any way.  This implies it does not modify SDP bodies,

implies -> implies that


>    although it may save them and/or operate on other MIME body types.
>    This category is further subdivided into specific roles as described
>    in this section.
>
> 3.1.1.  Proxy-B2BUA
>
>
>
>
>
> Kaplan & Pascual       Expires November 11, 2013                [Page 3]
> 
> Internet-Draft             Taxonomy of B2BUAs                   May 2013
>
>
>    A Proxy-B2BUA is one that appears, from a SIP protocol perspective,
>    to be a SIP Proxy based on [RFC3261] and its extensions, except that
>    it maintains sufficient dialog state to generate in-dialog SIP
>    messages on its own and does so in specific cases.  The most common
>    example of this is a SIP Proxy which can generate BYE requests to
>    tear-down a dead session.
>
>    A Proxy-B2BUA does not modify the received header fields such as the
>    To, From, or Contact, and only modifies the Via and Record-Route
>    header fields following the rules in [RFC3261] and its extensions.
>    If a Proxy-B2BUA can generate in-dialog messages, then it will also
>    need to modify the CSeq header, after it's generated its own.  A

it's -> it has


>    Proxy-B2BUA neither modifies nor inspects MIME bodies (including
>    SDP), does not have any awareness of media, will forward any Method
>    type, etc.
>
> 3.1.2.  Signaling-only
>
>    A Signaling-only B2BUA is one that operates at the SIP layer but in
>    ways beyond those of [RFC3261] Proxies, even for normally forwarded

It isn't immediately obvious what 'beyond' means here and I can't tell 
whether the following sentences are meant to define it, since they 
merely provide the same kind of might/might-not detail done in the 
previous sub-section.  The detail is necessary, of course, but it 
doesn't explain the conceptual point being made by saying "beyond".


>    requests.  Such a B2BUA may or may not replace the Contact URI,

since rfc 2119 isn't cited, i assume that there is no normative language 
in this doc?

in any event, i think the language is cleaner if 'may or may not' is 
replace by 'might'.


>    modify or remove all Via and Record-Route headers, modify the To and
>    From header fields, modify or inspect specific MIME bodies, etc.  No

Small stylistic suggestion, especially for anything that is a 
specification:  When a list of (possible) actions is provided, it helps 
to format it as a list.


>    SIP header field is guaranteed to be copied from the received request
>    on the UAS side to the generated request on the UAC side.

This last sentence is pretty scary.  It seems to affirm a complete lack 
of assurance of end-to-end functionality.


>    An example of such a B2BUA would be some forms of Application Servers

forms -> form  {to match "an example")

Servers -> Server


>    and PBXs, such as a server which locally processes REFER requests and
>    generates new INVITEs on behalf of the REFER's target.  Another
>    example would be an [RFC3323] Privacy Service Proxy performing the
>    'header' privacy function.
>
> 3.1.3.  SDP-Modifying Signaling-only
>
>    An SDP-Modifying Signaling-only B2BUA is one that operates in the
>    signaling plane only and is not in the media path, but does modify
>    SDP bodies and is thus aware of and understands SDP syntax and
>    semantics.  Some Application Servers and PBXs act in this role in
>    some cases, for example to remove certain codec choices or merge two
>    media endpoints into one SDP offer.

it's worth expanding sdp at least once in the doc.

Also, these sub-section descriptions provide the mechanical details, but 
without any attempt to distinguish the meaning of the differences from 
one type to another.  What's the /purpose/ of one role vs. another?  As 
I scan the subsections, it appears that they are meant to describe 
agents that go progressively deeper into the architectural components. 
If the different roles are related in such a way, it's worth noting that 
at the beginning of the section.


> 3.2.  Media-plane B2BUA Roles
>
>    A Media-plane B2BUA is one that operates at both the SIP and media
>    planes, not only on SIP messages but also SDP and potentially RTP/
>    RTCP or other media.  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.  No SIP header field is guaranteed to be
>

rtp/rtcp citation.


> Kaplan & Pascual       Expires November 11, 2013                [Page 4]
> 
> Internet-Draft             Taxonomy of B2BUAs                   May 2013
>
>
>    copied from the received request on the UAS side to the generated
>    request on the UAC side, and SDP will also be modified.
>
>    An example of such a B2BUA would be a Session Border Controller

Session Border Controller -> Session Border Controller (SBC)


>    performing the functions defined in [RFC5853], a B2BUA transcoder as
>    defined in [RFC5370], a rich-ringtone Application Server, or a
>    recording system.  Another example would be an [RFC3323] Privacy
>    Service Proxy performing the 'session' privacy function.
>
>    Note that a Media-plane B2BUA need not be instantiated in a single
>    physical system, but may be decomposed into separate signaling and
>    media functions.

This seems to be highlight an essential network architecture point, 
namely that there is a basic difference between components of the 
architecture versus their instantiation/implementation is h/w&s/w. 
Folks often miss this distinction, so it might be worth highlighting 
much earlier in the doc.


>    The Media-plane B2BUA category is further subdivided into specific
>    roles as described in this section.
>
> 3.2.1.  Media-relay
>
>    A B2BUA which performs a media-relay role is one that terminates the
>    media plane at the IP and UDP/TCP layers on its UAS and UAC sides,

udp/tcp but not rtp?

don't you mean 'originates' on its UAC side?


>    but neither modifies nor restricts which forms of UDP or TCP payload
>    are carried within the UDP or TCP packets.  Such a role may only

Might be worth inserting a sentence that explicitly says something like 
"Rather, the payload is transparently copied from the UAS side to the 
UAC side."


>    support UDP or only TCP or both, as well as other transport types or
>    not.  Such a role may involve policing the IP packets to fit within a
>    bandwidth limit, or converting from IPv4 to IPV6 or vice-versa.  This
>    is typically similar to a NAT behavior, except a NAT operating in
>    both directions on both the source and destination information; it is
>    often found as the default behavior in SBCs.
>
> 3.2.2.  Media-aware
>
>    A B2BUA which performs a media-aware role is similar to a media-
>    relay except that it inspects and potentially modifies the payload
>    carried in UDP or TCP, such as [RFC3550] RTP or RTCP, but not at a

text after first comma doesn't parse.  perhaps a connector word, before 
RTP is missing?


>    codec or higher layer.  An example of such a role is an [RFC3711]
>    SRTP terminator, which does not need to care about the RTP payload
>    but does care about the RTP header; or a device which monitors RTCP
>    for QoS information; or a device which muxes/de-muxes RTP and RTCP
>    packets on the same 5-tuple.
>
> 3.2.3.  Media-termination
>
>    A B2BUA which performs a media-termination role is one that operates
>    at the media payload layer, such as RTP/RTCP codec or MSRP message
>    layer and higher.  Such a role may only terminate/generate specific
>    RTP media, such as [RFC4733] DTMF packets, or it may convert between
>    media codecs, or act as a Back-To-Back [RFC4975] MSRP agent.  This is
>    the role performed by transcoders, conference servers, etc.
>
>
>
> Kaplan & Pascual       Expires November 11, 2013                [Page 5]
> 
> Internet-Draft             Taxonomy of B2BUAs                   May 2013
>
>
> 4.  Mapping SIP Device Types to B2BUA Roles
>
>    Although the B2BUA role types defined previously do not define a
>    system type, as discussed in section 3, some discussion of what

'a' system type?  or perhaps 'system types'?

role types -> roles

{I suspect the word 'type' can be dropped for role references in this 
document, since roles are already an abstraction.}


>    common system types perform which defined roles may be appropriate.
>    This section provides such a 'mapping' for general cases, to aid in
>    understanding of the roles.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net