1 / 22

User to User Key Signaling Protocols

User to User Key Signaling Protocols. Ellis K Cave Sr. Principal Engineer InterVoice-Brite. DTMF - is it Signaling or Media?. DTMF was designed to provide address signaling at start of call network address signaling DTMF originally turned off during conversation part of call

tallis
Télécharger la présentation

User to User Key Signaling Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. User to User Key Signaling Protocols Ellis K Cave Sr. Principal Engineer InterVoice-Brite

  2. DTMF - is it Signaling or Media? • DTMF was designed to provide address signaling at start of call • network address signaling • DTMF originally turned off during conversation part of call • Left on during call because of tip-ring polarity administration issues SIP WG

  3. DTMF - is it Signaling or Media? • PSTN service and application vendors discovered DTMF control in late 70s • Vendors standardized on the use DTMF for application control during call • simple user input mechanism • standard across all PSTN terminal device • Accidental provision of a standard user input model by the Telco made possible most of today’s complex telephony applications SIP WG

  4. The Infamous Octothorpe (pound sign) • Illustrates the confusion between network signaling and user signaling • VRU vendors use pound ‘#’ for application control • Input field termination • “Press pound when you complete your entry” • Network vendors use pound ‘#’ as call re-originate • “Press pound to disconnect the current LD call, and place another” SIP WG

  5. Network vs User Signaling Confusion • To differentiate between network and application functions, network providers had to require that the pound be held for over 2 seconds for network alerts • VRU vendors may still interpret a 2-second pound as an application function SIP WG

  6. Address Signaling in a Packet Network • Current packet session protocols thoroughly deal with address signaling • DTMF is not required for address signaling on packet terminals • Packet network address signaling standards • H.323 - Q.931, H225 • SIP Invite • Smart terminal aggregates address data input from caller • Terminal transmits aggregated address data in the call setup signaling message when user presses terminate (OK) key. SIP WG

  7. DTMF replacement in a packet network • DTMF-type address signaling is not required in a packet network • However, some type of user input keystroke signaling IS a requirement in a packet network for interactions with applications and other users • What will replace DTMF as application control in a packet network? SIP WG

  8. Most services in the packet network will require standardized user input. • Examples • voicemail • meet-me conferencing • recording/logging services • language translation services • hearing impaired service • To keep these applications simple, user input should be standardized across all terminal types SIP WG

  9. Questions • What do you want to have happen when a user presses a button on the keypad of a SIP desk phone during a SIP call ? • A cell phone? Answer • The same thing that happens when you press a key on the keyboard of a computer during a SIP call. SIP WG

  10. User Signaling in a Packet Network • H.323 defines user input indication - H.245 • Intended specifically for DTMF • Assumes 16-key device 0-9, *, #, and A-D • SIP doesn’t address user input issue • Schulzrinne made H.323 to SIP proposal • Left out user input indication translation SIP WG

  11. Current Proposals for SIP DTMF • http://www.ietf.org/rfc/rfc2833.txt. • http://www.ietf.org/internet-drafts/draft-ietf-sip-info-method-05.txt. • draft-kuthan-sip-infopayload-00.txt (expired). • http://www.ietf.org/internet-drafts/draft-choudhuri-sip-info-digit-00.txt. • http://www.ietf.org/internet-drafts/draft-culpepper-sip-info-event-00.txt. • http://www.ietf.org/internet-drafts/draft-agrawal-sip-h323-interworking-reqs SIP WG

  12. Where should you put User Input? • Should it go in the signaling protocol (SIP)? • The current Info Method proposals propose this approach • Does an application protocol belong in the session set-up/teardown signaling? • SIP Info Method has the right transport characteristics • guaranteed delivery • single packet • Should it go in the session description protocol (SDP)? • SDP currently only sets up media sessions SIP WG

  13. Where should you put User Input? • Perhaps User Input needs its own session specifically for user signaling. • If an application using SIP expects to need user input (and most will), the user agent should use SDP to set up a user input session • User input sessions will be as common as streaming media sessions SIP WG

  14. User Key Input Transport Protocol Requirements • Keystroke-based • Requires guaranteed delivery • no dropped packets • Requires guaranteed sequencing • receiver should be able to get transmitted input events in transmit order • Duration information should be an option • User input signaling protocol should be the same whether it is a SIP phone, a PC, or a cell phone! SIP WG

  15. What are the Choices? • RTP stream • Info Method • New SDP session protocol SIP WG

  16. RTP streaming for User Key Input • Pros • Existing protocol • Guaranteed Sequencing • Cons • User Input is not a streaming function • single keystroke events • RTP is not guaranteed delivery • Overly complex protocol for simple keystrokes • RTSP, stats, jitter buffers, etc • Simple text chat apps would require RTP stack • User Input needs to be a separate session from audio stream SIP WG

  17. SIP Info Method for User Key Input • Pros • Existing protocol • Guaranteed delivery • Simple mechanism (part of SIP) • Cons • Architecturally, application and user data should NOT be in the signaling channel • Future applications using redirection and replication of user input for multi-party conferencing would be prevented • How do you redirect or multicast the SIP session Info Messages? SIP WG

  18. New SDP Session for User Key Input • Pros • Allows selection of appropriate transport protocol for reliable keystroke delivery • Separate session for User Key Input • Allows redirect & multi-unicast, etc. • Cons • Need to define new SDP protocol for User Key Input • Must use SDP to set up User Key Input session SIP WG

  19. SDP supports • Video • Audio • Application • Data • Control • Which type of session is most appropriate? SIP WG

  20. Gateway Requirements • Gateway is the intelligent proxy for the dumb black phone in a SIP call. • Gateway never sees PSTN address signaling from terminal, only user key input • Job of the gateway is to convert DTMF to the new SIP User Key Input protocol • Gateway sets up User Key Input SDP session SIP WG

  21. Avoid the WAP/WML/HDML/WebClip Debacle • Different protocol for each type of device • To avoid chaos, the User Key Input protocol should be standardized for all packet terminal devices. • The “one” numeric key should produce the same message in the User Key Input session on all devices. SIP WG

  22. Conclusions • SIP architecture needs a User Key Input mechanism • Best choice is a separate SDP session • Could be “application’ or “control” session type • User Input should be standardized across all terminal devices • Keystroke/event message map defined in standard across all terminal device types SIP WG

More Related