目前应急指挥和报警，医疗救助，极端环境救援系统已经被广泛在了政府和其他救援机构中。第一时间准确获取到报警人地理位置信息是救援是否成功的关键。在报警流程中，绝大部分的报警人地理位置信息获取方式仍然是依靠传统的方式获取。它首先需要报警人自己报告具体位置。但是，在一些特殊场景中，报警人不能非常明确清晰地报告准确位置，这样就会导致救援效率降低。我们国家最早的应急管理系统是广西南宁市在2002年建立的应急管理系统。以前绝大部分的系统应急指挥呼叫是基于传统PSTN网络环境中部署的，和当前IMS网络呼叫的技术相比，在应急指挥响应，特别是针对语音呼叫报警方面仍然有很多可提升的空间。语音呼叫IP化，IMS部署已经纳入了运营商的技术推进的时间表中，SIP语音呼叫已经逐渐成为主流，利用最新语音技术实现地理位置信息传输（例如，通过SIP扩展头Geolocation实时同步传输地理位置信息）也是一个提升响应速度的非常重要的手段。一些国家也通过法律手段明确了一些特殊场景的呼叫，例如报警，紧急救援的呼叫必须支持呼叫携带地理位置的要求。笔者针对通过SIP控制头geolocation方式实时传输地理位置信息做一些比较全面的讨论，讨论的话题主要包括关于SIP呼叫携带地理信息的背景说明，关于业务场景中使用的各种地理信息的场景需求，在SIP INVITE中指出Geolocation扩展头和核心RFC方面，关于Asterisk和思科的CUCM中SIP对geolocation的示例说明，以及目前通过第三方接口获取地理位置同步呼叫时可能面临的挑战。

　　我们知道，在SIP呼叫中，呼叫可能经过多个实体逻辑的处理，例如通过网关接入，通过SBC接入，或者通过其他第三方服务器的转发，或者VPN等等。这些呼叫经过了多个实体逻辑的处理以后，其呼叫双方的终端可能在同一物理空间（同一层楼或者同一层楼不同办公室房间），也可能在不同的物理地理空间，例如终端双方可能分别处于地理空间的不同城市，也可能是不同国家。在过去20年中，很多呼叫业务形态和客户端需求基本上都是基于基本的呼叫业务，没有对其他新业务有太多的需求。但是，在最近几年，随着应用场景的不断迭代，用户部署环境的变化，这些终端也随之发生了改变，这些改变带来了业务方面的变化，例如终端的移动性带来的数据更新，基于SIP的IOT终端，紧急呼叫业务的支持能力，应急指挥调度系统，以及最近运营商强制要求的STIR/SHAKEN呼叫身份验证等问题。进一步来说，随着呼叫业务部署的形态不断变化， 包括云部署方案的推进，以及语音业务的IP化升级改造，如何能够在终端呼叫的同时能够叠加支持物理空间和地理位置的服务，并且提供相应的用户位置定位（Geolocation）是一个目前运营商或者企业通信解决方案中仍然难以解决的难题。我们的友好领邦印度就有关于相应的TRAI法规，明确要求呼叫支持Geolocation。另外，美国FCC在2019年已经发布了关于E911紧急呼叫业务的地理位置的明确规定。

　　此图例以及以下图例均来自于互联网资源

　　今天，作者就这一难题进行全面讨论。以下视频中，报警人需要说明自己的地理位置是正确报警的关键。可是，实际生活中，我们仍然不能比较好地解决这个问题。

　　首先，我们对SIP用户的地理位置的需求背景做一点简单介绍。在当前很多的业务场景中，需要支持SIP用户的Geolocation功能。当然，除了通过Geolocation扩展头支持地理信息以外，现在很多的支持方式也支持了地理位置的查询，但是需要通过实时服务的应用来实现，集成到SIP应用中。这些方式不是我们本章节讨论的主要内容，我们在后期讨论中会涉及类似内容。现在，我们针对SIP呼叫支持地理位置学习进行讨论，其业务场景包括以下几个典型的场景：

