1 / 9

SIP URI Service Discovery using DNS-SD draft-lee-sip-dns-sd-uri-02

SIP URI Service Discovery using DNS-SD draft-lee-sip-dns-sd-uri-02. Jae Woo Lee & Henning Schulzrinne Columbia University Wolfgang Kellerer & Zoran Despotovic DoCoMo Laboratories Europe. Presented by Henning Schulzrinne. SIP UA Discovery using DNS-SD. Why?

rupert
Download Presentation

SIP URI Service Discovery using DNS-SD draft-lee-sip-dns-sd-uri-02

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. SIP URI Service Discovery using DNS-SDdraft-lee-sip-dns-sd-uri-02 Jae Woo Lee & Henning Schulzrinne Columbia University Wolfgang Kellerer & Zoran Despotovic DoCoMo Laboratories Europe Presented by Henning Schulzrinne IETF 70 - SIPPING

  2. SIP UA Discovery using DNS-SD • Why? • SIP communication within subnet without servers • E.g., wireless ad-hoc network, campus LAN • Why DNS-Based Service Discovery (DNS-SD)? • Widespread implementation: Apple Bonjour, iChat • Some SIP UAs already use it: Gizmo, Ekiga • Why not SIP multicast? • UAs can track peer locations using multicast REGISTER • But no query capability • New UA won’t discover existing UAs until their registrations are refreshed (up to an hour delay) • Not reliable - may miss registrations IETF 70 - SIPPING

  3. Overview of Operation • Multicast DNS (mDNS) • Runs on each host in a local subnet • Queries & answers are sent via link-local multicast to port 5353 • Special TLD reserved for local names: “.local.” • PTR records enumerate available service instances _sipuri._udp.local. PTR sip:bob@a.com._sipuri._udp.local. _sipuri._udp.local. PTR sip:joe@a.com._sipuri._udp.local. • SRV & A records resolve a specific service instance sip:bob@a.com._sipuri._udp.local. SRV 0 0 5060 bobs-machine.local. bobs-machine.local. A 192.168.0.100 • TXT records contain additional information sip:bob@a.com._sipuri._udp.local. TXT txtvers=1 name=Bob the Builder contact=<sip:bob@192.168.0.100:5060>;audio;video IETF 70 - SIPPING

  4. SIP URI Advertisement Format • Service instance name: Instance.Service.Domain • Instance = ( SIP-URI / SIPS-URI ) [ SP description ] • Service = “_sipuri._udp” / “_sipuri._tcp” / “_sipuri._sctp” • E.g.) sip:bob@example.com - PDA._sipuri._udp.local. • Contact TXT record attribute • Similar to Contact SIP header except: • It contains only a single URI • Non-SIP URIs are not allowed • UA capabilities advertised via field parameters (RFC3840) IETF 70 - SIPPING

  5. Forming SIP Request Using Discovered URI • “To” header • SIP/SIPS URI from service instance name (normally AOR) • Request-URI • SIP/SIPS URI from TXT contact attribute if available, otherwise same as “To” header IETF 70 - SIPPING

  6. determines transport uses default port if contact URI doesn’t have one Determining Request Destination Service instance name: sip:bob@a.com._sipuri._udp.local. Contact In TXT? No Yes TXT lookup SRV lookup Contact URI with host name: sip:bob@bobs-machine.local. Host name & port: bobs-machine.local. 5060 A/AAAA lookup Contact URI with numeric IP: sip:bob@192.168.0.100 IP address & port: 192.168.0.100 5060 IETF 70 - SIPPING

  7. User Interface and Security • Services are not authenticated in DNS-SD/mDNS • Anyone can advertise anything • UA should clearly distinguish two kinds of URIs: • User’s address book entries • Ad hoc URIs discovered using DNS-SD • Possibility: UA authentication using self-signed certificate • CA-signed certificate may be overkill in ad hoc network • Must warn user on first encounter of self-signed certificate IETF 70 - SIPPING

  8. Related Mechanisms • “_sip” service type used by Asterisk • Intended for server discovery • Gizmo & Ekiga use it for UA discovery • Now they can use “_sipuri” instead • P2PSIP • Replace centralized SIP servers with services provided by p2p endpoints • doesn’t work well in high-churn networks • significantly more complicated • Charter specifically excludes multicast-based approaches IETF 70 - SIPPING

  9. Open Issues • Believed to be complete, but... • Choice of AOR - require separate name space? • security vs. recognizability • Resolution mechanism? • deviates slightly from RFC 3263 • UI recommendations ok? IETF 70 - SIPPING

More Related