Subject: [BLISS] RE: Comments on draft-anil-sipping-bla-04

From: "Elwell, John" <[email-masked]>
Date: Fri, 16 Mar 2007 18:40:33 +0000

Alan,

Yes, I sent it to BLISS because I thought that was where the feature would
be discussed, but I still need to review the requirements draft. See below
for more on this draft.

John 

> -----Original Message-----
> From: Alan Johnston [mailto:[email-masked]] 
> Sent: 16 March 2007 15:57
> To: Elwell, John
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Comments on draft-anil-sipping-bla-04
> 
> John,
> 
> Thank you for your comments on the draft.   See my comments below.   
> Since this is the BLISS list, I'm hoping to have more 
> discussion about 
> the requirements in draft-johnston-bliss-mla-req-00.txt 
> rather then the 
> mechanism in this draft.
> 
> You are right that terminology is difficult, and despite a 
> major rewrite 
> of the document we didn't quite get it right.  Hopefully we will get 
> closer in the next version.
> 
> Thanks,
> Alan
> 
> 
> Elwell, John wrote:
> > If this draft is worked on I think terminology will prove a 
> difficult area.
> > For example, some people use the term "bridged lined 
> appearance" for the
> > particular situation where there is bridging (mixing) of 
> media so that users
> > on different devices can participate in the call 
> simultaneously. We should
> > avoid the term "bridging" for matters that do not involve 
> this type of
> > bridging.
> 
> We tried to only use the term bridging early in the draft in the 
> non-normative sections.  After that, we tried to switch to the 
> appearance term.
> 
> >  Also the term "appearance" is misleading, because often people use
> > the term appearance to refer to a particular registered 
> contact for an AoR,
> > i.e., a device on which that AoR appears. In the draft, 
> however, it is used
> > to identify a particular call.
> >
> >   
> 
> We are open to other terms, but I thought appearance was 
> pretty good.  
> I've never heard of appearance being used to indicated a registered 
> contact - is there a document you can point me to here?  We 
> definitely 
> want to avoid naming collisions.
[JRE] My company uses it internally and when talking to customers. When I
say a registered contact, I mean only in the context of multi-line
appearance or shared line appearance (where one device can have appearances
of multiple lines, or a line can be shared among multiple devices
respectively).

> 
> > In fact terminology throughout the document seems to be 
> inconsistent. A vast
> > number of terms are used, often meaning the same thing (I 
> think). Some of my
> > comments below identify particular terminology issues.
> >
> > In some places the term "line" is used alone without definition.
> >   
> 
> Well, there is actually no real definition for a "line" in 
> SIP - it is a 
> virtual construct.  Even though I generally dislike long terminology 
> sections, we probably should add one to this document.
[JRE] Either that or avoid duplicate terminology, if there is another
defined term meaning the same thing.

> 
> > "Calls can be joined (also called bridged or conferenced 
> together)". Is this
> > usual? If two devices A1 and A2 have appearances of the 
> same AoR A, and A1
> > makes a call to B and A2 makes a call to C, this suggests 
> that you can
> > bridge together A1, A2, B and C. 
> 
> No, this is not the behavior we meant - we'll reword to avoid 
> confusion.
> 
> > I have not heard of such a behaviour
> > (although it could be done by conventional SIP 
> conferencing). I think what
> > the authors may have in mind is that if A1 makes a call to 
> B, A2 can bridge
> > into that call. However, this is not reflected by the current text.
> >   
> 
> Yes, this is what we meant.
> 
> > Section 3.1:
> > "Executive/Assistant arrangement: The executive may appear as an
> >    appearance on the assistant SIP telephony device."
> > This does not seem to match the description of appearance 
> in section 3. If
> > an appearance is a call, how can an executive be an appearance?
> >
> > "taking over a
> >    call on a particular appearance."
> > This too does not seem to align with the description of 
> appearance in
> > section 3.
> >   
> 
> You are right - we will fix this wording problem.
> 
> > A BLA call group appears to be just the set of registered 
> contacts for a
> > given AoR - why do we need a special term? Or can there be 
> registered
> > contacts that are not members of the BLA call group, in 
> which case how are
> > such contacts identified?
> >
> > What are "APPEARANCE group", "BLA group" and "AOR
> >    group"? How do they relate to "BLA call group"? 
> >   
> 
> I don't believe there are any differences between these.
[JRE] So stick to one term.

