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

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

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

　　今天，作者就這一難題進(jìn)行全面討論。以下視頻中，報(bào)警人需要說明自己的地理位置是正確報(bào)警的關(guān)鍵�？墒�，實(shí)際生活中，我們?nèi)匀徊荒鼙容^好地解決這個(gè)問題。

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

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

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

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

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

　　通過返回的錯(cuò)誤碼對獲取地理信息失敗以后做進(jìn)一步規(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)方式格式是一個(gè)新的引入的擴(kuò)展，通過這個(gè)擴(kuò)展支持了URL MIME外部擴(kuò)展，這樣的處理方式滿足了SIP數(shù)據(jù)信息體的內(nèi)容間接訪問，其目的是允許任何SIP信息體中的MIME能夠通過間接方式URL指向一個(gè)定位資源。關(guān)于對SIP協(xié)議的內(nèi)容間接訪問的機(jī)制讀者可以參考RFC4483。傳輸?shù)臄?shù)據(jù)格式也是非常重要的，PIDF中支持了具體的數(shù)據(jù)呈現(xiàn)格式，關(guān)于具體的地址呈現(xiàn)結(jié)構(gòu)和格式（PIDF），讀者可以參考RFC6848。在此規(guī)范控制中規(guī)定了具體城市街區(qū)，門牌號等詳情。

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

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

　　Asterisk支持的配置模塊包括：

　　2.1：geoloc_incoming_call_profile // 對應(yīng)呼入的INVITE請求

　　2.2：geoloc_outgoing_call_profile // 對應(yīng)呼出的INVITE請求

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

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

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

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

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

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