I have attached the minutes from Call-Park/Pickup design
team meeting we had last Thursday.
Date/Time:
--------------------
2008.02.14 8:00PST-9:00PST
Attendees:
--------------------
Dale Worley
Derek Mcdonald
Francois Audet
Michael Proctor
Sanjay Sinha
Shida Schubert
* Please send me an e-mail in person, if I missed anybody..
Agenda:
--------------------
1. Resolving the Contention
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. Francois has some concern with 01a:
1. use of URN.
> Means Proxy needs to understand.
> Backward-Compatibility issue
2. P2P stuff
> Don't see we need to do anything here.
> It's outside of the scope of this draft.
> The idea was to enable park without the park server.
> To provide stable naming scheme.
> There is a difference between P2PSIP and UA having
the capabilities.
Conclusion: 00 version was better than 01a, we should make
the 00 version a basis for the update.
> Francois made some suggestion in re-formating the document.
> It's possible to just park on the UA, and treat the URI as
an opaque string as one always do.
> Opaque parameter is lost during translation.
> With Park server, it's usually provisioned up front, so
there is no problem with resolution/translation.
> How can a UA find out when other UA is providing the park?
> First write it as URI, and that it's routable.
*Kind of like how cc-conference is written.
> Need to solve the loose-route issue, and we shouldn't work
around it. Have the loose-route resolve the problem.
> Highlight the fact that this is another use-case for the
loose-route.
>> Suggestion: Call-flow is based on service example, service
example doesn't address how UA gets a dialog info, where call
is parked and this draft is where it should be addressed.
> Configuration Issue:
>> There is nothing that needs to be done.
>> It's done either manually or through auto-configuration.
>> Anybody in favor of URN?
>> Not really.
>> Need to define the format of the orbit?
>> Until loose-route is solved, use of server may be necessary.
>> Just needs to be worded properly.
> Should send the use-case to Jonathan.
>> Francois will send the use-cases to Jonathan.
> Flag it as an open-issue.
> Note: without it it's difficult to park it on the UA.
> It reads like you have to do the music thing.
> Should ease the text so music/media is not mandate.
> Michael will mention the music-on-hold aspect in the use-case.
> Francois suggests that the draft adds a section explaining how
it could work without the server.
> What happens if REPLACEs is not supported, what to be done?
>> Do we want to add text?
>> Probably should wait, may complicate the draft too much.
> Use of 302 was suggested to refer the target(Alice) to the
call-park server.
>> Debate over use of 302 vs REFER.
>> Will add some text on why it's better to send the REFER to
call-server.
2. Action Plan. ******************************
1. Text modification (Assuming Michale does this)
A. Configuration Issue: Just describe how UA needs to be configured
with the URI.
B. Remove the text surrounding URN.
C. Modify the text so it doesn't allude that the draft tries to
address P2PSIP scenario.
D. Adds section explaining how it works with park-server implemented
on UA.
> Highlight the open issue: Loose-Route.
E. Add some text on why it's better to send the REFER to call-server.
G. Error Code for REFER > May be add an open-issue
2. Francois will send the use-case for loose-route(call-park/pickup)
to Jonathan.
3. Next Meeting. ******************************
2008 Feb 21st, 8:00PST-9:00PST
_______________________________________________
BLISS mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/bliss
