一个代理服务器可以同时向N个地方发送INVITE请求。这种并发寻找就是传说中的分流（forking）。
端到端的媒体包和SIP信号控制包通过不同的通讯路径来发送。
改变媒体会话属性。这个可以通过发送一个包含新媒体属性描述的re-INVITE请求来完成。这个re-INVITE是捆绑在一个现有的会话的，这样参与会话的对方可以明白这是要改变现有的会话属性而不是新建立一个会话。对方收到这个re-INVITE请求后，会发送一个200（OK）应答表示接受这个改变。请求方通过一个ACK来表示接受了对方的这个200(OK)应答。如果对方不同意这个媒体属性变化，他会发送一个错误的应答比如488（暂时不能进行），这个也会收到发起者的一个ACK响应。不管怎样，就是是re-INVITE的失败也不会影响到现有的会话－原有的会话还可以用上次的媒体会话属性继续。
如果代理服务器希望在INVITE之后继续保持SIP消息流，他会在INVITE中增加一个头域（Record-Route）包含一个URI指向这个代理服务器的hostname或者IP地址。这个消息会在会话中一直保存。这样代理服务器就可以继续接收和转发ACK,BYE,给BYE的200（OK）应答。每一个代理都可以单独决定是否接收INVITE以后的后续消息，并且这些后续消息都可以被发送到那些决定接收后续消息的代理服务器。这种情况通常发生在提供mid-call业务的代理服务器上。
SIP/2.0允许6类应答：
1xx：临时应答－请求已经接收，正在处理这个请求。
2xx：成功处理－请求已经成功接收，并且正确处理了这个请求。
3xx：重定向－还需要附加的操作才能完成这个请求，本请求转发到其他的服务器上处理。
4xx：客户端错误－－请求包含错误的格式或者不能在这个服务器上完成。
5xx：服务器错误－服务器不能正确的处理这个显然合法的请求。
6xx：全局错误－请求不能被任何服务器处理。