8.4.1用户代理功能要求
从功能上可将用户代理分为两类：电话用户代理和会议用户代理。二者的功能要求并不冲突。前者更强调各种呼叫控制，如能支持呼叫前转、呼叫转交、第三方咨询、呼叫中加入用户以及网状互连、多播和基于MCU的多方会议控制。后者更强调支持多媒体通信。实际上，在电话用户代理上增加多媒体性能并不会增加SIP信令的复杂性，因此以后这两类用户代理可予合并。
用户代理最基本的功能要求是能支持SIP请求和响应的正确发送和接收。在用户端应保持SIP事务的状态，按有限状态机的方式对事务操作进行控制。
用户代理的网络能力必须能支持单播UDP，并应能支持多播UDP和TCP。启动后首先试探绑定SIP端口(5060)，如果其它SIPUA已经使用此端口号，则绑定至其它合适的端口。
如果没有配置和固定的SIP服务器相关联，UA向”所有SIP服务器”于留多播地址(224.0.1.75)发送REGISTER请求，其生存期(ttl)等于1。登记请求发出后，可能会收到来自不同本地服务器的多个响应，UA存储这些地址，用其中之一作为主用服务器，其余的作为备用服务器。
在缺省情况下，UA应首先和本地SIP服务器联系。当该服务器找不到时，可直接和被叫联系。也可以配置成对某些域可以直接通信。
对于人呼叫，UA应向用户显示To、From、组织(Organization）优先级(Priority）和主题(Subject)字段，可转换成更加直观的显示形式，并应指示该呼叫是否已鉴权。
UA应校验To和Request-URI是否正确，应拒绝不是发给本用户的呼叫。应自动接受对已有Call-ID的呼叫邀请，井能在呼叫中改变媒体类型和编码。
UA收到入呼叫后的处理步骤为：
．首先调用用户处理文档。
．该文档可规定拒绝、自动接受或延迟决定如何处理该呼叫。如为延迟决定，则UA应回送lxx响应。
．如果文档未作决定，则UA经用户界面询问用户。有可能此时又来了第二个呼叫，用户可决定接受哪一个呼叫。
．UA 应设置定时间隔。如果用户超时未作决定，UA应将该呼叫记录入文件，向用户发送E-mail，然后回送40（8 请求超时）响应。
对于出呼叫，主叫应能选择呼叫采用多播还是单播分配媒体数据；应能指明当被叫地址(To)扩展成一组地址时，是连接第1个被叫，还是连接所有被叫(Call-Disposition:all)；还应能选择呼叫是否允许前转(Call-Disposition：如not-forward)。
8.4.2重定向服务器功能要求
重定向服务器本身不发送任何SIP请求。收到除CANCEL以外的请求时，服务器回送3xx 响应，告之所有可选的下站地址，也可以拒绝此请求。如果收到CANCEL请求，应回送2xx响应，该响应结束SIP事务。服务器保持整个SIP事务的状态。重定向服务器间可能产生的转发环路由客户自行检测。
8.4.3代理服务器功能要求
代理服务器分为有状态和无状态两类。有状态代理服务器记忆入请求和出请求，无状态代理服务器不记忆任何请求信息。另外，根据是否具有并行分发请求的能力，可将代理服务器分为叉分(forking)和非叉分两类。叉分服务器应有状态记忆功能。接受 TCP连接的代理服务器必须是有状态服务器。
有状态代理服务器的行为相当于一个虚拟UAS/UAC。接收入请求时执行服务器状态机，发送出请求时执行客户状态机。唯一不同之处是，当收到关于INVITE的200响应时，总是往主叫方向（上行方向）前转，而不生成ACK。相应地，收到关于200响应的ACK时，总是向下行方向前转。这时，相当于一个无状态服务器。
无状态代理服务器不能视为虚拟UAC/UAS，它只是简单地将每个收到的请求向下行方向前转，将每个收到的响应向上行方向前转。
为了防止环路，服务器收到请求时必须校核自己的地址是否已在该请求的Via字段中。ToFrom、Call-ID和Contact字段从入请求复制到出请求，Request-URI 可能改变，同时服务器将自身地址作为新的Via字段加入到出请求中。
对于收到的响应，服务器需校核顶端Via字段是否和自身地址相匹配。如不匹配，必须丢弃。
