目前應急指揮和報警，醫(yī)療救助，極端環(huán)境救援系統(tǒng)已經被廣泛在了政府和其他救援機構中。第一時間準確獲取到報警人地理位置信息是救援是否成功的關鍵。在報警流程中，絕大部分的報警人地理位置信息獲取方式仍然是依靠傳統(tǒng)的方式獲取。它首先需要報警人自己報告具體位置。但是，在一些特殊場景中，報警人不能非常明確清晰地報告準確位置，這樣就會導致救援效率降低。我們國家最早的應急管理系統(tǒng)是廣西南寧市在2002年建立的應急管理系統(tǒng)。以前絕大部分的系統(tǒng)應急指揮呼叫是基于傳統(tǒng)PSTN網絡環(huán)境中部署的，和當前IMS網絡呼叫的技術相比，在應急指揮響應，特別是針對語音呼叫報警方面仍然有很多可提升的空間。語音呼叫IP化，IMS部署已經納入了運營商的技術推進的時間表中，SIP語音呼叫已經逐漸成為主流，利用最新語音技術實現(xiàn)地理位置信息傳輸（例如，通過SIP擴展頭Geolocation實時同步傳輸?shù)乩砦恢眯畔ⅲ┮彩且粋�提升響應速度的非常重要的手段。一些國家也通過法律手段明確了一些特殊場景的呼叫，例如報警，緊急救援的呼叫必須支持呼叫攜帶地理位置的要求。筆者針對通過SIP控制頭geolocation方式實時傳輸?shù)乩砦恢眯畔⒆鲆恍┍容^全面的討論，討論的話題主要包括關于SIP呼叫攜帶地理信息的背景說明，關于業(yè)務場景中使用的各種地理信息的場景需求，在SIP INVITE中指出Geolocation擴展頭和核心RFC方面，關于Asterisk和思科的CUCM中SIP對geolocation的示例說明，以及目前通過第三方接口獲取地理位置同步呼叫時可能面臨的挑戰(zhàn)。

　　我們知道，在SIP呼叫中，呼叫可能經過多個實體邏輯的處理，例如通過網關接入，通過SBC接入，或者通過其他第三方服務器的轉發(fā)，或者VPN等等。這些呼叫經過了多個實體邏輯的處理以后，其呼叫雙方的終端可能在同一物理空間（同一層樓或者同一層樓不同辦公室房間），也可能在不同的物理地理空間，例如終端雙方可能分別處于地理空間的不同城市，也可能是不同國家。在過去20年中，很多呼叫業(yè)務形態(tài)和客戶端需求基本上都是基于基本的呼叫業(yè)務，沒有對其他新業(yè)務有太多的需求。但是，在最近幾年，隨著應用場景的不斷迭代，用戶部署環(huán)境的變化，這些終端也隨之發(fā)生了改變，這些改變帶來了業(yè)務方面的變化，例如終端的移動性帶來的數(shù)據(jù)更新，基于SIP的IOT終端，緊急呼叫業(yè)務的支持能力，應急指揮調度系統(tǒng)，以及最近運營商強制要求的STIR/SHAKEN呼叫身份驗證等問題。進一步來說，隨著呼叫業(yè)務部署的形態(tài)不斷變化， 包括云部署方案的推進，以及語音業(yè)務的IP化升級改造，如何能夠在終端呼叫的同時能夠疊加支持物理空間和地理位置的服務，并且提供相應的用戶位置定位（Geolocation）是一個目前運營商或者企業(yè)通信解決方案中仍然難以解決的難題。我們的友好領邦印度就有關于相應的TRAI法規(guī)，明確要求呼叫支持Geolocation。另外，美國FCC在2019年已經發(fā)布了關于E911緊急呼叫業(yè)務的地理位置的明確規(guī)定。

　　此圖例以及以下圖例均來自于互聯(lián)網資源

　　今天，作者就這一難題進行全面討論。以下視頻中，報警人需要說明自己的地理位置是正確報警的關鍵�？墒�，實際生活中，我們仍然不能比較好地解決這個問題。

　　首先，我們對SIP用戶的地理位置的需求背景做一點簡單介紹。在當前很多的業(yè)務場景中，需要支持SIP用戶的Geolocation功能。當然，除了通過Geolocation擴展頭支持地理信息以外，現(xiàn)在很多的支持方式也支持了地理位置的查詢，但是需要通過實時服務的應用來實現(xiàn)，集成到SIP應用中。這些方式不是我們本章節(jié)討論的主要內容，我們在后期討論中會涉及類似內容�，F(xiàn)在，我們針對SIP呼叫支持地理位置學習進行討論，其業(yè)務場景包括以下幾個典型的場景：

