Subject: RE: [BLISS] Fwd: I-D ACTION:draft-johnston-bliss-mla-req-00.txt

From: "Elwell, John" <[email-masked]>
Date: Mon, 19 Mar 2007 13:43:24 +0000

Alan,

Thanks for your responses. See below.

John 

> -----Original Message-----
> From: Alan Johnston [mailto:[email-masked]] 
> Sent: 19 March 2007 08:59
> To: Elwell, John
> Cc: [email-masked]; Mohsen Soroush-nejad; Venkatesh 
> Venkataramanan; Anil Kumar
> Subject: Re: [BLISS] Fwd: I-D 
> ACTION:draft-johnston-bliss-mla-req-00.txt
> 
> Hi John,
> 
> Thanks for your comments on the draft - see mine below.
> 
> Thanks,
> Alan
> 
> Elwell, John wrote:
> > Alan,
> >
> > Some of the terminology concerns I already made on 
> draft=anil-sipping-bla
> > apply also to this document, so I won't repeat them. 
> 
> Hopefully this draft suffers a little less, but we will fix 
> this as well.
> 
> > Other comments:
> >
> > REQ-4: "UAs registering against the group AOR should be able
> >    to learn about each other and join the appearance group."
> > Why do UAs need to learn about each other? Isn't it just 
> necessary for a UA
> > to know that the AoR is a group AoR and therefore is shared 
> by other UAs?
> > Although specific solutions might require the UA to know 
> about specific
> > other UAs, I don't think this is a basic requirement. I 
> don't think the
> > solutions discussed in the draft require this.
> >   
> 
> I guess you are correct.  If a UA registers against the AOR and never 
> makes or receives a call, the other UAs don't care about it.  
> However, 
> if it makes or receives a call, it needs to be known to the 
> other UAs so 
> that SIP call control operations can be performed.  If you agree with 
> this, perhaps we can reword the requirement to reflect this.
[JRE] OK, if it makes or receives a call then the other UAs need sufficient
information to pick-up or join that call, but whether this requires the
other UAs to have this UA's identity depends on the particular solution.
Some rewording would help.

> 
> > "REQ-5 The mechanism must scale for large numbers of appearances, n,
> >    and large numbers of UAs, N, without introducing 
> excessive messaging
> >    traffic."
> > One consequence of a large N is, depending on solution, the 
> establishment of
> > N early dialogs towards the UAC and N parallel ICE 
> procedures, N parallel
> > key management procedures, etc.. This might not be 
> important for values of N
> > of the order of 3-5, but with much larger values of N this 
> could certainly
> > be a problem. I assume this requirement is intended to 
> cover this and to
> > include messages in general (such as STUN and whatever in-band key
> > management is used) as well as SIP messaging.
> >   
> 
> This is a very interesting idea.  I agree that this 
> requirement should 
> include traffic such as ICE messaging and RTP keying.  I'm 
> not sure we 
> have good options for optimizing, though.
> 
> > "The use of a State Agent for the Dialog Package meets REQ-5."
> > Well, I don't think it does, for reasons in my previous comment.
> >
> >   
> 
> Yes, a state agent does not help with N ICE and media path 
> keying traffic. 
> 
> > The comparison of options and the conclusions that are reached seem
> > reasonable to me. My only concern is the scalability to 
> large values of N in
> > environments where NAT traversal and media security are 
> managed on an
> > end-to-end basis, although it would work in environments 
> where SBCs handle
> > NAT traversal and where key management for media security 
> is not done until
> > one of the UAs answers.
> >   
> 
> Well, we have discussed an alternative model in which instead of the 
> INVITE being forked to all N endpoints, the endpoints first 
> get a NOTIFY 
> from the Appearance Agent.  If a UA wants to answer the call, 
> it sends 
> some kind of indication to the Appearance Agent which then causes the 
> INVITE to get sent to the endpoint.  Now, this is a major 
> change to the 
> way UAs answer calls, but it might help reduce ICE and media 
> path keying 
> messaging.
[JRE] The point is, I think we need both. For low values of N, the present
mechanism seems OK, but for larger values of N, I think there might need to
two classes of UA - those who really must receive a forked INVITE request
and those that can make do with a NOTIFY request- perhaps users less likely
to answer calls from that AoR who would be content with the longer
post-answer delays (and associated media clipping) associated with the
pick-up type operation (e.g., based on INVITE/Replaces) that would need to
occur.