> 
> > "Virtual BLA: Allows a AOR, not assigned as a primary 
> appearance". What is a
> > primary appearance? It is not defined and not used elsewhere.
> >
> > "The Appearance Agent can select the appearance number for 
> an incoming
> >    call."
> > What about an outgoing call?
> >   
> 
> Yes - that is described a few sentences later.
[JRE] I think the problem I had was that it gave me the impression initially
that appearance numbers were assigned only to incoming calls, but that did
seem to get contradicted later.

> 
> > "Some implementations of this feature utilize a URI 
> parameter such as
> >    "line=3" on the Contact URI."
> > How can a parameter on the contact URI identify a call? 
> Perhaps it doesn't
> > matter, because this is not the chosen method. Just rather 
> confusing.
> >   
> 
> Does the description in draft-johnston-bliss-mla-req-00.txt 
> make better 
> sense?  The intention was not to discuss the URI contact 
> method in this 
> draft but I guess this text got left in by accident.
> 
> > "the proxy could fetch this information by initiating a
> >    SUBSCRIBE request with Expires: 0 for the AOR to fetch 
> the list of
> >    lines that are in use."
> > If an appearance number identifies a call, what is the 
> relevance of the
> > number of lines in use - shouldn't it be the number of 
> calls (where each
> > line can have multiple calls potentially)? Of course, this 
> depends exactly
> > what is meant by "line".
> >   
> 
> We don't use the word line here.
[JRE] OK, but you use the word "lines".

>  This discussion is about 
> how a proxy 
> server, which does not necessarily have any knowledge of 
> which UAs are 
> in active sessions, could learn which appearance numbers are 
> in use so 
> that an unused one can be assigned.
> 
> > "When calls are placed on hold, the UAs MAY include local session
> >    description in the dialog package notification.  The 
> element should
> >    indicate that the call that is the subject of the dialog is being
> >    held (use of a=inactive or a=sendonly is RECOMMENDED [9])."
> > Do we really want to get into the parsing of SDP in order 
> to determine the
> > state of a call? We would start getting into considerations 
> like whether
> > a=inactive or a=sendonly is at the session level or media 
> level, and if
> > different media have different values, which is the 
> authoritative value. The
> > status of the media is of less relevance than whether the 
> call is in a state
> > where it can be picked up by another device, so we should 
> ensure that
> > appropriate, easy to interpret indications are given in the 
> dialog event
> > package document.
> >   
> 
> This is a mistake - the next sentence was meant to replace that one:  
> "When calls are placed on hold, the "+sip.rendering=no" [RFC 3840 
> <http://tools.ietf.org/html/rfc3840>] feature tag MUST be used."  We 
> don't want to send SDP in the dialog package notifications.
> 
> > "when it is
> >    attempting to 'seize' a line appearance"
> > This sounds like an outgoing call attempt, but previously 
> it says that
> > appearance numbers are assigned only for incoming calls. 
> However, it does
> > seem reasonable to assign an appearance number to an 
> outgoing call, to allow
> > it to be picked up, bridged into, etc.
> >
> >   
> 
> No, it says both earlier, but we'll go over to make sure any 
> confusing 
> text is fixed.
> 
> > "but this MUST be implemented to resolve glare
> >    issues."
> > I think the glare issue talked about is where there is some 
> limit to the
> > number of calls than can be in progress for a given AoR. 
> This isn't really
> > discussed much.
> >
> > "This is needed to resolve conflicts in the use of a particular
> >    appearance."
> > What is meant by "appearance" here?
> >   
> 
> If two UAs in the group both select appearance number 2 at 
> the same time 
> - only one of them may use it, the other must select 
> appearance number 3 
> instead.
> 
> > Regards,
> >
> > John
> >
> >
> >   
> 

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss