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 protected]
http://www.ietf.org/mailman/listinfo/bliss
