Subject: [BLISS] Call-Completion Design Team Minute: 08.02.01

From: Shida Schubert <[email-masked]>
Date: Wed, 06 Feb 2008 08:48:04 -0800

All;

Below is the minute from the meeting we had for
the Call-Completion design team, last week.

Date/Time:
--------------------
2007.02.01 8:00PST-9:00PST

Attendees:
--------------------
Shida Schubert
Dale Worley
Denis Alexitsev
Eric Sasaki
Enrico Marocco
Dennis Lubbers
Francois Audet
 * Please send me an e-mail, if I've missed anybody..

Agenda:
--------------------
1. Deciding on the meeting frequency until the next meeting (weekly or 
bi-weekly?)
2. Review/Comment on Dales' revised draft
3. Way forward to merge the two documents.
4. Debating the remaining issues on the mechanism(If time permits).

Discussions:
--------------------
1. Deciding on the meeting frequency until the next meeting (weekly or 
bi-weekly?)
   >> Will try to hold a meeting every week starting at 9:00 PST.
    >> Next meeting is on Feb 8th starting at 9:00 PST.

2. Review/Comment on Dales' revised draft
   a) There were some concerns/questions about the need for retaining
      the call-id.
   >> Dale explains why it's necessary.
   >> The next questions was how long this call-id needs to be retained.
     >> This depends on implementation(Depends on how big the window is
        for failed call to get in the queue).
        >> Can be up to 30 minutes.
      Conclusion: No clear conclusions >> Discuss on the Design Team ML.

   b) Suggestions to include some text that callee monitor may be part of
      callee and caller agent may be part of caller, to allow the reader
      that different scenarios was considered.

3. Way forward to merge the two documents.
   >> Chair will co-ordinate with the two authors to merge the draft.
      4. Debating the remaining issues on the mechanisms.
   >> Use of cookies, PSTN inter-working etc.
     >> See a need for cookie to be used for indicating that callee  
        supports call-completion, but unclear if it's necessary to carry
        the point of subscription(callee monitor).
             >> Issues is raised when call is forked and multiple responses
        are to be received. It's important to be able to identify the
        queue that's related to the party caller is interested in.

   >> Discussions trying to understand Caller Retension
     >> WHen both end supports then retension is invoked.
     >> It's an optional feature.

5. Action Plan.
   >> Chair will co-ordinate with the two authors and try to merge the 
text.
   >> Dennis Lubbers will post his concern about retaining the call-id
      value to the list.
   
_______________________________________________
BLISS mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/bliss