　　以上幾種典型的場景中，如果通過SIP 呼叫攜帶了地理位置信息的話Geolocation，就可以提升應急指揮和報警服務系統(tǒng)的響應速度，確保了位置的準確性。當然，如何對SIP INVITE呼叫中添加對地理位置的消息支持擴展需要其他的技術規(guī)范來實現(xiàn)。IETF國際組織，針對SIP INVITE，包括3GPP的呼叫對地理位置的支持定義了多個RFC，例如RFC6442和RFC8787等。在以下內容中，我們分別討論幾個和geolocation 相關的技術規(guī)范。在具體討論geolocation或者地理位置之前，我們首先什么一個大家都比較熟悉的地理概念。

　　在呼叫過程中，我們需要攜帶呼叫方的具體位置，把呼叫方的具體位置傳輸?shù)胶艚薪邮辗�務器端。因此，我們需要首先大概說明關于位置的標識�；\統(tǒng)地說（筆者不熟悉地理知識，僅簡單說明），我們確定一個物體或者實體的位置包括兩種方式：1）以國際標準定義的經緯度的方式，通過經緯度來定義具體的地理位置和坐標。2）通過地圖文字標識和空間內部具體位置的方式表示的位置，例如，某個國家地區(qū)城市的街道來標識，或者建筑物中的第幾層第幾個房間號碼。這兩種標識方式都會在我們接下來介紹的規(guī)范中和后期介紹的用戶場景中使用。在討論規(guī)范前還要說明，我們目前沒有一個單獨的關于geolocation的官方文檔，關于geolocation 的部署使用規(guī)范其實涉及了多個RFC規(guī)范。在SIP協(xié)議中，SIP通過擴展的方式支持了geolocation的傳輸。具體的規(guī)范在RFC6442中有明確規(guī)定。此RFC6442定義了如何使用SIP傳輸?shù)乩硇畔⒌刂返浇邮辗?Location Recipient (LR)的三個SIP擴展頭，它們分別是Geolocation， Geolocation-Routing 和 Geolocation-Error，通過這三個擴展頭確保地理信息傳輸?shù)臏蚀_性。以下是一個Geolocation頭語法：

　　message-header    =/ Geolocation-header

　��； (message-header from RFC 3261)

　　Geolocation-header = "Geolocation" HCOLON locationValue

　　*( COMMA locationValue )

　　locationValue      = LAQUOT locationURI RAQUOT

　　*(SEMI geoloc-param)

　　locationURI        = sip-URI / sips-URI / pres-URI

　　/ http-URI / https-URI

　　/ cid-url ； (from RFC 2392)

　　/ absoluteURI ； (from RFC 3261)

　　geoloc-param = generic-param ； (from RFC 3261)

　　可支持的SIP請求包括：

　　INVITE [RFC3261]，REGISTER [RFC3261]，OPTIONS [RFC3261]

　　BYE [RFC3261]，UPDATE [RFC3311]，INFO [RFC6086]

　　MESSAGE [RFC3428]， REFER [RFC3515]，SUBSCRIBE [RFC3265]

　　NOTIFY [RFC3265]，PUBLISH [RFC3903]

　　另外，RFC3693定義了對geolocation地理位置傳輸?shù)姆绞�，例如，現(xiàn)在我們使用的SIP協(xié)議就是其規(guī)范的其中一種方式。現(xiàn)在，我們看一個比較典型的SIP 中間代理作為B2BUA的處理方式。

　　在以上圖例中，SIP中間代理服務器作為一個B2BUA來協(xié)同雙方UA對定位對象的支持。Alice和Bob可以作為SIP UA發(fā)送接收地理信息，LS是一個定位服務器，通過URL來獲取Bob的定位對象-location object。關于LS的具體的處理機制，讀者可以參考RFC3693。通過B2BUA的話，B2BUA就可以通過自己的管理機制或者其他權限安全機制來處理Alice或者Bob的請求和定位對象。在RFC6442中也針對Geolocation-Error有非常詳細的定義，同時，此規(guī)范也定義了其他錯誤碼，例如獲取定位信息失敗等響應，例如424：

　　424 (Bad Location Information)，作為SIP 響應碼

　　通過返回的錯誤碼對獲取地理信息失敗以后做進一步規(guī)范處理。SIP INVITE中包含地理信息示例：