> 
> 
> > John
> >
> >
> >
> >
> >
> >  
> >
> >   
> >> -----Original Message-----
> >> From: Alan Johnston [mailto:[email-masked]] 
> >> Sent: 27 February 2007 21:13
> >> To: [email-masked]
> >> Cc: Mohsen Soroush-nejad; Venkatesh Venkataramanan; Anil Kumar
> >> Subject: [BLISS] Fwd: I-D 
> ACTION:draft-johnston-bliss-mla-req-00.txt
> >>
> >> All,
> >>
> >> The authors of draft-anil-sipping-bla (which will be revised 
> >> as -04 next 
> >> week) have put together this draft discussing requirements and 
> >> implementation options for set of features known as Bridged Line 
> >> Appearance (BLA), Multiple Line Appearance (MLA), Single Line 
> >> Extension, 
> >> etc.
> >>
> >> Comments are most welcome.
> >>
> >> Thanks,
> >> Alan
> >>
> >> -------- Original Message --------
> >> Subject: 	I-D ACTION:draft-johnston-bliss-mla-req-00.txt
> >> Date: 	Tue, 27 Feb 2007 15:50:03 -0500
> >> From: 	[email-masked]
> >> Reply-To: 	[email-masked]
> >> To: 	[email-masked]
> >>
> >>
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts 
> >> directories.
> >>
> >>
> >> 	Title		: Requirements and Implementation Options for
> >>                           the Multiple Line Appearance 
> Feature using 
> >>                           the Session Initiation Protocol (SIP)
> >> 	Author(s)	: A. Johnston, et al.
> >> 	Filename	: draft-johnston-bliss-mla-req-00.txt
> >> 	Pages		: 16
> >> 	Date		: 2007-2-27
> >> 	
> >>    This document describes the requirements for implementation of a
> >>    group telephony feature commonly known as Bridged Line 
> Appearance
> >>    (BLA) or Multiple Line Appearance, or Shared Call/Line 
> Appearance
> >>    (SCA).  When implemented using the Session Initiation 
> >> Protocol (SIP),
> >>    it is referred to as Multiple Appearances.  This feature 
> >> is commonly
> >>    offered in the IP Centrex services and IP-PBX offerings 
> >> and is likely
> >>    to be implemented on SIP IP telephones and SIP feature 
> servers used
> >>    in a business environment.  This document lists requirements and
> >>    compares implementation options for this feature.
> >>
> >>
> >>
> >> A URL for this Internet-Draft is:
> >> http://www.ietf.org/internet-drafts/draft-johnston-bliss-mla-r
> >>     
> > eq-00.txt
> >   
> >> To remove yourself from the I-D Announcement list, send a 
> message to 
> >> [email-masked] with the word unsubscribe in 
> >> the body of 
> >> the message. 
> >> You can also visit 
> >> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> >> to change your subscription settings.
> >>
> >> Internet-Drafts are also available by anonymous FTP. Login 
> with the 
> >> username "anonymous" and a password of your e-mail address. After 
> >> logging in, type "cd internet-drafts" and then 
> >> "get draft-johnston-bliss-mla-req-00.txt".
> >>
> >> A list of Internet-Drafts directories can be found in
> >> http://www.ietf.org/shadow.html 
> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >> Internet-Drafts can also be obtained by e-mail.
> >>
> >> Send a message to:
> >> 	[email-masked].
> >> In the body type:
> >> 	"FILE /internet-drafts/draft-johnston-bliss-mla-req-00.txt".
> >> 	
> >> NOTE:	The mail server at ietf.org can return the document in
> >> 	MIME-encoded form by using the "mpack" utility.  To use this
> >> 	feature, insert the command "ENCODING mime" before the "FILE"
> >> 	command.  To decode the response(s), you will need "munpack" or
> >> 	a MIME-compliant mail reader.  Different MIME-compliant 
> >> mail readers
> >> 	exhibit different behavior, especially when dealing with
> >> 	"multipart" MIME messages (i.e. documents which have been split
> >> 	up into multiple messages), so check your local documentation on
> >> 	how to manipulate these messages.
> >>
> >> Below is the data which will enable a MIME compliant mail reader
> >> implementation to automatically retrieve the ASCII version of the
> >> Internet-Draft.
> >>
> >>
> >>
> >> _______________________________________________
> >> BLISS mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/bliss
> >>
> >>     
> >
> >
> >   
> 

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

---

From: Venkatesh <[email-masked]>
Date: Mon, 19 Mar 2007 07:45:11 -0700

John:

IMHO, we should try to avoid multiple ways for supporting the feature. This
is a sure recipe for interoperability issues which BLISS is trying to
address in the first place. Believe using NOTIFY's instead of forked
INVITE's seem to solve your problem with ICE. I am not sure I understand
your concern about media cut thru's with this solution. Just for the record,
the alternative solution we had discussed is as below:

The State Agent is the only entity that REGISTER's on behalf of the BLA AoR.
All other UA's simply SUBSCRIBE to the State-Agent. On receipt of an
incoming call, the State-Agent is the only entity that receives the INVITE
request. It sends out a NOTIFY to all the UA's in the BLA group. Any UA that
intends to 'answer' this call uses INVITE with Replaces header using the
dialog identifiers in the NOTIFY request.

Thanks,
Venkatesh