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

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 3 Jan 2013 11:16:17 +0000

Hi Hadriel,

Responses to your comments are inline below.

Regards
Andy

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: 21 December 2012 21:21
> To: Hutton, Andrew
> Cc: Christer Holmberg; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [straw] WGLC: for draft-ietf-straw-b2bua-taxonomy-00
> 
> 
> Hi Andy,
> thanks for reviewing the draft!
> Comments/actions inline...
> 
> 
> On Nov 30, 2012, at 11:56 AM, "Hutton, Andrew" <andrew.hutton@siemens-
> enterprise.com> 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?

[AndyH] - Yes.

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

[AndyH] Yes maybe I am being pedantic but for me the text does not read well could I suggest replacing the following:

"As more and more SIP domains get deployed and interconnect, the odds of a SIP session crossing such media-plane B2BUAs increases, as well as the number of such B2BUAs any given SIP session may go through. In other words, any given SIP session may cross any number of B2BUAs both in the SIP signaling plane as well as media-plane."

With

"As more and more SIP domains get deployed and interconnect the probability of a single SIP session crossing multiple B2BUA's at both the signaling and media planes increases significantly".

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

[AndyH] - Ok I agree that SDP is a special case but then we need to either explicitly mention in section 3.1.2 that SDP is not a MIME type that a Signaling-only B2BUA can modify or not say anything about modifying MIME bodies in 3.1.2 and limit it to the SIP layer as stated in the 1st sentence. I think the later would be ok.

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

[AndyH] - In that case I think we can do without the last sentence which starts with "Some are based on ....". Less text is good.

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

[AndyH] - Ok just change "form" to "from" them.

> -hadriel

---

From: Mary Barnes <[email-masked]>
Date: Thu, 3 Jan 2013 07:46:17 -0600

Responses inline below [MB].

On Fri, Dec 21, 2012 at 3:08 PM, Hadriel Kaplan <[email-masked]> wrote:
> Hi Mary,
> Thanks for the review!
> On Nov 29, 2012, at 5:19 PM, Mary Barnes <[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?

[MB] The current abstract doesn't provide the background/motivation as
to why you are even writing this document.  You are only explaining
the objective of the document.  I think you can move the first
paragraph in the intro  to the abstract - prepending it to the current
abstract and it will address my concern.  Then you can update the
first sentence in the second paragraph so there is an appropriate lead
in for the Intro simply by replacing "In practice," with "In current
SIP deployments," [/MB]
"
>
>
> - 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?
[MB] I think specific references are more useful since the 3gpp
website is not that easy to navigate unless you are fairly familiar
with how they do their specs.  I've spent way more time than one would
think necessary pointing folks to specific 3gpp documents. [/MB]
>
> - 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
>
>