　　Geolocation： <cid：target123@atlanta.example.com>

　　INVITE sips：bob@biloxi.example.com SIP/2.0

　　Via： SIPS/2.0/TLS pc33.atlanta.example.com；branch=z9hG4bK74bf9

　　Max-Forwards： 70

　　To： Bob <sips：bob@biloxi.example.com>

　　From： Alice <sips：alice@atlanta.example.com>；tag=9fxced76sl

　　Call-ID： 3848276298220188511@atlanta.example.com

　　Geolocation： <cid：target123@atlanta.example.com>

　　Geolocation-Routing： no

　　Accept： application/sdp， application/pidf+xml

　　CSeq： 31862 INVITE

　　Contact： <sips：alice@atlanta.example.com>

　　Content-Type： multipart/mixed； boundary=boundary1

　　Content-Length： ...

　　Content-Type： application/sdp

　　...Session Description Protocol (SDP) goes here

　　--boundary1

　　Content-Type： application/pidf+xml

　　Content-ID： <target123@atlanta.example.com>

　　<？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：gbp="urn：ietf：params：xml：ns：pidf：geopriv10：basicPolicy"

　　xmlns：cl="urn：ietf：params：xml：ns：pidf：geopriv10：civicAddr"

　　xmlns：gml="http：//www.opengis.net/gml"

　　xmlns：dm="urn：ietf：params：xml：ns：pidf：data-model"

　　entity="pres：alice@atlanta.example.com">

　　<dm：device id="target123-1">

　　<gp：geopriv>

　　<gp：location-info>

　　<gml：location>

　　<gml：Point srsName="urn：ogc：def：crs：EPSG：：4326">

　　<gml：pos>32.86726 -97.16054</gml：pos>

　　</gml：Point>

　　</gml：location>

　　</gp：location-info>

　　<gp：usage-rules>

　　<gbp：retransmission-allowed>false

　　</gbp：retransmission-allowed>

　　<gbp：retention-expiry>2010-11-14T20：00：00Z

　　</gbp：retention-expiry>

　　</gp：usage-rules>

　　<gp：method>802.11</gp：method>

　　</gp：geopriv>

　　<dm：deviceID>mac：1234567890ab</dm：deviceID>

　　<dm：timestamp>2010-11-04T20：57：29Z</dm：timestamp>

　　</dm：device>

　　</presence>

　　--boundary1--

　　在數(shù)據(jù)傳輸中，數(shù)據(jù)呈現(xiàn)方式格式是一個新的引入的擴展，通過這個擴展支持了URL MIME外部擴展，這樣的處理方式滿足了SIP數(shù)據(jù)信息體的內容間接訪問，其目的是允許任何SIP信息體中的MIME能夠通過間接方式URL指向一個定位資源。關于對SIP協(xié)議的內容間接訪問的機制讀者可以參考RFC4483。傳輸?shù)臄?shù)據(jù)格式也是非常重要的，PIDF中支持了具體的數(shù)據(jù)呈現(xiàn)格式，關于具體的地址呈現(xiàn)結構和格式（PIDF），讀者可以參考RFC6848。在此規(guī)范控制中規(guī)定了具體城市街區(qū)，門牌號等詳情。

　　大概在15年前IETF已經發(fā)布了關于SIP呼叫中傳輸?shù)乩砦恢玫男薷膮f(xié)議，一些周邊擴展協(xié)議隨之發(fā)布。但是，技術理論永遠是超前的，應用需要結合實際的用戶場景才能逐步展開。當初，很多技術和互聯(lián)網，大數(shù)據(jù)，物聯(lián)網還沒有真正普及，很多國家的網絡仍然處于2-3G。因為環(huán)境的局限，用戶也沒有非常迫切地運用這些定位技術。隨著互聯(lián)網技術的迭代升級，我們已經進入到了5G時代，技術已經比較成熟。另外，國家層面對公共服務領域的投入和重視程度也日益加強，比如，美國FCC和印度政府對電信業(yè)務的強制措施的要求，都要求緊急呼叫必須支持地理位置的信息。以下是美國FCC對E911呼叫支持地理位置信息的法案說明。

　　開源社區(qū)的開放性孕育出很多新的創(chuàng)意。春江水暖鴨先知，很多創(chuàng)新或者客戶需求往往都是從開源開始。Asterisk對Geolocation的支持就是一個比較典型的示例。在最近發(fā)布的Asterisk版本中已經對Geolocation做了支持。關于Asterisk支持Geolocation處理流程如下：