　　以上几种典型的场景中，如果通过SIP 呼叫携带了地理位置信息的话Geolocation，就可以提升应急指挥和报警服务系统的响应速度，确保了位置的准确性。当然，如何对SIP INVITE呼叫中添加对地理位置的消息支持扩展需要其他的技术规范来实现。IETF国际组织，针对SIP INVITE，包括3GPP的呼叫对地理位置的支持定义了多个RFC，例如RFC6442和RFC8787等。在以下内容中，我们分别讨论几个和geolocation 相关的技术规范。在具体讨论geolocation或者地理位置之前，我们首先什么一个大家都比较熟悉的地理概念。

　　在呼叫过程中，我们需要携带呼叫方的具体位置，把呼叫方的具体位置传输到呼叫接收服务器端。因此，我们需要首先大概说明关于位置的标识。笼统地说（笔者不熟悉地理知识，仅简单说明），我们确定一个物体或者实体的位置包括两种方式：1）以国际标准定义的经纬度的方式，通过经纬度来定义具体的地理位置和坐标。2）通过地图文字标识和空间内部具体位置的方式表示的位置，例如，某个国家地区城市的街道来标识，或者建筑物中的第几层第几个房间号码。这两种标识方式都会在我们接下来介绍的规范中和后期介绍的用户场景中使用。在讨论规范前还要说明，我们目前没有一个单独的关于geolocation的官方文档，关于geolocation 的部署使用规范其实涉及了多个RFC规范。在SIP协议中，SIP通过扩展的方式支持了geolocation的传输。具体的规范在RFC6442中有明确规定。此RFC6442定义了如何使用SIP传输地理信息地址到接收方-Location Recipient (LR)的三个SIP扩展头，它们分别是Geolocation， Geolocation-Routing 和 Geolocation-Error，通过这三个扩展头确保地理信息传输的准确性。以下是一个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地理位置传输的方式，例如，现在我们使用的SIP协议就是其规范的其中一种方式。现在，我们看一个比较典型的SIP 中间代理作为B2BUA的处理方式。

　　在以上图例中，SIP中间代理服务器作为一个B2BUA来协同双方UA对定位对象的支持。Alice和Bob可以作为SIP UA发送接收地理信息，LS是一个定位服务器，通过URL来获取Bob的定位对象-location object。关于LS的具体的处理机制，读者可以参考RFC3693。通过B2BUA的话，B2BUA就可以通过自己的管理机制或者其他权限安全机制来处理Alice或者Bob的请求和定位对象。在RFC6442中也针对Geolocation-Error有非常详细的定义，同时，此规范也定义了其他错误码，例如获取定位信息失败等响应，例如424：

　　424 (Bad Location Information)，作为SIP 响应码

　　通过返回的错误码对获取地理信息失败以后做进一步规范处理。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--

　　在数据传输中，数据呈现方式格式是一个新的引入的扩展，通过这个扩展支持了URL MIME外部扩展，这样的处理方式满足了SIP数据信息体的内容间接访问，其目的是允许任何SIP信息体中的MIME能够通过间接方式URL指向一个定位资源。关于对SIP协议的内容间接访问的机制读者可以参考RFC4483。传输的数据格式也是非常重要的，PIDF中支持了具体的数据呈现格式，关于具体的地址呈现结构和格式（PIDF），读者可以参考RFC6848。在此规范控制中规定了具体城市街区，门牌号等详情。

　　大概在15年前IETF已经发布了关于SIP呼叫中传输地理位置的修改协议，一些周边扩展协议随之发布。但是，技术理论永远是超前的，应用需要结合实际的用户场景才能逐步展开。当初，很多技术和互联网，大数据，物联网还没有真正普及，很多国家的网络仍然处于2-3G。因为环境的局限，用户也没有非常迫切地运用这些定位技术。随着互联网技术的迭代升级，我们已经进入到了5G时代，技术已经比较成熟。另外，国家层面对公共服务领域的投入和重视程度也日益加强，比如，美国FCC和印度政府对电信业务的强制措施的要求，都要求紧急呼叫必须支持地理位置的信息。以下是美国FCC对E911呼叫支持地理位置信息的法案说明。

