A session can have multiple RTP sessions corresponding to the UDP ports define in the line of the SDP.
2.一般來說，在會議應用中SIP可以通過請求來讓另一方加入已有會話中。在這種情況下，新的對話會被創建。
3.對話是end-point對end-point的關係，即真實的通信雙方，
而transaction 是hop by hop的關係，即路由過程中交互的雙方。
呼叫（call）： 呼叫是一個非正式的術語，用來表示一個多媒體會話，用Call-ID來標識；不論兩方通話還是在多方通話中，在每個UA中是使用同一個Call-ID；
事務(transaction)： 請求（UAC）+最終響應（相鄰的UAS），SIP基於事務。所謂相鄰就是說transaction存在於相鄰的SIP實體，而不是存在於兩個UA之間。CSeq標識。一個事務中包含一個請求消息、0個或多個臨時響應消息、1個或多個最終響應消息（2xx~6xx）。SIP是事務性的協議。事務的區分通過Via字段棧頂的Branch的值來確定，這是由於對於請求消息每經過一個有事務狀態的Proxy的時候，該Proxy需要爲這個事務創建一個服務器端事務和一個客戶端事務，並且將自己的URI添加到Via的棧頂，並生成一個Global ID做爲Branch的值，以此值來表示一個與之相對應的事務。SIP在事務層面定義了狀態機和定時器來實現重傳。
下圖是一個回覆200 OK的成功的INVITE事務：是不是INVITE事務區別在於 UAC需要爲每個INVITE最終請求（2xx～6xx）生成ACK響應，而其他的請求消息（INFO,OPTION,etc）則不必如此。因爲INVITE的地位比較重要， 所以需要這樣一個三次握手的機制來保證會話的雙方都能夠確保事務的完整性，這一點和TCP連接建立的三次握手比較像。
注意在上圖這兩個UA中，每一個代理服務器都將自己的地址加入返回的ACK的Via頭域中，而非成功的transaction則不會加入，見RFC 3261 (p.24)。CSeq頭域的值必須與INVITE相同，並且CSeq的方法必須是ACK。中間響應消息 1xx 的使用則是爲了節省網絡開銷設計的，一旦 UC 收到任何一箇中間響應消息，則 UC 必須停止消息重發定時器，不再從發這個請求消息，反之則直到收到最終響應消息或重發定時器超時。一旦客戶端UAC的事務在Calling狀態收到任何中間響應消息1xx，事務則自動切換到Processing狀態，停止請求消息的重發。並且需要將中間響應消息傳送給TU事務用戶。在呼叫業務中，TU以及上層應用可以根據中間響應消息在用戶界面上提示用戶。一旦事務切換到Processing狀態，任何其他中間響應消息也都要傳送給TU。
而非INVITE事務則如下：
當UAC發出非INVITE請求時，它就會在事務管理子層上開啓定時器F（TCP）或者是E（UDP），確保超時的時候進行重傳。這適用於除了 ACK請求外的其他非INVITE請求。每次超時重傳時E的時間都被翻倍，直到最大的4秒。而F超時時，UAC就會認爲是Timeout，這個事務將被刪除。
對話(dialog/leg）： 代表着兩個SIP UA之間持續一段時間的端到端的聯繫（如：一段通話）。也就說僅僅存在於端到端的信令關係。當一個UAS發出對於INVITE（或者REFER）的非失敗最終響應<=>200OK（BYE），則Dialog建立，同時這也是session的開始。UA和SIP代理服務器之間不會有對話。在SIP中呼叫中包含一個或多個Dialog（這僅僅存在於多方通話中）。Dialog終結於任意一端發出 BYE。Early Dialog可以通過UAC發出的CANCEL進行終結，更確切的說，所有早期對話在接收到非2XX最終響應時就被終結了。 Call-ID-value、To、From進行標識。Forking時體現明顯。
在這個Forking的例子中，這個用戶註冊了三個設備，在用戶被呼叫時，INVITE的Contact頭域就被轉換爲三個INVITE發往三個設備。後邊的q指的是優先級，q越小，優先級越高。其中的SIP註冊服務器相當於一個Forking代理，儘管這個實體接收到兩個ACK，但是除了這些ACK外，它與主叫方的信令交互都是屬於一個transaction的，而與被叫方則分別建立了Transaction。另外，被叫方收到的兩個ACK由分別建立了Transaction。注意Device3返回了488這樣的非成功響應，SIP註冊服務器（Forking代理服務器）沒有將該響應發回主叫方，這是SIP代理一個重要的特徵，SIP代理還能自行發出Request:CANCEL消息。
UAS對話層接收到一個新的對話請求INVITE消息後，在建立會話的響應消息2xx中，將請求消息裏面的所有Route-Record字段拷貝到2xx消息中，並且UAS的對話層必須添加一個Contact字段使得對話中後續的響應（INVITE在2xx響應的情況下也包括ACK消息）、請求消息可以直接和本UA聯繫。當UAC收到UAS的INVITE的2xx響應消息後，如果2xx中不包含任何Route-Record字段的，則UAC可以選擇直接發送ACK到Contact中地址&端口。
會話(session)： 多方用戶的媒體關係，在對話的控制下建立。
下圖是Early dialog、Session、Dialog、Transaction等的在一個UA-UA的呼叫中的體現：
在這個例子中，通過INVITE事務而成功建立起來的dialog必須有一個ACK進行迴應，這是第二個transaction的開始，儘管ACK並沒有回覆，但是由於新的 branch-value被填入，所以這個ACK代表了一個新的Transaction的開始。注意，此時 transaction number (CSeq) 並沒有根據INVITE而增加--也就是說若收到的最終響應不是2XX（是3XX--6XX），則該transaction中包含ACK，若最終響應是2XX，則ACK屬於一個新的transaction(此處存疑，國外有資料將其視爲一個新的transaction，但是RFC3261中的意思卻是ACK不屬於INVITE Transaction，也不創建新的Transaction，但會重新計算Transaction參數--branchID)。早期對話是UAS以一個1XX響應作爲迴應時建立的。這樣做的好處是在UAC可能在早期對話中發出諸如UPDATE這樣的SIP請求。