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

From: "Elwell, John" <[email-masked]>
Date: Sun, 18 Mar 2007 22:05:11 +0000

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

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

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

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.

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: Alan Johnston <[email-masked]>
Date: Mon, 19 Mar 2007 03:59:05 -0500

Hi John,

Thanks for your comments on the draft - see mine below.

Thanks,
Alan

Elwell, John wrote:
> 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:

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.

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

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

> NAT traversal and where key management for media security is not done until

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.

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Mon, 19 Mar 2007 05:10:58 -0500

Alan 

Section 6.2 "Call Originated by a UA in a BLA group", the first
paragraph states that "the UA just before allowing the user to place a
call,
shall send out a dialog event NOTIFY with state (trying). The User Agent
MUST wait for a 200 OK response from the State Agent, before it proceeds
with sending out the INVITE to the address entered by the end user."
This
places the State Agent in the critical path for whether or not a call
goes
through.  In a 911 scenario I don't know if we want to have a dependency
on
the responsiveness of the State Agent (which has to deal with many
SUBSCRIBEs and NOTIFYs as per this draft) before a 911 call (or some
other
type of emergency call) can go through.  

Cheers,

Martin