　　开源社区的开放性孕育出很多新的创意。春江水暖鸭先知，很多创新或者客户需求往往都是从开源开始。Asterisk对Geolocation的支持就是一个比较典型的示例。在最近发布的Asterisk版本中已经对Geolocation做了支持。关于Asterisk支持Geolocation处理流程如下：

　　Asterisk支持的配置模块包括：

　　2.1：geoloc_incoming_call_profile // 对应呼入的INVITE请求

　　2.2：geoloc_outgoing_call_profile // 对应呼出的INVITE请求

　　具体的配置和使用Asterisk AMI调用，读者可以参考asterisk官方开源文档说明。除了Asterisk以外，思科的CUCM也一直支持地理位置的功能。读者也可以参考思科的官方网站，这里不再赘述。

　　现在，获得地理位置信息的方式很多，对于应用集成实现地理信息或者地理坐标信息，以及地图信息已经不是一个困难的事情。目前我们获取地理信息主要手段包括：

　　我们现在说的这些手段都需要通过服务接口来获取地理位置信息，然后和语音或者视频系统集成来实现地理位置和呼叫的融合。如果通过第三方接口信息支持报警系统或者其他应急指挥系统的话，我们可能考虑一些技术挑战。首先，这样的处理方式的优势就是灵活，集成商可以灵活调用各种不同的数据。但是，每个服务提供商的数据封装格式可能不同，大家都数据格式可能缺乏封装的统一规范标准支持。没有统一的封装规范的话，就会造成后续数据服务管理迁移的难度。另外，通过第三方数据服务时可能导致地理位置信息的时延和增加响应错误管理逻辑的难度。具体来说，如果系统接口获取信息出现了时延或者因为各种原因，提取地理信息错误以后，系统如何和SIP 呼叫的信令保持同步，在紧急报警呼叫中这也是一个比较关键的问题。平台服务人员已经接听了报警电话，但是，后台地理位置信息仍然没有呈现在管理中心的界面上的话，这样就会产生救援反应不够及时的问题，可能导致救援失败。如果使用SIP INVITE支持Geolocation地理位置扩展来进行传输的话，RFC6442支持了关于获取地理位置信息路由的管理策略和返回错误码标准机制。通过规范的处理流程会进一步确保其位置信息和呼叫信令的同步。当然，集成商仍然可以通过服务提供商的响应错误进行处理，根据返回的响应数据，集成商开发出自己的处理逻辑模块。但是，这些处理流程可能不能形成一个规范标准，其他第三方也可能没有办法实现无缝集成，增加了和其他应用集成的难度和复杂程度。

　　笔者针对通过SIP控制头geolocation方式实时传输地理位置信息做了比较全面的讨论，讨论的话题主要包括关于SIP呼叫携带地理信息的背景说明，关于业务场景中使用的各种地理信息的场景需求，在SIP INVITE中指出Geolocation扩展头和核心RFC方面，关于Asterisk和思科的CUCM中SIP对geolocation的示例说明，以及目前通过第三方接口获取地理位置同步呼叫时可能面临的两个挑战。

　　在这些讨论中，特别是针对如何提升报警效率中关于地理位置获取做了更多介绍，同时在SIP扩展头geolocation语法和处理流程通过拓扑图的方式进行了详解。另外，笔者针对其他方式获取地理位置的信息结合呼叫时的同步进行了讨论。特别针对数据封装的规范以及错误响应处理的规范进行了说明。

　　通过以上的讨论，笔者希望对目前报警系统的效率优化方面进行多角度分析。对呼叫中的地理信息处理，除了通过第三方获取数据以外，可能通过SIP呼叫携带地理信息方式也是一个比较创新的方式。当然，创新是有代价的。我们也需要看到问题，目前绝大部分厂家或者应急指挥中心，调度系统等仍然缺乏从技术层面对geolocation 扩展头的支持，第三方服务商或者语音运营商可能也没有成熟，如何推进和实际效果都需要时间来验证。