　　Asterisk支持的配置模塊包括：

　　2.1：geoloc_incoming_call_profile // 對應呼入的INVITE請求

　　2.2：geoloc_outgoing_call_profile // 對應呼出的INVITE請求

　　具體的配置和使用Asterisk AMI調用，讀者可以參考asterisk官方開源文檔說明。除了Asterisk以外，思科的CUCM也一直支持地理位置的功能。讀者也可以參考思科的官方網站，這里不再贅述。

　　現(xiàn)在，獲得地理位置信息的方式很多，對于應用集成實現(xiàn)地理信息或者地理坐標信息，以及地圖信息已經不是一個困難的事情。目前我們獲取地理信息主要手段包括：

　　我們現(xiàn)在說的這些手段都需要通過服務接口來獲取地理位置信息，然后和語音或者視頻系統(tǒng)集成來實現(xiàn)地理位置和呼叫的融合。如果通過第三方接口信息支持報警系統(tǒng)或者其他應急指揮系統(tǒng)的話，我們可能考慮一些技術挑戰(zhàn)。首先，這樣的處理方式的優(yōu)勢就是靈活，集成商可以靈活調用各種不同的數(shù)據(jù)。但是，每個服務提供商的數(shù)據(jù)封裝格式可能不同，大家都數(shù)據(jù)格式可能缺乏封裝的統(tǒng)一規(guī)范標準支持。沒有統(tǒng)一的封裝規(guī)范的話，就會造成后續(xù)數(shù)據(jù)服務管理遷移的難度。另外，通過第三方數(shù)據(jù)服務時可能導致地理位置信息的時延和增加響應錯誤管理邏輯的難度。具體來說，如果系統(tǒng)接口獲取信息出現(xiàn)了時延或者因為各種原因，提取地理信息錯誤以后，系統(tǒng)如何和SIP 呼叫的信令保持同步，在緊急報警呼叫中這也是一個比較關鍵的問題。平臺服務人員已經接聽了報警電話，但是，后臺地理位置信息仍然沒有呈現(xiàn)在管理中心的界面上的話，這樣就會產生救援反應不夠及時的問題，可能導致救援失敗。如果使用SIP INVITE支持Geolocation地理位置擴展來進行傳輸?shù)脑�，RFC6442支持了關于獲取地理位置信息路由的管理策略和返回錯誤碼標準機制。通過規(guī)范的處理流程會進一步確保其位置信息和呼叫信令的同步。當然，集成商仍然可以通過服務提供商的響應錯誤進行處理，根據(jù)返回的響應數(shù)據(jù)，集成商開發(fā)出自己的處理邏輯模塊。但是，這些處理流程可能不能形成一個規(guī)范標準，其他第三方也可能沒有辦法實現(xiàn)無縫集成，增加了和其他應用集成的難度和復雜程度。

　　筆者針對通過SIP控制頭geolocation方式實時傳輸?shù)乩砦恢眯畔⒆隽吮容^全面的討論，討論的話題主要包括關于SIP呼叫攜帶地理信息的背景說明，關于業(yè)務場景中使用的各種地理信息的場景需求，在SIP INVITE中指出Geolocation擴展頭和核心RFC方面，關于Asterisk和思科的CUCM中SIP對geolocation的示例說明，以及目前通過第三方接口獲取地理位置同步呼叫時可能面臨的兩個挑戰(zhàn)。

　　在這些討論中，特別是針對如何提升報警效率中關于地理位置獲取做了更多介紹，同時在SIP擴展頭geolocation語法和處理流程通過拓撲圖的方式進行了詳解。另外，筆者針對其他方式獲取地理位置的信息結合呼叫時的同步進行了討論。特別針對數(shù)據(jù)封裝的規(guī)范以及錯誤響應處理的規(guī)范進行了說明。

　　通過以上的討論，筆者希望對目前報警系統(tǒng)的效率優(yōu)化方面進行多角度分析。對呼叫中的地理信息處理，除了通過第三方獲取數(shù)據(jù)以外，可能通過SIP呼叫攜帶地理信息方式也是一個比較創(chuàng)新的方式。當然，創(chuàng)新是有代價的。我們也需要看到問題，目前絕大部分廠家或者應急指揮中心，調度系統(tǒng)等仍然缺乏從技術層面對geolocation 擴展頭的支持，第三方服務商或者語音運營商可能也沒有成熟，如何推進和實際效果都需要時間來驗證。