1、主叫发送SIP INVITE请求，包含初始SDP，经理主叫流程以及中间流程，最终发送到被叫侧的S-CSCF； 2、被叫侧S-CSCF校验服务请求同时触发服务逻辑单元。这里基于用户订阅的多媒体服务情
况，对请求的SDP进行鉴权；
3、S-CSCF根据之前UE注册时的信息，将INVITE请求转发到之前记忆的P-CSCF;
4、如果P-CSCF决定被叫是MPS会话（多媒体优先级会话），P-CSCF获取对话信息并且调用动态策略，将获取的用户信息发送PCRF网元。P-CSCF通过之前UE注册时记忆的UE地址，将INVITE转发至UE；
下述信令截图就是INVITE的消息内容，从这里我们可以看出一些信息：
(1)主叫与被叫遵从电信URI的格式，即用tel方式进行公共用户标识表征，可以看出主叫来电号码是18407404056，被叫电话号码是18407404056；
(2)Call-ID:amCanUH-KnuK3GPdcuGJySgOHl87SpbfCHKujkAGJj3YyIbH22AbyEDy-Rwrym9difa@zteims,Call-ID是为了对同一用户的会话进行标识，因此在对话中同一个用户的请求和响应中，Call-ID是唯一的，另外对于同一用户，该Call-ID也应该是全球唯一的标识符，同时一般Call-ID以一种随机加密的方式（RFC1750）出现，使用该随机加密方式可以保护会话不被非法截获，同时可以减少Call-ID的冲突，一般call-ID是由随机加密序列结合主机名称或者IP地址产生。值得注意的是，在单一多媒体会议中，对于用户发起的对同一实体邀请，可能每次分配的Call-ID都不尽相同。有趣的是，主叫的Call-ID与被叫接收的INVITE信息的Call-ID不一样，主叫Call-ID是终端发起的，因此与终端分配的IP地址有关，被叫Call-ID是被叫所处IMS域S-CSCF发起的，因此打上了被叫域S-CSCF的标签；
(3)Cseq: 1000 INVITE。Cseq对消息处理进行标识和排序。INVITE需要与对应的消息类型保持一致（INVITE）。对于对话外非注册消息的Cseq，可以是设置为任意值。在同一对话内，该值随着消息每传递一次进行+1的增量同步。其中一种设置方式可在初始设置时将其与时间（秒级）关联； (4) Record-Route: ,Record-Route是由P-CSCF插入的，目的是为了使后续的请求(Request)依然能通过该代理进行路由，在请求从主叫路由到被叫所经历的一些代理服务器中，Record-Route是可以被替换或者改写的； (5)
Contact: ;audio;video;+g.3gpp.mid-call;+g.3gpp.srvcc-alerting;+g.3gpp.ps2cs-srvcc-orig-pre-alerting;+g.3gpp.icsi-ref=\l\
Contact里面包含一个SIP URI地址，<>里面包含的就是SIP URI地址以及相应的URI参数，<>之外的是包头参数，而不是URI参数。一般可以认为Contact与Via是对应出现的，Via告诉后续的响应消息（Response）将要发送的地址，而Contact则指示了后续的请求消息（Request）将要发送的地址。除了SIP URI地址这些信息之外，Contact里面还包含了一些支持主叫UE能够支持的特性以及能力；
(6) Via: SIP/2.0/UDP
[2409:8099:0:20::1]:5062;branch=z9hG4bK-*5*01eb3dceecc83856d94btaN0
Via里包含了期望响应消息发送的地址。Branch参数区分了该请求创建的交易。并且在客户端以及服务器端，除了Cancel以及Ack请求，Branch参数被唯一使用。Cancel消息里的Branch参数需要与被Cancel的请求里的Branch参数保持一致。Ack里的Branch参数应该与Invite里的Branch参数； (7) Content-Disposition: session, 这里对用户端（含客户端和服务器）描述了消息实体的类型为session(会话)，如果这一栏丢失，则接收端置为默认设置，如果没有默认设置，则置为render(展示)类型；
(8) P-Called-Party-ID: , 这项报头内容只在被叫中出现，里面包含的信息就是被叫UE的公共用户标识。
(9)Supported: 100rel,precondition,timer。这里可选项100rel的出现可以判定SIP message来自于MGCF，也意味着主叫电话来自于交换域。
(10) Session-Expires: 3600;refresher=uac Min-SE: 90
这两条报头往往需要结合一起来看，Min-SE决定了session在代理服务器或者UE之间最小的更新间隔，意味着代理服务器在处理request时不允许恶意将其修改更低，而
Session-Expire则决定了更新的上限，在该值超时前如果没有收到周期的re-INVITE或者UPDATE消息，则会话认为结束。同时更新是由发起request的一方（uac）来启动；一般可以设置30分钟（1800秒），这是由于认为95%的会话在30小时内就结束了，不过随着新技术的实施，将该值适当拉大也可以接受（详见 RFC4028）。
(11) P-Asserted-Identity: ，该包头域应该与主叫UE发出的P-Preferred-Identity捆绑起来解读。这里涉及了一个trust domain的概念，如果在信任域之间发送，代理服务器收到了P-Preferred-Identity，如果同在可信域之内，该值作为服务器可参考值，可在被插入后续的P-Asserted-Identity包头域中，P-Preferred-Identity值。
Asserted Identity意味着该值已被证实，这个值对于接收端的UE来讲，意味着比From包头域的值更值得信任。Asserted的值出现是为了简化鉴权（防止恶意篡改，更改，重放主叫号码）来电号码而产生，这样在信任域内的不同SIP服务节点转发该值，无需再重新进行该值的修改。但是发送到信任域之外，需要将该值删除或者进行一些私有加密的处理。这两个包头域的取值设置可以是SIP,SIPs URI或者Tel格式，同时对于中间转发的服务器，最多可添加一个SIP或者SIPs URI和最多一个Tel URI；
(12)Feature-Caps: *;+g.3gpp.srvcc;+g.3gpp.mid-call;+g.3gpp.srvcc-alerting, Feature-Caps包头域说明了在SIP信令传送中途径的SIP实体所支持的特性和能力，与Contact包头域的URI里所支持的特性和能力形成对比的是，Contact包头域里的SIP URI表征的SIP实体支持的能力不允许出现在Feature-Caps里面。一个SIP消息中可以包含多个SIP实体所添加的Feature-Caps包头域，采取先到先添的原则，后一个添加得保证都在这些包头域的置顶位置。从这里我们可以解读到在信令消息转发途径的SIP实体会支持SRVCC，mid-call，甚至支持在alerting过程中的SRVCC切换流程；
(13) Accept-Contact:
*;+g.3gpp.icsi-ref=\该包头域是主叫端对被叫端UE所具备的能力偏好要求，在经过一系列的IMS网元后，服务器会参考该包头域所规定内容，依据偏好选择设置，对被叫端进行选择；
5、UE根据自身是否支持主叫端发起媒体流的子集情况，反馈Offer Response消息。SDP消息中表示多媒体对话中一个或者多个媒体信息。该反馈响应发送至P-CSCF
183阶段主要做的语音编解码协商，m=audio 50010 RTP/AVP 104 105，可以看出被叫UE支持的是104、105编码格式，含意如下 a=rtpmap:104 AMR-WB/16000/1
a=fmtp:104 mode-change-capability=2;max-red=0
a=rtpmap:105 telephone-event/16000/1
a=fmtp:105 0-15，这里采用的是AMR宽带语音编码方式，采样率为16000Hz，同时
telephone-event说明了一些支持DTMF信令的情况（双音多频，主要发送号码用的）；