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

[Hadriel Kaplan <[e-mail]>]

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


On Nov 30, 2012, at 11:56 AM, "Hutton, Andrew" <[e-mail]> 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