User Requirements for SIP in support of deaf, hard of hearing and speech-impaired individuals

User Requirements for SIP in support of deaf, hard of hearing and speech-impaired individuals • Arnoud Van Wijk • Ericsson • Guido Gybels, Nathan Charlton • The Royal National Institute for Deaf People draft-charlton-deaf-req-00.txt

What has happened over the last three months? • draft-vanwijk-sipping-deaf-req-00.txt • 51st Meeting in London: decision to focus on the requirements • New draft with requirements only was submitted: draft-charlton-deaf-req-00.txt • SIPPING Charter: now includes under Nr 2, “Messaging-like applications under SIP”: support for hearing-, speech impaired calling • Milestone: Feb ’02: submission to IESG • Design team draft-charlton-deaf-req-00.txt

Motivation • Ensure SIP-based applications will fully support services for hearing/speech impaired users • Allow improved/new services where possible • è We can’t degrade the existing situation • è Avoid building solutions before req. are defined • è SIP already has the potential for new/improved services draft-charlton-deaf-req-00.txt

Open issues #1 Now that it is on the charter, can we rename the current draft to: draft-sipping-deaf-req-00.txt draft-charlton-deaf-req-00.txt

Open issues #2 Req. #5: “User Agents SHOULD be able to identify the content of a media stream in order to obtain such information as the cost of the media stream, if a transcoding service can support it, etc. User Agents SHOULD be able to choose among transcoding services and similar services based on their capabilities (e.g., whether a transcoding service carries a particular media stream), and any policy constraints they impose (e.g., charging for use). It SHOULD be possible for User Agents to discover the availability of alternative media streams and to choose from them.” è Some confusion about the meaning è We need ideas on how to do this! draft-charlton-deaf-req-00.txt

Open issues #2 (Continued) Do we just define this requirement and leave it to the implementers to come up with a solution? è We suggest: NO We have to define a model for doing this and incorporate that into the requirements. draft-charlton-deaf-req-00.txt

Open issues #2 (Continued) • What are the options? • SDP-based mechanism? • New SIP header? • Make assumptions based on the nature/origin of the call? • Don’t define a solution, let the operators take a decision? draft-charlton-deaf-req-00.txt

Open issues #2 (Continued) • Option a) Use SDP: • Elegant solution • BUT: currently no fields available? • So: do we need to define a new field type? draft-charlton-deaf-req-00.txt

Open issues #2 (Continued) • Option b) New SIP header: • Backwards compatible • Is SIP the right place to look for content? draft-charlton-deaf-req-00.txt

Open issues #2 (Continued) • Option c) Make assumptions based on the nature/origin of the call • Can be implemented today • BUT: Low granularity, relevance • High maintenance draft-charlton-deaf-req-00.txt

Open issues #2 (Continued) • Option d) Let the operator make a decision • How? • Currently possible by having human operators drop/accept the call: depends on human judgement • But: what about (semi) automated systems? • UGLY! draft-charlton-deaf-req-00.txt

Open issues #2 (Continued) Any other options?? Suggestions, please!! draft-charlton-deaf-req-00.txt

Open issues #3 • Very little feedback from the mailing list: • Did we capture all the business-cases??? • Is this a robust set of requirements? • Advocacy groups need to look at this • We need further thinking/input from the WG: testing the assumptions! draft-charlton-deaf-req-00.txt

What’s next? • Let’s look at the open issues and come up with answers; • Updated draft somewhere end of January 2002 • Last call • Submission to IESG as planned draft-charlton-deaf-req-00.txt

User Requirements for SIP in support of deaf, hard of hearing and speech-impaired individuals