Reported by AC Mahendran
Agenda/Logistics: (9:00am)
· Rohan gave introduction. Encouraged everyone to buy shirts.
· Note well.
· Passed the Blue Sheets (white in color).
· Indicated that Network Connectivity will be available in the afternoon.
I. Multiparty Apps framework and Conferencing Requirements: (Dan Petrie/Orit L)
A) CC Framework draft (Presentation by Dan)
Dan:
Issues in framework draft:
· Too large and need context of primitive operations?
· Idea proposed to split the conferencing parts
1. Requirements
2. Primitives
3. Service examples
Brian: Draft is good. Needs to be sliced. URI needs to be pulled out. Conferencing/URI needs slicing.
Rodney: We need to see how it inter-works in relation with SIP call package.
Collin Jennings: REFER/Re-INVITE can be used to implement a lot of these. Refer preferable.
Dan:
· There was a lunch BOF for conferencing at Minneapolis.
· Requirements design team formed at BOF
· Produced Requirements document for conferencing
· Model is important for terminology and hence produced.
Highlights:
· Need to split the draft.
· We need to discuss about this more on the mailing lists.
B) Conferencing Requirements presentation (Orit, Levin)
(Orit)Outline of draft:
· Hierarchal Applications (signaling model)
· SIP Start Conference App
· SIP Star Real Time Multimedia conferencing
(Orit)Reasons for hierarchal model:
· Means to describe reality
· A basis for terminology Definition
· A means to understand each others requirement
· Means to describe and classify requirements
(Orit)Hierarchal App Model
Eg: Meta application can have two types for eg: SIP Voice conferencing & White Board (T.120 based). SIP Voice conferencing can have Media control and Voice/Data plane
Rohan: Technology terms don’t look familiar unlike other drafts. Why not use standard terms like conference?
Orit: Could not find definition for SIP conference anywhere. What is it?
Jonathan: This doesn’t look like Requirements spec.
Joerg Ott: I don’t agree with the model.
SIP Star Conferencing App (Orit)
Main Requirements:
· Tight conference control
· Pre arrange and spontaneous conference
· Center participant will be able add and disconnect SIP based participants
Rohan: is it one per media type or one per conference?
Orit: not talking about media type
Dan: We are talking about SIP center and not about media
SIP Star RT Multimedia Conference App (Orit)
· SIP Star Conf app with one or more RT media planes
· RT Media plane established by SDP means
· Should contain media control sub apps
· May have data planes that are not RT media planes
Dan: Presentation space is similar to conference space (trying not to be voice specific)
Jorge: In this case, is the center participant is a UA?
Orit: Yes
Rohan: In CC framework a media mixer is not a contributor.
Orit: This model doesn’t preclude a media mixer to be a contributor.
Allison: Is end system mixer a part of model?
Orit: Yes
Henning: Important part is control aspect. Here, media process idea doesn’t add much to clarity.
Henning: This is not AVT group.
Dan: We need to agree on terminology.
Dean: No one understood the document.
Jonathan: What is role of these terminologies? Need to read half the document to get the first requirement.
Jonathan: We should use concepts available today and add to them, instead of defining everything top-down, as specified.
Rohan: We need more concrete examples and motivations for accepting things specified in the document.
Orit: I agree
Henning: Idea is keep H.232/ISUP etc at arms length from SIP. We don’t have any experience in T.120 and I don’t want to hear it again.
Jonathan: Agree with Henning.
Rohan: This needs to be taken offline. Need call flows etc for interworking.
Highlights:
· Terminology is very confusing; so is the draft.
· Needs more discussion offline.
· The spec needs to be clearer with concrete examples and motivations.
C) Henning presentation SIP Conferencing Requirements:
SIP philosophy: separate media / session signaling.
Model: (Henning)
· Support central-control conferences.
· Allow reuse of SIMPLE procedures.
· Do not invent new pieces
· Avoid conference specific profiles
· No T.120 special case
· No need to define requirements for things we all ready have (like conference creation, leaving etc)
· Believe meta-app model is misguided
General Model (Henning)
· Divide into requests and notifications (requests to do something, notification -- something happened)
· Requests may trigger notifications if action may be delayed or partial
Jonathan: Don’t agree with statement that says “no need to define requirements for things we already have”. There are some holes that we might have to fill.
Henning: Agreed
Brian: We need to think about interoperable devices. There are too many choices for that one to work today.
Additional Items: (Henning)
· Simplicity
· Bandwidth frugal (Mobile)
1. Incremental notifications & commands
2. Selectable notification granularity
3. Templates for privileges ---
Components identified by object manipulated: (Henning)
· Conferences
· Participants
· Resources
Conference Mgmt: (Henning)
1) Create Conference (Need mass invitation etc…)
2) Delete conference (name vs resource; might not want resources to be available after conference, but names could be around for a longer time)
3) Conference properties:
User Mgmt: (Henning)
Open issues: (Henning)
· Separate name and resource allocation
· Template management
Eric: After looking at both the presentations, I feel “Whole thing is out-of-scope”. Feel it is implementation dependent.
Rohan: At least, it is reasonable to consider standardization. We need more detail to figure which is out of scope.
Jonathan: Need to agree on a framework for standardization.
??: Interoperability between UAs is clearly in scope.
Rohan: Authors take a look at conferencing model draft and comment on where things break.
Henning: confused what are the next steps:
Rohan: get issues out on the list. One person should be responsible for collecting responses and summarizing it.
Brian: Lets solve a small problem and then worry about bigger problems: Like ad-hoc conferencing issues.
Jonathan: Multiparty Conferencing draft discusses it. However, it misses things like mass invites.
Brian: Take conferencing document and complete it.
Jonathan: We needed requirements for that document.
Henning: Need consensus on where it is out of scope or not.
Rohan: it is easy to identify which is out-of-scope than which is within scope. We need to do that first.
Highlights for the Conferencing Requirements:
· Get the issues out on the list. One person should be responsible for collecting responses and summarizing it.
· Authors need to look at the conferencing models and comment on where things break.
· Need to discuss the scope of the problem clearly.
· Complete the Multiparty Conferencing draft.
II. REFER / Replaces / cc-transfer / service examples (11:30am).
A) REFER: (Robert Sparks)
Refer 02 was split into multiple drafts:
· REFER without referred-by.
· New mime types draft.
· Referred-by draft.
Next steps:
· Finish referred-by draft.
· Integrate changes into cc-transfer draft.
Henning: What was motivation for having message/sipfrag instead of message/sip?
Robert: To prevent a lot of headers
Robert: The current plan is to send the Referred-By header as a S/MIME encoded body.
Robert: In body part there will be sipfrag which contains referred-by header with value of the referrer.
Henning: worried about cut and paste of this signature? Security issues !
Robert: Need to address it.
Jon: Other alternative is to send the REFER to another entity which can add the SMIME body.
Brian: Do we need Referred-by header?
Robert: Since there are implementations which use Referred-by, we need to use the same header name. Other than that, I have no preference for the header.
Robert: can be used by people who don’t want to interpret SMIME body.
Henning: Body should contain meta-data for what it is represents.
Henning: What about case with multiple refers?
Henning: try to make some correlation between some header and body part to identify the body part.
Andy: We need service examples in the paper.
Henning: We need section in paper to talk about issues when in areas where there is no synchronization in time.
Jon: We need to specify min set of headers that need to be present in the body. Others may or may not be present.
Brian: since there are multiple parties the synchronization problem is more.
Jon: Don’t see a problem with that.
Andy: What error message do we tell the user of there is a clock sync problem?
Robert: Just say “piece of info can’t be verified or is stale”
Robert: Refer in last call.
Robert: Referred-by will be done this week or next week.
Next Steps:
· Complete cc-transfer
· Complete Referred-by draft.
o Address security issues
o Provide service examples
o Meta-data to understand what the body refers to
o Correlation between header and appropriate body (especially, when the request is REFERed multiple times)
o Paper needs to talk about the time synchronization problem
B) Replaces draft – Rohan:
Rohan: took over draft from Billy Biggs.
Rohan: people were wondering whether “Replaces” can replace early dialog. Could not find any technical problems for replacing early dialogs.
Forking proxies problem: Is this going to be useful?
Jonathan: Strong objections. Assuming refer triggered invite hits the same proxy, proxies have to do things they have never done before.
Rohan: Propose to the list to remove proxy functionality and will go down some path to match forking logic at later time.
Jonathan: what about security issues. It is actually modifying the call of a third party and hence there is an authorization issue.
Jonathan: Must be a capability in the draft to authorize replace
Rohan: Will do.
Highlights:
· Security issues need to be addressed in the document.
· Forking proxies problem needs to be addressed (removed?)
Robert: CC transfers needs to be updated with refer changes & some security considerations.
D) Service Examples (Alan)
Changes in the latest version of the draft: (Alan)
· Added subscribe/notify using dialog event package
· Single line extension flow
· Added auto callback flow
· Changed to require “replaces” instead of “Accept-contact”
Open issues:
Single line extension:
· One subscription using forking to get to N agents vs N-1 subscriptions without forking
· Requires invite with join primitive
Alan: join is a separate draft not a working group item
Jonathan: Dint know we needed a join primitive for single line extension
Rohan: explained about Jonathan’s idea of Globally routable URI.
After this, there were some discussions on the need for Globally routable URIs.
Next Steps:
· Need to discuss this on the mailing lists.
Break for lunch.
updated 08 May 2002 19:05 -0500