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

["Hutton, Andrew" <[e-mail]>]

Hi Hadriel,

Responses to your comments are inline below.

Regards
Andy

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[e-mail]]
> Sent: 21 December 2012 21:21
> To: Hutton, Andrew
> Cc: Christer Holmberg; [e-mail]; [e-mail];
> [e-mail]
> 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
>