Date/Time:
2007.01.29 8:00PST-9:00PST
Attendees
Jason Fischl
Shida Schubert
Alan Johnston
Derek MacDonald
Fernando Lombardo
Michael Procter
Theo Zourzouvillys
Raj Jain
Venkatesh Venkataraman
Bill Mitchell
Agenda
1. Figure out the meeting frequency.
2. Requirement Bash.
3. Action Plan.
Discussions
1. Figure out the meeting frequency
> Will have a weekly call on the same time slot.
Bridge Details: +1 604-320-3344 x0330 or sip:[EMAIL PROTECTED]
2. Requirement Bash
> What's missing?
1). Interaction with privacy.
e.g. When privacy is enabled, it shouldn't be
possible to INVITE/JOIN to that dialog with
privacy enabled.
>> Some suggestions: mark the dialog as "private"/"locked"
: Use state agent to change the status
of the dialog in mid-dialog.
>> Conclusion: Definitely need some text.
2). Seizing Line/Appearance is missing.
>> Feedback: One of the most desired features, users requested.
: It was left out because it doesn't interfere with
the current proposal, it's all in the detail.
>> Conclusion: Will add text to cover this.
3). Concept of appearance number is it mandatory.
>> Feedback: UA may not always have the UI to render the appearance
number.
>> Things to consider: Consider the cases where UA doesn't have the
appropriate UI but allow it to participate in the group.
4). Concept of call-park/pickup
>> During the discussion, it was clear that concept of
call-park/pick-up
existed in BLA/MLA/SLA.
>> Suggestions from chair: Whatever overlaps need to be in sync with
call-park/pick-up draft.
5). Provisioning is it in scope?
>> Yes, text is necessary.
6). How is it done in IP-PBX?
>> For what I have seen, most are following the bla draft, and some
uses overlap dialog.
>> Action: Chair will ask IP-PBX vendors to get some feedbacks.
7). Backward compatibility
>> Agreement on not to complicate the draft simply to accomodate the
UA that doesn't support the recommended primitives. Will look into
ways to accomodate them without bending backwards.
8). Do we want to consider NAT Traversal?
>> Feedback: Would need to draw out where the NAT will be sitting.
Use of GRUU/Outbound may simplify a lot of things.
>> Conclusion: If it throws up new NAT traversal scenario then
should be addressed, otherwise should re-use what's
out there already. Even if something needs to be
addressed, it should be addressed elsewhere and not
in this draft. (e.g. SIPPING).
: As for the use of GRUU/Outbound, the team will be look
at its uses cases-by-cases. Don't want to use unstable
spec too aggressively.
9). Use Forking vs. NOTIFY only.
>> Feedback: Possibly take Forking out of the picture and only suggest
the use of NOTIFY.
>> Conclusion: Need to look at both options, they both have pros/cons.
>> Some alternatives discussed: Alert-Info with NOTIFY,
INVITE without offer(Making the
forking approach more reasonable)
3. Action Plan
BLISS draft will be updated.
> Alan will add some strawman text until next week.
> Text on privacy will be provided by Raj
> Some text is needed on the analysis of how the recommendation will
work for each of the variations (SLA, MLA, BLA etc.). Need to find
out whether there is something different fundamentally that either
peer needs to know which variant is being used or additional extension
to enable the variants.
> Need some text on this.
_______________________________________________
BLISS mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/bliss
