Reported by Mary Barnes
AAA requirements (Requirements) -- John Loughney and Gonzalo
Camarillo
http://www.ietf.org/internet-drafts/draft-calhoun-sip-aaa-reqs-04.txt
http://www.softarmor.com/sipping/drafts/draft-loughney-sip-aaa-req-00.txt
Discussion:
Ø Mary B: Is this a generic SIP AAA requirements doc or 3GPP or 3GPP2 specific?
Ø John L: Should be generic.Unlikely to update Calhoun draft. Battle for AAA has been decided to be Diameter. Radius is deemed insufficient.
Ø Henry S: Does not agree.
Ø John L: IETF will not be doing RADIUS extensions.
Ø Allison: Solution’s draft could be applied to RADIUS (due to DIAMETER compatibility with RADIUS). Propose RADIUS compatible AVPs for SIP work. This WG is not picking the technology.
Ø John L: There may be a general draft for using DIAMETER in a RADIUS compatibility role.
Ø Henry: It seems that we are throwing this approach (RADIUS) out.
Ø Allison: Problems with using RADIUS on a large scale. A lot of functionality should be transitional.
Ø Rohan: There’s nothing about this that says this is DIAMETER or RADIUS. Could use whatever protocol.
Ø Henry: Present version as it reads seems to restrict it to DIAMETER.
Ø Rohan: Would like to see Web services work (as referenced by Henry).
SIP Needs
Ø For AAA
Ø Are these needs modular? John L: Yes.
Ø Should they be?
Discussion:
Ø Jonathan: This looks to be 3GPP specific.
Ø John L: Shouldn’t be, but admits this was starting point. John is not SIP expert thus needs feedback to ensure generic.
Architecture needed
Ø Do we need to sketch out a roaming architecture for SIP where AAA is used, possibly in a modular way?
Ø Does multi-access make this interesting?
Discussion:
Ø Rohan: Question with regards to intent to cover access types in architecture.
Ø John L: May access as a subscriber with different access types. Services may have to vary depending upon access. Some things
Ø Rohan: SIP – you have one or more addresses of record, which can be associated with different access types. IF you’re accessing a SIP server that you normally don’t have a relationship with, but you want access. You could be doing this in a non-traditional, non-roaming perspective.
Ø John L: Unrelated, but needs to be brought out is that these requirements are meant to enhance SIP services and not detract. For scalability in some deployment scenarios, AAA can enhance the network services. These requirements should not burden SIP.
Examples:
Ø Simple 3GPP example
Ø WLAN roaming using 3rd party service providers
Discussion:
Ø Rohan: SIP UA on laptop and want to make calls to the PSTN. Invites go to various gateway UAs which want to Authenticate subscriber.
Ø John L: Access and Service are tightly coupled. Access authorization should be separate from Service Authorization.
Ø Brian R: Simplest example would be an enterprise with multiple sites. This is much simpler than 3GPP and WLAN roaming. Requires cross site authentication.
Charts for General requirements (from draft)
Ø JohnL: SIP has its own Authentication and Authorization needs outside of this.
Ø SIP Summit guy: Explain this from a service provider perspective.
Ø John L: you can have a SIP session without a AAA infrastructure. It could.
Ø Allison: very simple example. User and your request for SIP Digest goes to AAA. 2 SIP proxies that speak TLS may not need AAA network. Whether they are or not should be transparent.
Ø Radika: Extension in SIP for this?
Ø John L: No. work may not require extra extensions for SIP. Could be some beneficial extensions to SIP.
Ø Radika: How do you make this happen?
Ø John L: Some SIP servers may need to talk to AAA. But, this is solution’s space.
Ø Henning: What’s meant by deregistration?
Ø Jonathan: You didn’t pay your bill.
Ø Dean: Registration is related to whether you can make calls.
Ø Rohan: The service they most often want to provide is prepaid.
Ø Mary: 2.1.2 is Cx interface. This is database access.
Ø Jonathan: Who knows about this?
Ø Keith: Doesn’t know this.
Ø Rohan: If we can’t think of a good use for this in the general SIP case, then push to the end.
Ø Mary: 3GPP uses DIAMETER for Cx and database.
Ø Others (John L, Dean, Keith, Mark): use also for Authentication to get vectors from HSS to S-CSCF.
2.1.3 Updating SIP Server Entries is 3GPP specific.
2.1.4 Indication of Assigned Server is 3GPP specific.
2.1.5 User Deregistration
Ø Rohan: Re-write 2.1.5 – Want to be able to support pre-paid.
o Brian: This depends, the requirement may indeed be generic.
o Jonathan: Authorization model for outgoing calls.
o Rohan: If we have a term that has a SIP connotation, should change.
o Henning: Does this mean that “Register”: SIP Server asks and AAA server sends a token, does this mean that AAA server instantiates the notion of telling SIP Server.
o John L: General requirement. SIP server asks and AAA replies.
o Keith: PP requirement is a PP2 requirement. Believes it’s valid to remove a SIP registration.
o Rohan: There’s a lot of motivation for a requirement to do prepaid type of services. This is a useful requirement.
o Keith: What he’s saying is that both requirements exist. 3GPP requirement to remove a user’s association of proxies.
o Brian: Want deregistration for paranoid IT department.
o Rohan: What does this have to do with Registration.
o Brian: Basic SIP, want to turn off services.
o Rohan: Authorization Policy decision for operator. You could remove registration, but this is NOT the only way to solve the problem.
o Cullen: Meta-comment with regards to architecture with information PUSH. Do we want that as a requirement?
o John L: perhaps this should be a MAY
o Mary: this PUSH may be more related to DB access.
o Henning: Trying to do several things. Implement services. Also, saying how you could use AAA to do this. 2. Trying to define what AAA should do. 3. Not all of these are needed for every configuration.
o John L: solutions MAY provide that.
o Aki: DIAMETER provides other stuff. AAA Server can direct what kind of accounting can be done.
o John L: DIAMETER and SIP are similar in the protocol stack. APPLS on DIAMETER for SIP services. What are the needs to build APPLs on DIAMETER?
o Mark W: If you’ve obtained Authorization; if Authorization stops, how quickly do you want to enforce that? If a longer duration is acceptable, then that allows Registration related interval, however, this won’t work for prepaid where need realtime response.
2.1.6 SIP Server Allocation is 3GPP specific.
Ø Brian R: You have both to worry about. But, think this is a general problem.
Ø Sanjoy: Why is 2.1.6 a AAA problem?
Ø John L: Agree, this is 3GPP specific.
Discussion:
Ø Henry: Is there any idea of how call setup delay will increase?
Ø John L: Yes, this is a valid requirement that should not unduly impact realtime.
Ø Keith: You’re probably willing to wait longer for Auth during Registration.
2.2.1: Authentication Based on SIP REGISTER
Ø Rohan: Reword 2.2.1 to say “Authentication of SIP Requests”
Discussion:
Ø Henry: Handoff with these Authentication processes.
Ø John L: This is a different layer than SIP.
Ø Keith: If you’re moving out of area, Registration is lost…
Ø John L: Will you do handoff between service providers?
Ø Keith: Not during active call, you would need to re-register.
Ø JohnL: Is requirement that you should be able to move and roam?
Ø Henry: SIP doesn’t know about this.
Ø John L: What is the requirement?
Ø Keith: Changing servers doesn’t change registration. Changing providers does.
2.3.1: Ability to Authorize SIP Registration
Ø AKI: Should be Authroizing a SIP request.
Ø Allison: should flag any of these that are doing a AAA operation as part of a SIP request or per call.
Ø Cullen: Lots of info to pass as part of Authorization (from SIP server to AAA server).
Ø John L: Word as supporting “ disparate information as part of authorization decision”
2.4 Accounting
Ø Aki: General: How do you bill a SIP session?
Ø John L: Need a flexible approach.
Ø Brian R: This is a common problem: billing SIP services are hard.
Ø Allison: Perhaps, need an appendix to this document on how to deal with this.
Ø John L: This could help firm up the requirements.
Ø Aki: you can collect this info for trend analysis. .
2.4.1 : Separation of Accounting Information
Ø Cullen: Session duration is a complicated topic – at what point does session start (Invite, …)
Ø John L: Service providers should be able to specify.
Ø
2.4.2 Accounting Information Related to Session Progression
Ø JohnL: likely related to prepaid
Ø Keith: Not sure that right information is being conveyed. In 3G, want to transfer information during progress of session. Don’t think this is necessarily related to the prepaid.
2.4.5 SIP Session Changes
2.4.6 Support For Accounting on Different Media Components
2.4.7 Support for Cumulative and Non-Cumulative Accounting
Ø John L: This is from earlier document.
Ø Jon P: Stateful and Stateless.
Ø Cullen: IF this is just when call started or when call ended, then agree to this general requirement.
2.4.8 Configuration of Accounting Generation Parameters
2.4.9 Ability to Relate SIP Session to Access Bearer Used
Ø JohnL: this is likely a 3GPP requirement.
Ø Mary: This should go away.
Ø Jonathan: this is bad.
Ø Keith: Don’t think this is PP specific. P-headers are intended to provide correlation.
Ø Cullen: Generalized requirement: Support arbitrary correlation Ids.
2.4.10 Ability to Transfer Accounting Server Information
Ø Cullen: What does this mean?
Ø John L: Just specifying that need ability to do so, not specifying how to do so.
Ø Jon P: Auto-configuration?
Ø Cullen: Support an automatic discovery process.
Ø John L: this could fall into a general requirement, for sip configuration
Ø Henry: Nice to be in terms of XML files, etc. Should use same mechanism that is used in the Internet.
4 Security Considerations
General Discussion:
Ø John L: Question to chairs: Thinks there’s a need for this document. After this document is done, what do we do? Does this require additional work in SIP or AAA?
Ø Brian: Want requirements documents out of SIPPING. Put a small design team together to determine where this needs to be done. We may have to force requirements over to AAA.
Ø Henry: Needs more than AAA. This ties you to business support systems. 1. How does SIP Server interface/interact with AAA? 2. Billing: billing is tied to business support systems. Business support systems are all based on XML.
Ø Allison: A design team is a good idea, because there is need to do some homework. There’s been lots of homework done on XML by AAA-Arch and AAA WG. Gathering the knowledge base from that work into a small group better than doing it on the fly. Don’t want to do this just in SIP. See a BCP for SIPPING to ensure that we properly influence other bodies. Need more homework.
Ø Aki: whether Accounting server is DIAMETER. You need a backend from AAA server that you could tie into business system.
Ø Henry: backend is considered front-end by some J
Ø Allison: nothing stops you from developing whatever interface you want from the accounting record. How much needs to be done in IETF.
Ø Henry: agree don’t want to take on design work from others.
Ø John L: points back to 2.1.1.
Next Steps
Ø John L: Should this in general be a WG draft?
Ø BrianR: can’t make a WG item decision at an interim meeting; take discussion to the list.
Ø AKI: SIP-AAA list?
Ø Allison: keep on the SIPPING mailing list.
Ø Henry: propose coordination with AAA-arch and AAA folks at next IETF meeting. Mobile IP WG has gone through this.
Ø Allison: Mobile IP is struggling because they didn’t do upfront work.
Ø Henry: AAA WG has fixed itself on DIAMETER. May want to argue that identity should be XML based.
Ø John L: SIP must be able to derive SIP identity from network identity. May not be the only way.
Ø Aki: in Digest, you already have the concept of a non-XML based identity.
Ø Henry: need an identity that is compatible with Internet payment systems. Don’t need to repeat the AAA WG screw-up.
Ø Jon P: Talk about the kinds of identities in SIP and then decide.
Ø Rohan: Requirements should be generic enough.
Ø Jon P: We have a base specification that already discuss authentication and authorization and new network identity stuff.
Ø John L: is this reasonable?
Ø Allison : This is perfect. Nothing should be dictating content or form of data. You don’t get XML document built into SIP. Won’t belabor AAA/Diameter spec issues.
Ø Sanjoy: Does diameter support XML based AVPs?
Ø John L: Appls on DIAMETER can support this; may need specific extensions.
Content Indirection (Jonathan Rosenberg)
http://www.ietf.org/internet-drafts/draft-olson-sipping-content-indirect-00.txt
History – basic problem is in sip events, we had ability for NOTIFY to contain a URL to find the state instead of the state itself. Thought it was a generally useful. Just as draft was about to go to draft it got pulled out – several reason but include that this was not really notify specific mechanism. Seemed that lots of things, particularly IM cases, would want to send just the URL then the receiver can decide when if and how to fetch the resource that the URL referred to. Took this to sipping to generate this draft.
Ø Henning – Closely related to earlier work on web change notification in draft-wu-sipping-webshare-00.txt
Ø Jonathan: Why is this a remotely hard problem? Issues such as lifetime: how long is the URL good for?
Ø Rohan: Am I publishing presence doc or giving you a URL from which to render data?
Ø Jonathan: Want to be able to PUSH content with versioning, such that you know whether you need to get new content.
Ø Henning: There is a strong connection to the publishing issue. Discussion seemed to point to certain architecture. Does it make sense to treat these as separate problems OR should we look at this as 2 facets of the same problem that overlap.
Ø Jonathan: If publish should be done as SIP PUBLISH. This problem is an upward reference to the other.
Ø Henning: can see the same mechanism working in both cases. A variety of SIP methods contain a list of URLS with expiration and type information. Can stick same header in the NOTIFY and it would do the same thing.
Ø Jonathan: One problem is a customer of the others. Can you “publish” mechanism to achieve the content indirection.
Ø Henning: Publish requirements can be folded in here.
Ø Rohan: Why should publish requirements be applied here?
Ø Ben: requirements are separate, BUT the same mechanism can meet both sets of requirements (e.g. lifetime of URL). IF you add: Is this URL rewrite-able, then you get very close to PUBLISH requirements.
Ø Henning: Only difference is direction.
Ø Ben: requirements are generically different, but both can lead to a common mechanism.
Ø Rohan: you don’t need an explicit direction. HTTP URI with method = POST – writing.
Ø Henning: May not care about R/W. What you care about is the protocol equivalent things that you can apply (e.g. GET/POST). Don’t see customer relationship. One comes from a read perspective, another a write perspective.
Ø Rohan: Content indirection doesn’t have to be read only. Content Indirection is more generic than publication. PUBLISH may be a trivial use of content indirection.
Ø Jonathan: Henning seems to be proposing that these requirements include the PUBLISH ones. Haven’t thought about this in that perspective. Content vault introduces more requirements.
Ø Ben: Don’t want to merge requirements. Want to know what it is you want to accomplish. Agree mechanism is likely to be similar, but don’t want to force same solution.
Ø Rohan: There are uses for this outside of publish. Requirements should be kept separate. Mechansim work later can incorporate both later.
Ø Related to this is the fact that
REQ-2: It MUST be possible to specify the purpose and disposition of
each URL independently. At a minimum, the following
dispositions SHOULD be supported:
* render: the content should be rendered
* publish: the content contains service data that the
client wishes to push to the server
* retrieve: the content represents data that is to be
shared between the client and server
* execute: the content represents executable data such as a
script that is intended to be executed as part of the
processing of this request
Discussion:
Ø Jonathan: finds this confusing. Any disposition in Content disposition header should be able to go here.
Ø Henning: Note the use of publish.
Ø Ben: using content indirection to publish.
Ø Adam: Replace “Server” with “User Agent Server”
REQ-6: The mechanism MUST ensure that the element which uses the URI
will be able to access a content type it understands. This is
to avoid losing the ability to negotiate content types when
using the content indirection mechanism.
Discussion:
Ø Jonathan: Implementation choice in SIP (JPEG or GIF) , should be same here.
Ø Roni: You know other side cannot handle the format until after you send it. Should be able to determine before you send.
Ø Jonathan: We’re not looking to solve the RESCAP problem. Want to make sure existing SIP functions are lost.
REQ-8: It MUST be possible for an automaton to process the content
indirection without human intervention.
Discussion:
Ø Jonathan: Normal assumption that other end (automata) can handle the content
REQ-9: It MUST allow for indirect transference of content in any SIP
message which would otherwise carry that content as a body.
Discussion:
Ø Rohan: Should exclude bodies with SESSION.
Ø Cullen: can’t lead to clients MUST support HTTP.
Ø Rohan: What if content expires, thus the indirection problem does become more difficult. You’re not providing enough information to understand why this break.
Ø Jonathan: New requirement: for additional errors or warnings.
Ø Rohan: Very little motivation for doing indirection of OFFERS/Answers.
Ø Jonathan: Why is OFFER/ANSWER worse or better.
Ø Rohan: Content is typically optional.
Ø Johnathan: what is requirement? Only work for optional content OR should it highlight potential problems.
Ø Rohan: Requirements: 1. Way for appropriate errors/warnings. 2. Verify that you don’t break Offer/Answer model with content in sessions.
Ø Jonathan: Protocol already supports this. Should highlight areas where the use of this would be inappropriate.
Ø Peter: When do you send the 200 OK.
Ø Jonathan: after you retrieve the URI.
Ø Ben: The distinction between an error due to indirection piece (eg.. Notify with indirect body. Is 200 OK to indirect body). Thus indirection must complete before 200 OK, thus timing issues.
Ø Adam: don’t think this is an issue.
Ø Jon P: IF mandatory should fail the message. Might want to have SDP for content indirection for encrypting or signing, thus it’s larger than useual.
Ø Jonathan: Requirement for being able to indicate whether message should be responded before or after content fetch. May need to couple with optional or mandatory.
Ø Roni: How will you know receiver of message can handle? (Requirement 6)
Ø Jonathan: Don’t loose negotiation capabilities from before.
Ø Cullen: What is real motivation behind requirements? Is this a mechanism for dealing with blocks that are too large for UDP messages OR a SIMPLE requirement?
Ø Jonathan: Started solving problem in different application contexts. What is the broadest general problem? “Sending content indirectly”
Ø Adam: Timing issue is a red herring. It’s not any different than when you have to fetch things vs proxy having to interface with something else before sending response.
Ø Peter: You have 2 types: immediate ack, can await an ack. Do you have a means if you’re delaying?
Ø Jonathan: Agree that you need the 2 types. Additional requirement for notification later if there’s a failure to an already responded to.
Ø Sanjoy: 100 trying. Download can’t send a response.
Ø Jonathan: Again, agree that there are 2 types: immediate response (optional), delayed (mandatory). This is another requirement for an additional notification for the immediate response scenarios. In SIMPLE, handling this case for IM by adding a success/failure indication. Broadening of that requirement.
Conclusion: Req-9 is a requirement.
More Discussion:
Ø Rohan: believes that content indirection only makes sense for optional.
Ø Jon P: new status code to indicate that you couldn’t process because you couldn’t retrieve indirect content. Why not allow?
Ø Rohan: Just because you can, doesn’t mean you SHOULD?
Ø Jon P: Sees uses for this for some devices.
Ø Rohan: Asking UAC to be well behaved in one way, but not in another.
Ø Adam: EG: page mode message with a URL.
Ø Henning: Recipient can decide how important call is. May decide that you can pay to download URL OR reject, thus allows recipient some control.
Ø Rohan: These things are going to have to be processed automatically.
Ø Jonathan: Fetching would only happen if rest of message was handled successfully.
Ø Joerg: Agrees with Jon P’s approach.
REQ-10: It MAY allow for indirect transference of content in any SIP
message which would otherwise carry that content as part of the
SIP headers. In other words, a SIP message with a large number
of headers could transfer the content of those headers
indirectly through this mechanism.
Discussion:
Ø Rohan: This seems bad.
Ø Allison: This seems to be really inviting trouble.
Conclusion: Remove Req-10.
Next Steps:
Ø Update requirements document.
Discussion:
Ø Rohan: Concensus on requirements, can we start work straight in SIP?
Ø Jonathan: Get this added to charter, finish requirements in SIPPING.
Ø Allison: Fits in existing charter. Publish requirements.
Key Events/ Stimulus Markup – Bert Culpepper & Jonathan Rosenberg
http://home.cfl.rr.com/bculpepper/draft-culpepper-sipping-app-interact-reqs-01.txt
R5: The protocol mechanism must provide a means for a network
entity to indicate its desire to receive user activity
indications and/or to present an application interface on the
User's UA. The protocol mechanism must provide a means for a
SIP UA receiving a request to respond with its
capability/intent to provide the requested services.
Ø Have rewritten the requirement to specify behavior for the protocol agent
R-8: The mechanism should support devices that possess a UI, and those which do not possess a UI.
Ø Thus, R-8 has been reworded.
Ø Discussion:
Ø Jonathan: Some devices have a display capability. Some devices (i.e. black phone) don’t have this.
List comment: The mechanism should be capable of handling Uis from simple screens
……
Reworded R-10:
List comment: The mechanism should allow the user to interface with multiple user interfaces for different applications within the same call.
Ø Bert’s Comment: Took this to mean that the mechanism should somehow dictate the user interface of the device.
Ø Thus, added R-18.
The mechanism should allow the user to know which appliction is associated with which user interface/input.
Ø Added R-17.
The mechanism should allow a device ….
…
Ø RFC comment: Described the view of the virtual instance of a device’s physical UI that can be “placed in focus”. BC: This is a device thing.
Ø JDR: The mechanism must support providing a display.
Added R18, R19 and R20:
R18: The mechanism must support the ability for multiple virtual
user interfaces to be associated with the same user session.
Each virtual user interface may be associated with the same or
different applications. For example, a user may want to
interact with a voice-recording application and a prepaid
calling application within the same call but allow each
application to use a different virtual user interface.
Discussion on the concept of the virtual instance:
Ø Jonathan: How can multiple apps cooperate within the same Virtual User.
Ø BC: Not sure what’s RFC’s point.
Ø Matt H.: Multiple Uas in virtual manner.
Ø Jonathan: An example would be a call from a PC interacting with VRU and prepaid app. One model would be 2 screen pops with view on each appl. Overall app is the entire monitor. Each app views that it has ownership of the entire screen.
Ø Henning: terminology is unusual.
Ø Jonathan: Makes sense for a screen with buttons, screen area maps to a button. The phone figures which app gets which buttons. A similar concept of “windows” as far as resources.
Ø Henning: perhaps logical versus physical. Physical representation is independent of logical. Can be represented in many ways (softbuttons, screens, etc.)
Ø Jonathan: can figure term later. Should this be part of requirements? Requirement for multiple Apps to I/F with user.
Ø Cullen: Not one type of focus: keyboard, voice, etc. Event model of virtualizing these events to the “windows” needs to be described.
Ø Jonathan: will depend upon markup types. DTMF case is really hard. Requirement should be to focus this to a specific markup.
Ø Matt H: ability to have a virtual I/F across multiple physical. Virtual User I/F that work across multiple types of input.
Ø Jonathan: there is a requirement that it support a wide range of devices.
Ø Matt H: 2 way – responding back must support this.
Ø Carl/SIP Summit guy: need to eliminate the word virtual. Stuck in the paradigm of DTMF.
Ø Bert: Likes Hennings “logical” versus “physical”
Ø Sanjoy: Support context: Will DTMF need this concept?
Ø Jonathan: markup proposal is to provide context. With markup proposal, yes.
Ø Bert: Context would be indicated through the subscription.
Ø Jonathan: How does a user know: prepaid vs. voice recording when user presses #? With markup: user can provide context, thus no feature interaction problem. Need to support the case where you can’t have context. Don’t want this to be the paradigm to be supported.
Ø Bert: believes this is a device problem. Logic would have to be inside the device and defined in the package.
Ø Peter: need to be able to present markup on a dumb device.
Ø Sanjoy: when you’re sending notification: event name tells you the context. How do you map key to specific event notification?
Ø Jonathan: you’ve wandered away from requirements. From a requirements perspective, does appl provide a context?
Ø Conclusion: General agreement on this requirement.
R19: The mechanism must support the ability for multiple
applications to explicitly cooperate within the same virtual
user interface. Specifically, each application may be
associated with different UI components within the same virtual
user interface.
Ø Bert: believes R19 needs to be cleaned up.
R20: The mechanism must allow user interface components created
through this mechanism to be updated or removed as desired by
the creating application entity.
List comment: The mechanism must allow a user to have assurances that the user input it is providing is only to applications/servers on the call path between caller and callee.
Ø Reword R16:
Reword R17:
R17: The Reporter must be able to identify and authenticate the
Requestor for each user interface component. Specifically, in
the case where the Requestor is an Application Entity, the User
must be able to identify the application name & instance. An
application instance consists of the application type [e.g.,
application’s name, version & application designer name] and
application instance [e.g., instance identifier & service
provider's identity].
Ø Jonathan: how do you know appl should legitimately get feedback? This should be an expression of authorization policies.
List Comment: The mechanism must work with applications that are both proxy and bbua.
Ø Author’s comment: Authors feel that the requirements are for the protocol agent and this requirement is addressed.
Ø Jonathan: SIP piece could be a proxy.
Robert’s (RFC) new questions:
A) Are people sufficiently interested in pursuing and solving the more general problem of representing input-based UI components beyond the simple telephone DTMF dialpad at all?
B) If so, do we want only one general key-based interaction mechanism where DTMF dialpads are simply a particular key-instance within that mechanism; or do people want multiple mechanisms; …
Conclusion: Bert: will update doc and sendout.
Markup as a Framework for App Interaction (Jonathan)
http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-markup-00.txt
What’s the idea
Ø General problem is to provide stimulus input to network applications.
Ø Stimulus signaling has 2 aspects:
o A display to guide the stimulus
o A way to collect the stimulus and send it to the application
o May not be a display (black phones)
Ø Markup languages (HTML, WML, VoiceXML) are targeted at this functionality.
Basic Flow
Ø UAC sends INVITE
Ø Apps return 183s with app-info header (contains an HTTP URI for fetching markup)
Ø Caller fetches markups (can use CC/PP to handle UI variations, Fetches from each app)
Ø Renders/executes markups
Ø Input Posted to URI in markup (may fetch more markup)
Handling Display-less UI
Benefits of this framework
Ø Supports a vast array of devices under same model (PCs, wireless phones, virtual reality I/F, etc.)
Ø Treats display less UI as a subset of general case
Ø Simple for simple devices (Barebones HTTP and trivial XML)
Ø Allows for reuse of existing w3c work in this area (HTML, VoiceXML, CC/PP)
Ø Provides a sane model for involving multiple applications (separate vitural UI-screen pops, dividing button real estate, etc.)
Discussion:
Ø Cullen: Agree on XML, but believes that HTML will continue to get more complex.
Ø Jonathan: Don’t want to limit solution.
Ø Henning: W3C approach (???).
Ø Jonathan: This is SALT. The point of this proposal was to support that sort of stuff.
Ø Rohan: The DML seems to be lacking the ability to specify a “long” pound.
Ø Jonathan: IF you want that, do it.
Ø Dave O: it’s in the MGCP digit map stuff. You’d need some way to encapsulate the digit map and the parms.
Ø Jonathan: Can add all that’s required as far as timers, etc to this proposal.
Ø Jonathan: Framework allows UACs to know the order in which they were encountered.
Open issues:
Ø Do we want a general framework this this or should we focus on key –events….
DML issues:
Ø How to handle multiple DML docs?
o Fork DTMF to each
o Prioritize them, define pass-trhur models
o Prioritize them, highest consumes until it terminates
o Others?
Ø How to prioritize them?
Ø What are the models for passing through?
Discussion:
Ø Mike P: confused about how DTMF is being used here. Sometimes it’s the AVT aspect and sometimes it’s a reference to the keypad.
Ø Jonathan: from UA, it’s the 12-key keypad.
Ø Rohan: Do you want to use the term signaled digits?
Ø Mike P: should remove the term DTMF.
Ø Mike P: Need to indicate that a button has been pressed for an amount of time.
Ø Dave O: This has nothing to do with DTMF as a physical layer encoding of button presses. BUT, as a stimulus package to capture low-level user interface actions.
Conclusion: General agreement that this is the right framework with which to continue.
updated 08 May 2002 18:58 -0500