1 / 22

SIP Location Conveyance for Geopriv using PIDF-LO and GML

This draft document proposes a method for conveying location information in SIP using the Presence Information Data Format for Location Objects (PIDF-LO) defined in the Geopriv Working Group. It explains the use of Civil Addressing and Coordinate or Geodetic representations. The document also discusses location conveyance in SIP through User-to-User and routing based on UAC location. Relevant RFCs and related topics are referenced.

jjune
Download Presentation

SIP Location Conveyance for Geopriv using PIDF-LO and GML

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. Needs changes to be made!!!! SIP Location Conveyance draft-ietf-sip-location-conveyance-04.txt James Polk Brian Rosen Oct 5th/6th, 2006

  2. Location Conveyance • Based on Presence Information Data Format (PIDF) for Location Objects (LO) as defined in the Geopriv Working Group of IETF • simply PIDF-LO • PIDF-LO uses GML (Geography Markup Language from OpenGIS) • 2 Location Representations are specified: • Civil Addressing (basically Post Office addresses which are internationalized) • Coordinate or Geodetic (Lat/Long/Alt with datum) • Two types of Location Conveyance in SIP: • User-to-User (I want to tell you where I am, have been or will be) • Routing based on UAC location (Proxies need to know my location to properly route the SIP Request (shown in Emergency example)) RFC 3825 Coordinate Location in DHCP RFC 4119 Geopriv PIDF-LO draft-ietf-sip-location-conveyance draft-ietf-geopriv-dhcp-civil

  3. RFC 3261 SIP Basics • The Session Initiation Protocol (SIP) is an application layer control (signaling) protocol for: • creating • modifying and • terminating multimedia sessions with one or more participants

  4. SIP Basics (cont’d) SIP components include: • User Agents (UAs) • Gateways • Registrar Servers • Proxy Servers • have degrees of statefulness • CSCF(s), B2BUAs, SBCs • Redirect Servers

  5. Version IHL DSCP ECN Total Length IPv4 Header is 20 Bytes and Binary Identification Flags Fragment Offset Time to Live Protocol Header Checksum Source Address UDP Header is 8 Bytes and Binary (Layer 4 here could also be TCP or SCTP) Destination Address Options Padding Source Port Destination Port Length Checksum SIP Headers in US-ASCII (variable in length per header/per message) SIP Header is Text-based and variable in length SIP message body is also variable, but not always present (depending on the Message-type) SIP messages *sometimes* have a message body - a SIP message header indicates the type of body - could be text, data, or something about audio, video or something else Example IPv4 SIP Packet format with UDP

  6. RFC 3261 SIP—INVITE Message INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 - Message body goes down here - Content-Length Header indicates one is present

  7. Applicable SIP Requests with Location • INVITE (RFC 3261) • REGISTER (RFC 3261) • SUBSCRIBE and NOTIFY (RFC 3265) • UPDATE (RFC 3311) • MESSAGE (RFC 3428) • PUBLISH* (RFC 3903) * NOT discussed in SIP Location ID

  8. INVITE RFC 3261 SIP INVITE including Location I Bob Alice Location within SIP— carried in header as URI or message body • A UAC can include its location as a message body: • Geolocation header, • Supported header, • geolocation option-tag, • Content-Type multipart/mixed INVITE sip:bob@192.168.10.20 SIP/2.0 Via: SIP/2.0/TCP pc33.atlanta.com ;branch=z9hG4bK77i832k9 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e6Kr456@pc33.atlanta.com Geolocation: cid:alice123@atlanta.example.com Supported: geolocation CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Accept: application/sdp, application/pidf-xml Content-Type: multipart/mixed; boundary=0a0 Content-Length: 543 sdp geolocation (if as a message body)

  9. INVITE RFC 3261 SIP INVITE including Location II Location within SIP— carried in header as URI or message body • A UAC can include its location as a message body: • Here’s the SDP Bob Alice --0a0 Content-Type: application/sdp v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.com c=IN IP4 10.1.3.33 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

  10. - Audio - UDP port (49172) for audio - Codecs included: G.711 v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.com c=IN IP4 10.1.3.33 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51172 RTP/AVP 31 34 a=rtpmap:31 H.261/90000 a=rtpmap:34 H.263/90000 - Video - UDP port (51172) for video - Codecs included: H.261, H.263 RFC 4566, 3264 SIP Message Body for multimedia • An SDP message body for voice only v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.com c=IN IP4 10.1.3.33 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 - Audio - UDP port (49172) to receive RTP - Codecs included: G.711 • An SDP message body for voice and video

  11. INVITE SIP INVITE including Location III Bob Alice Location within SIP— carried in header as URI or message body • A UAC can include its location as a message body: • Here’s a short form version of the location message body (long form on next slide) • Location in Coordinates --0a0 Content-Type: application/pidf+xml (short form*) Content-ID: cid:alice123@atlanta.example.com <gml:location> <gml:coordinates>36.132N 115.151W </gml:coordinates> </gml:location> <method>802.11</method> <provided-by>www.cisco.com</provided-by/> --0a0-- Valid size on next slide

  12. Based on this GML schema • To a point, a line, a polygon • Provides how location was derived • and who is responsible for it • After the fact troubleshooting RFC 4119 GEOPRIV Geospatial/Coordinate format <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0" entity="pres:geotarget@example.com"> <tuple id="sg89ae"> <timestamp>2006-03-27T09:00:00Z</timestamp> <status> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point gml:id="point96" srsName="epsg:4326"> <gml:coordinates>36.132N 115.151W </gml:coordinates> </gml:Point> </gml:location> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retention-expiry>2006-03-29T16:30:00Z</gp:retention-expiry> <method>802.11</method> <provided-by>www.cisco.com</provided-by/> </gp:usage-rules> </gp:geopriv> </status> </tuple> </presence>

  13. INVITE SIP INVITE including Location IV Bob Alice Location within SIP— carried in header as URI or message body • A UAC can include its location as a message body: • Here’s a short form version of the location message body (long form on next slide) • Location in civic address form --0a0 Content-Type: application/pidf+xml (short form*) Content-ID: cid:alice123@atlanta.example.com ... <gp:geopriv> <gp:location-info> <cl:civilAddress> <cl:country>US</cl:country> <cl:A1>Nevada</cl:A1> <cl:A3>Las Vegas</cl:A3> <cl:HNO>399</cl:HNO> <cl:A6>Convention Center</cl:A6> <cl:STS>Drive</cl:STS> <cl:PC>89109</cl:PC> <cl:LMK>LVCC</cl:LMK> <cl:RM>110</cl:RM> <cl:civilAddress> <gp:location-info> ... --0a0-- Valid size on next slide

  14. Newly defined in the PIDF-LO ID • Specifies up to 27 fields for civil location • Provides how location was derived • and who is responsible for it • After the fact troubleshooting RFC 4119 GEOPRIV civic format <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0" entity="pres:geotarget@example.com"> <tuple id="sg89ae"> <timestamp>2006-03-27T09:00:00Z</timestamp> <status> <gp:geopriv> <gp:location-info> <cl:civilAddress> <cl:country>US</cl:country> <cl:A3>Las Vegas</cl:A3> <cl:A6>Convention Center</cl:A6> <cl:STS>Drive</cl:STS> <cl:HNO>399</cl:HNO> <cl:LMK>Las Vegas Convention Center</cl:LMK> <cl:PC>89109</cl:PC> <cl:civilAddress> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retention-expiry>2006-03-29T16:30:00Z</gp:retention-expiry> <method>802.11</method> <provided-by>www.cisco.com</provided-by> </gp:usage-rules> </gp:geopriv> </status> </tuple> </presence>

  15. INVITE SIP INVITE including Location V Bob Alice Location within SIP— carried in header as URI or message body • A UAC can include its location as a URI: • Geolocation header with URI, • Supported header, • geolocation option-tag, • Content-Type application/sdp INVITE sip:bob@192.168.10.20 SIP/2.0 Via: SIP/2.0/TCP pc33.atlanta.com ;branch=z9hG4bK77i832k9 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e6Kr456@pc33.atlanta.com Geolocation: sips:alice123@atlanta.example.com Supported: geolocation CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Accept: application/sdp, application/pidf-xml Content-Type: application/sdp Content-Length: 243

  16. 200 OK INVITE SIP Response including Location Bob Alice Location within SIP— carried in header as URI or message body • 200 OK may contain either form of location delivery (message body or URI) • Since Request had appropriate Accept header SIP/2.0 200 OK Via: SIP/2.0/TCP sip:alice@atlanta.com ;branch=z9hG4bK77i832k9 To: Bob <sip:bob@biloxi.com>; tag=a6c85e3 From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e6Kr456@pc33.atlanta.com Geolocation: sips:alice123@atlanta.example.com Supported: geolocation CSeq: 314159 INVITE Accept: application/sdp, application/pidf-xml Content-Type: application/sdp Content-Length: 142 (Bob’s SDP here)

  17. SUBSCRIBE (w/Loc URI) NOTIFY (w/ Location) INVITE (w/Loc URI) 200 OK 200 OK Dereferencing Location URI LIS Bob Alice Location URI within SIP— carried in header as URI or message body has to be dereferenced to be any good • Location URI recipient (UA or server) will dereference the URI based on the scheme used • What happens next is up to what device type did the dereferencing • if it’s a UA, it could be done or send its location to UAC • if it’s a routing server, the location would be used by LoST next

  18. LoST Server LV PSAP#2 LV PSAP#1 LV PSAP#3 LoST (w/ Loc) LoST Answer (w/ PSAP URI) INVITE (with Location) INVITE (to URI as R-URI, with Location) 180 Ringing 180 Ringing 200 OK 200 OK ACK Session Established SIP Routing based on Location of UAC Alice CES.com Proxy

  19. Early LoST Query GPS psap2.lv.clark.nv.us.arpa.sos INVITE sips:usn... or psap2.lv... INVITE sips:psap1.lv... Las Vegas Fire Department DHCP Backend DB Location-based call routing – UA learns its location LoST Mapping Server Use of SIP UPDATE Method to update location changes noticed by UAC after call establishment Real-Time LoST Query Access Point 36° 13' N 115° 15' W 36° 13' N 115° 15' W  Las Vegas fire department

  20. INVITE sips:urn:service:sos SIP/2.0 Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK74 Max-Forwards: 70 From: Alice <sip:alice@atlanta.com>;tag=9fxced76sl To: <sip:urn:service:sos> Call-ID: 3848276298220188511@pc33.atlanta.com Geolocation: sips:alice123@atlanta.example.com Supported: geolocation CSeq: 31862 INVITE Route: <sips:psap2.lv.clark.nv.us.arpa.sos> Contact: <sip:alice@atlanta.com> Content-Type: multipart/mixed; boundary=0a0 Content-Length: 311 INVITE w/ SDP and Location • Location message body could be in the civic format --0a0 Content-Type: application/pidf+xml (short form*) <country>US</country> <A2>Las Vegas</A2> <A6>Convention Center</A6> <STS>Drive</STS> <HNO>399</HNO> <NAM>Las Vegas Convention Center</NAM> <RM>N111</RM> --0a0-- * “Short form” means not enough room here SIP Routing based on UAC’s Location Outbound Proxy Alice • SIP Routing based on Location • “sos@...” is not globally unique --0a0 Content-Type: application/sdp v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.com c=IN IP4 10.1.3.33 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

  21. INVITE sips:psap2.lv.clark.nv.us.arpa.sos SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.com;branch=z9hG4bK74 Max-Forwards: 70 From: Alice <sip:alice@atlanta.com>;tag=9fxced76sl To: <sip:urn:service:sos> Call-ID: 3848276298220188511@pc33.atlanta.com Geolocation: sips:alice123@atlanta.example.com Supported: geolocation CSeq: 31862 INVITE Route: <sips:psap2.lv.clark.nv.us.arpa.sos;lr> Contact: <sip:alice@atlanta.com> Content-Type: multipart/mixed; boundary=0a0 Content-Length: 311 INVITE w/ SDP and Location * “Short form” means not enough room here SIP Emergency based on UAC’s Location PSAP ESRP • SIP Routing based on Location • Request-URI based on current LoST Query by ESRP during call • If this “in-call” LoST Query fails, <lr> Route header is fallback • Location could be in geo --0a0 Content-Type: application/sdp v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.com c=IN IP4 10.1.3.33 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --0a0 Content-Type: application/pidf+xml (short form*) <gml:location> <gml:coordinates>36.132N 115.151W </gml:coordinates> </gml:location> <method>802.11</method> <provided-by>www.cisco.com</provided-by/> --0a0--

  22. Open Issues with ID • ABNF determining schemas possible? • OPTIONS usage to learn UAS’s location • has to do with Require header usage • probably will kill this idea • Location-by-reference allowed? • Granular Error Responses in 424

More Related