Để hiểu về SIP ta xem xét các ví dụ trao đổi bản tin trong các trường hợp sau:
a. Sự trao đổi bản tin SIP giữa hai đầu cuối SIP
INVITE: Là một bản tin yêu cầu. Bản tin INVITE chứa loại phiên kết
nối, có thể là thoại hoặc cả thoại và video như một kết nối của dịch vụ hội nghị truyền hình.
Bản tin INVITE gồm các trường sau:
INVITE sip:marconi@radio.org SIP/2.0
Via:SIP/2.0/UDP lab.high-Voltage.org:5060;branch=z9hG4bKfw19b Max-Forwards: 70
Dòng đầu tiên chứa địa chỉ (URI) của người được mời. Trường Via chứa địa chỉ của người gọi, port well-known của SIP, branch là chuỗi nhận
dạng phiên trao đổi, bản tin hồi đáp cho bản tin này phải có cùng chuỗi
branch.
180 Ringing: Đây là bản tin đại diện cho bản tin hồi đáp:
SIP/2.0 180 Ringing
Via:SIP/2.0/UDPlab.high-Voltage.org:5060;
branch=z9hG4bKfw19b;received=100.101.102.103
To: G. Marconi <sip:marconi@radio.org>;tag=a53e42
From: Nikola Tesla <sip:n.tesla@high-Voltage.org>;tag=76341 Call-ID: 123456789@lab.high-Voltage.org
CSeq: 1 INVITE
Contact: <sip:marconi@tower.radio.org>
Content-Length: 0
Trường Via có thêm chuỗi received chứa địa chỉ của người nó nhận được bản tin yêu cầu. Trường To và From không hoán đổi lại bởi vì nó chỉ chiều của yêu cầu chứ không phải chiều của bản tin. Ở đây, Tesla là người yêu cầu cuộc gọi và Marconi hồi đáp nên hai trường này vẫn giống với trong bản tin INVITE. Lúc này, Marconi cũng tạo ra một chuỗi tag ngẫu
nhiên duy nhất. Hai chuỗi tag sau trường To và From sẽ giữ nguyên như thế trong suốt cuộc gọi.
200 OK
Khi chấp nhận lời mời cuộc gọi, M. (Marconi) gửi bản tin 200 OK để thông báo cho T. (Tesla).
ACK
Bản tin này khẳng định kết nối đã thiết lập và cho phép chuyển sang giao thức vận chuyển RTP để bắt đầu nói chuyện.
BYE
M. muốn kết thúc cuộc gọi, nó gửi bản tin BYE
200 OK
T. chấp nhận kết thúc cuộc gọi: SIP/2.0 200 OK
Via: SIP/2.0/UDP tower.radio.org:5060;branch=z9hG4bK392kf ;received=200.201.202.203
To: Nikola Tesla <sip:n.tesla@high-Voltage.org>;tag=76341 From: G. Marconi <sip:marconi@radio.org>;tag=a53e42
Call-ID: 123456789@lab.high-Voltage.org CSeq: 1 BYE
Content-Length: 0
b. SIP call có sự tham gia của Proxy server
Trong trường hợp 1: Tesla biết địa chỉ IP của Marconi nên có thể gửi trực tiếp bản tin INVITE tới địa chỉ đó. Điều này không phải lúc nào cũng có được. Trong phiên kết nối này nó là IP này nhưng phiên kết nối khác thì nó có IP khác do dùng DHCP.
SIP dùng địa chỉ giống tên email gọi là URI. SIP URI là tên có thể được phân giải sang địa chỉ IP bằng SIP proxy server và DNS lookup. SIP proxy không thiết lập hay kết thúc phiên kết nối mà nó đứng giữa khi trao
đổi các bản tin SIP, nhận rồi chuyển các bản tin này đi. Ví dụ sau sẽ cho thấy rõ:
Hình 2-12: Cuộc gọi có sự tham gia của Proxy server
Đầu tiên, DNS dò tìm trong miền địa chỉ của H (munich.de), trả về IP của proxy server proxy.munich.de, sau đó, bản tin INVITE được gửi tới IP của proxy.
c. Đăng ký SIP
H. gửi một bản tin yêu cầu đăng ký tới server đăng ký. Server đăng ký dùng thông tin trong yêu cầu này để cập nhật cho dữ liệu của proxy dùng để định tuyến yêu cầu.
Hình 2-13: Quá trình đăng ký với Server đăng ký REGISTER sip:registrar.munich.de SIP/2.0
Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bKus19 Max-Forwards: 70
To: Werner Heisenberg <sip:werner.heisenberg@munich.de> From: Werner Heisenberg <sip:werner.heisenberg@munich.de> ;tag=3431
Call-ID: 23@200.201.202.203 CSeq: 1 REGISTER
Contact: sip:werner.heisenberg@200.201.202.203
Content-Length: 0
Server đăng ký hồi đáp lại bằng bản tin 200 OK