1. December 2007IETF 70 - SIPPING1 SIP URI Service Discovery using DNS-SD draft-lee-sip-dns-sd-uri-02 Presented by Henning Schulzrinne Jae Woo Lee & Henning Schulzrinne Columbia University Wolfgang Kellerer & Zoran Despotovic DoCoMo Laboratories Europe

2. December 2007IETF 70 - SIPPING2 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

3. December 2007IETF 70 - SIPPING3 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= ;audio;video

4. December 2007IETF 70 - SIPPING4 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)

5. December 2007IETF 70 - SIPPING5 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

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

7. December 2007IETF 70 - SIPPING7 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

8. December 2007IETF 70 - SIPPING8 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

9. December 2007IETF 70 - SIPPING9 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?