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

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

Hi Mary,
Thanks for the review!
Comments/actions inline...

On Nov 29, 2012, at 5:19 PM, Mary Barnes <[email-masked]<mailto:[email-masked]>> wrote:

General comments:
---------------------------
- A fair number of references need to be added - I've identified many below.
- The document discusses Application Servers and PBXs throughout section 3, but those terms aren't described until section 4, so I think at least a forward reference should be added (although, that kindof makes it circular, so maybe adding a generic definition something like the following to the terminology section might be useful) and/or the terminology added to section 1.

OK.

Minor comments:
-----------------------
- Abstract - really could use a bit more intro.  I would suggest to borrow some text from the introduction - maybe the first paragraph.

You're the second person to suggest this, but I don't see it - or rather I don't see how to do so in a useful way without repeating the intro section, and really this is supposed to be an abstract not an intro - just enough information for someone to decide whether to read the doc or not, right?  Does it not fulfill that goal?  If not, what exact wording should be added?

- Section 1 - Terminology:
-- Remove the reference to RFC 2119.  I don't think it's necessary.

Done.

-- Also, I don't think B2BUA, UAS and UAC need to be defined here.  They should just be expanded on the first usage.   I would just refer to the definitions in RFC 3261 as you have for RFC 2828.
-- Per my comment above

- Section 3, 2nd paragraph, last sentence.  What is a "one-armed 3rd party call control transcoder"?  There is a reference to section 3.1 of RFC 5369, but that doesn't use the "one-armed" terminology.  I don't think referring to "one-armed" adds value.  I suggest simply removing it.

Done.

- Section 3.2.2: Add references for SRTP Terminator and RTCP for QoS
done
- Section 3.2.3:  Add a reference for MSRP
done
- Section 4.6:  Expand P-CSCF and IBCF. Add references to 3GPP architecture and media plane gateway specs.
- Section 4.7:  Expand S-CSCF.

Can I get away with just a reference to 3gpp's website of specs?

- Section 5:  I would suggest to reword something like "The security considerations related to the functionality described in this document are addressed in the relevant references."

done.

Nits:
------
- Section 4.2:
-- expand VCC & IVR
-- last sentence: "Poxy-B2BUA" -> "Proxy-B2BUA"
- Section 4.4.: Expand TDM.

Done.

-hadriel

---

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

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

On Nov 30, 2012, at 11:56 AM, "Hutton, Andrew" <[email-masked]> wrote:

> 1. Abstract. Could do with a bit more detail on what a SIP B2BUA actually is and the roles it performs the statement "... performing different roles in different ways" is I think a bit too vague.  Maybe you could mention some examples includes SBC's and Application Servers.

I can add that example -  would that be sufficient for the abstract?

> 
> 2. Section 2, 3rd para. ", the odds of a SIP session the odds of a SIP session crossing such media-plane B2BUAs increases". I am not sure of the relevance of "media-plane B2BUAs" in this context. In fact I think it would not harm to lose this paragraph altogether.

The point of it was to explain to folks why they should care.  A lot of people think of their own B2BUA being deployed in isolation, rather than the SIP call continuing to hit other B2BUAs along its way to wherever it's going.
OK to keep it?

> 3. Section 3.1 states "This implies it does not modify SDP bodies, although it may save them and/or operate on other MIME body types". This is incorrect and in fact the subsection 3.1.3 describes such a B2BUA which does modify SDP. I suggest the following text "A Signaling-plane B2BUA is one that operates only on the SIP message protocol layer, and only with SIP messages, bodies, and headers but not the media itself in any way".  The sentence about other MIME body types can then be removed.
> 
> 4. Section 3.1.2 and 3.1.3. I am not sure why it is necessary to separate the "SDP-Modifying Signaling Only" B2BUA from the "Signaling Only B2BUA". The signaling only B2BUA section states that such a B2B UA may "modify or inspect specific MIME bodies," why does it not just include SDP as one of the MIME types a signaling-only B2BUA may modify?

Because for RAI mechanisms which use this taxonomy doc, it may make a big difference - i.e., if you define something that operates in SDP it will not matter to "normal" signaling B2BUAs, but may have an impact for SDP-aware ones.  For example the BUNDLE stuff, or much of MMUSIC's work.
If you're a vendor that builds a B2BUA that is agnostic to SDP, you don't have to worry about BUNDLE et al.  If you build a signaling B2BUA that inspects/modifies SDP, you do... even if your B2BUA doesn't actually handle media itself.

> 
> 5. Section 4.1 "SIP PBXs and Softswitches". I don't understand the reference to the UAC & UAS being "connected with a logical PRI loopback;". I don't think this is really a valid analogy. If it is meant to mean there may be signaling transcoding between the SIP UAS and UAC then that it is what it should say. 

It's just meant to explain that the term 'PBX' is a marketing term, and that in practice some PBXes are full B2BUAs at all layers, while some are not. (In a previous life I worked on a PBX that was a UAC/UAS with a logical TDM layer connecting the call-halves)

> 
> 6. Section 4.2. "Poxy-B2BUA" -> "Proxy-B2BUA" I assume

Yup.

> 
> 7. Section 4.4 The last sentence states:
> 
> "Some transcoders save and remove SDP offers in INVITEs form the UAC, and wait for an offer in the response from the UAS, similar to a 3PCC model; others just insert additional codecs in SDP offers and only transcode if the inserted codec(s) are selected in the answer."
> 
> I think this goes in to too much detail about how a transcoder might work is not necessary and anyway the 3PCC bit sounds like rather dubious practice which we don't need to say anything about.

This whole section (section 4) is about what SIP device types in the market match up to what B2BUA roles in this doc.  It does not prescribe any behavior as being better or worse, but is more like a helper for normal (non-IETF) people reading this doc.  I have sen transcoders operate in the 3pcc manner, and others not.  So the point of calling it out here was to say "it depends, and there is no one-size-fits-all mapping in call cases".

-hadriel