在互联网多媒体协议栈中，SIP是一种应用层协议。RFC3261定义了TCP、UDP或TLS传输的用法。有一份扩展文档定义SIP的SCTP的用法。
UDP 传输
使用UDP时，每条SIP请求或应答消息都由一个独立的UDP数据报承载。对于体量特别大的消息体，SIP有一种紧凑的格式，有些头域名可以用单个字符的缩略格式，以此节省空间。
SIP的传输端口可以从可用端口池中选择，也可以使用SIP默认的5060端口。UDP传输没有握手和确认，这意味着携带SIP消息的数据报可以会丢失。然而，UDP的校验和机制让UDP层可以识别并丢弃错误的数据报，保证接收SIP消息的完整性。SIP内置可靠性机制。应答消息发到5060端口，或Via头域中指定的端口。
UDP为UA和服务端提供最简单的传输方式，允许它们在不关心传输层状态的前提下运行。然而，UDP没有拥塞控制。重负荷链路上的丢包会触发重传，这又会加剧丢包，最终可能将链路推入拥塞崩溃。此外，SIP使用UDP只允许传输体量比MTU小的请求(应答也一样)。对于简单的SIP消息，这完全没有问题。然而，对于携带组合包体和大量头域的大容量SIP消息来说，这就是问题了。这时，必须使用TCP传输，因为SIP不支持SIP层的分包。
TCP 传输
TCP提供一种可靠的传输，代价是复杂度的提高和网络的时延。和UDP一样，TCP的是SIP服务端口默认为5060，而源端口是从可用端口池中选择的。
使用TCP传输SIP时，Content-Length头域的作用至关重要，因为它用于查找一条消息的结尾和下一条消息的开头。使用TCP或其它基于流的传输协议时，所有消息都必须携带Content-Length头域，不论是请求还是应答。
为了发送应答消息，服务端使用5060端口(或Via头域中指定的端口)打开一条新的TCP反向连接。发送ACK消息使用与INVITE相同的流，因为它关联SIP会话，ACK发送之后连接被关闭。如果TCP在dialog内关闭，可以在dialog内发起一条新的连接来发起新的请求，比如说发BYE请求来结束媒体会话。
TCP提供可靠传输和拥塞控制。它可以传输任意大小的SIP消息。缺点包括建立连接引入的时延，还有服务端需要在传输层中维持连接的状态。
TLS 传输
SIP可以通过TCP使用TLS对传输内容加密，同时具有额外的身份验证功能。安全SIP URI方案(sips)，即使用TLS传输。SIP协议使用TLS的默认端口是5061。
如果在两个代理服务器之间使用TLS，那么要求每个代理具有允许相互身份验证的证书。但是，如果客户端没有证书，也可以与另一种身份验证机制结合使用TLS，比方说SIP摘要，以达成相互验证身份的目的。
使用TLS传输SIP同时获得加密和身份验证服务的优势。但是，加密与身份验证中对单跳有效。如果SIP请求经过多跳(比如经过一个或多个代理服务器)，那么TLS不适合于端到端的身份验证。SIP代理服务器必须支持TLS，而且很可能用TLS用于长连接。
SCTP 传输
RFC 4168 SIP扩展中定义了SIP中的SCTP (RFC4960)用法，提供了另一种可靠的面向流的传输。与TCP相比，对于SIP这样基于消息交互的协议来说，SCTP具有一定优势。首先，它内置消息分片机制，因此可以在传输层描述SIP消息。使用TCP时，SIP协议必须通过Content-Length计算来提取SIP消息。如果多个SIP事务和dialog共享一条TCP连接，那么排头阻塞问题，会导致缓存区里一些有效的SIP消息不会被读取，而是被重传。由于有消息层的描述，SCTP能够继续把完整的消息转发给应用层，同时只要求重传丢失的消息。注意，只有在多个应用程序通过一条TCP连接进行多路复用时才会出现这种问题。这方面的一个例子是两个信令代理服务器间的TCP连接。对于UA端到代理服务器间的TCP连接来说，这通常不是问题，除非它们之间建立了多个dialog并存。
SCTP还支持多重寻址，因此，如果一对负载均衡的SIP代理服务器中有一台故障了，另一台可以立刻接管，继续接收消息，甚至不需要查询DNS或数据库。