Trong sự trao đổi các bản tin SIP của hình 2.9, Tesla đã biết địa chỉ IP của Marconi nên có thể gửi thẳng bản tin INVITE tới địa chỉ này. Nhưng đây không phải là trường hợp phổ biến – ý nghĩa của địa chỉ IP không giống như một số điện thoại. Một lý do là địa chỉ IP thường được phân chia động do sự thiếu hụt địa chỉ IP của hệ thống IPv4. Ví dụ, khi một PC quay số tới nhà cung cấp dịch vụ internet (ISP), lúc ấy một địa chỉ IP sẽđược tự động gán cho PC này thông qua DHCP. Địa chỉ IP này nằm trong số những địa chỉ IP khả dụng đã được phân chia cho nhà cung cấp. Trong suốt quá trình của một phiên làm việc, địa chỉ IP không bị thay đổi, nhưng nó khác nhau đối với mỗi phiên quay số vào. Thậm chí đối với kết nối internet luôn hoạt động (always on) nhưđường DSL, một địa chỉ IP khác vẫn có thể được gán lại sau mỗi lần PC khời động.
Cũng vậy, một địa chỉ IP không nhận diện duy nhất một người dùng, nhưng lại nhận diện một nút trên mỗi mạng IP vật lý riêng. Bạn có một địa chỉ IP ở cơ
Nguyễn Đức Hùng- ĐHBKHN 54 quan, một cái khác ở nhà, và một cái khác nữa khi bạn log on từ xa trong lúc đi công tác. Một cách lý tưởng thì sẽ chỉ có một địa chỉđể nhận dạng bạn, bất kể bạn
đang ở đâu. Trong thực tế thì cũng có một giao thức internet hoạt động chính xác như vậy, đó là email. SMTP sử dụng một trạm hoặc hệ thống tên độc lập (một địa chỉ email) không tương ứng với một địa chỉ IP riêng biệt. Điều đó cho phép email
được gửi tới bạn, bất kểđịa chỉ IP của bạn là gì và bất kể bạn đang kết nối internet ở đâu.
Thêm nữa, một yêu cầu (request) được định tuyến sử dụng duy nhất một địa chỉ IP sẽđược gửi đến duy nhất một điểm cuối duy nhất một thiết bị. Kể từ khi giao tiếp chuyển từđặc tính device-to-device sang user-to-user, có nhiều lược đồ địa chỉ
hữu dụng sẽ cho phép một user này gọi tới một user khác, mỗi request có thể được gứi tới chính xác user đích mà không cần biết họ đang sử dụng thiết bị nào, hay là trong trường hợp họ sử dụng nhiều thiết bị.
SIP sử dụng những cái tên giống như hệ thống email để đánh địa chỉ. Lược
đồđịa chỉ là một phần của hệ thống địa chỉ internet được biết đến như là URIs. SIP URIs cũng có thể quản lý, điểu khiển các sốđiện thoại, các thông số truyền, và một số các mục khác nữa. Về bản chất, SIP URI là một tên được phân giải thành một địa chỉ IP bằng cách sử dụng SIP proxy server và tra cứu DNS tại thời điểm cuộc gọi. Hình 2.10 là một ví dụ về cuộc gọi SIP điển hình với một loại SIP sever gọi là “proxy server”:
Nguyễn Đức Hùng- ĐHBKHN 55
Hình 2.9. Báo hiệu với sự có mặt của proxy server
Trong ví dụ này, người gọi là Schroedinger gọi tới Heisenberg có thông qua SIP proxy server. Một SIP proxy hoạt động tương tự như một proxy trong giao thức HTTP và các giao thức Internet khác. SIP proxy không thiết lập hay kết thúc các phiên, nhưng nó giữ vị trí nằm giữa cuộc trao đổi bản tin SIP, nhận bản tin đến và chuyển tiếp chúng. Trong ví dụ này chỉ có một proxy, nhưng trong thực thế có thể
có nhiều proxy trong đường báo hiệu.
SIP bao gồm hai phân loại rộng của URIs: một tương ứng với người dùng user, và một tương ứng với thiết bị hay điểm cuối. Người dùng URI (user URI )
được hiểu là một bản ghi địa chỉ ( AOR –address of record ), một yêu cầu gứi tới một địa chỉ của bản ghi sẽ đòi hỏi phải tra cứu cơ sở dữ liệu, dịch vụ, các thao tác
đặc trưng , kết quả là request đang được gửi đến một hoặc nhiều thiết bị đầu cuối. Một device URI được hiểu là một liên hệ (contact), đặc trưng của nó là không đòi hỏi phải tra cứu cơ sở dữ liệu. Một địa chỉ trong bản ghi URI thường xuyên sử dụng trong trường header của TO và FROM, đây là cách thông thường để liên lạc được với một người và phù hơp cho việc lưu trữ trong sổ địa chỉ và trả lại các cuộc gọi
Nguyễn Đức Hùng- ĐHBKHN 56 nhỡ. Một device URI thường được sử dụng trong trường header của CONTACT và
được liên kết với mỗi người dùng riêng trong một khoảng thời gian ngắn.
Schroedinger không biết chính xác Heisenberg hiện tại đang truy nhập mạng
ởđâu và thiết bị nào họđang sử dụng, vì thế một SIP proxy server sẽđược dùng để định tuyến cho bản tin INVITE. Đầu tiên, một truy vấn DNS về tên miền SIP URI của Heisenberg (munich.de) sẽ được thực hiện. Việc này sẽ trả về địa chỉ IP của proxy server là proxy.munich.de. Và bản tin INVITE sẽđược gửi đến địa chỉ IP đó:
INVITE sip:werner.heisenberg@munich.de SIP/2.0
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a Max-Forwards: 70
To: Heisenberg <sip:werner.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=42 Call-ID: 10@100.101.102.103
CSeq: 1 INVITE
Subject: Where are you exactly?
Contact: <sip:schroed5244@pc33.aol.com> Content-Type: application/sdp
Content-Length: 159 v=0
o=schroed5244 2890844526 2890844526 IN IP4 100.101.102.103 s=Phone Call t=0 0
c=IN IP4 100.101.102.103 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000
Proxy tra cứu SIP URI trong Request-URI (Sip: (adsbygoogle = window.adsbygoogle || []).push({});
werner.heisenberg@munich.de) trong cơ sở dữ liệu của nó và định vị được Heisenberg. Việc này được hoàn thành bởi quá trình hai bước:
1.User agent tra cứu DNS để xác định địa chỉ IP của proxy; proxy tra cứu trong cơ sở dữ liệu đểđịnh địa chỉ IP;
Nguyễn Đức Hùng- ĐHBKHN 57 2.Gói tin Invite sau đó được chuyển tiếp tới địa chỉ IP của Heisenberg với sự
bổ xung trường header Via thứ hai được dán nhãn với địa chỉ IP của proxy:
INVITE sip:werner.heisenberg@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK83842.1 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a Max-Forwards: 69
To: Heisenberg <sip:werner.heisenberg@munich.de>
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=42 Call-ID: 10@100.101.102.103
CSeq: 1 INVITE
Contact: <sip:schroed5244@pc33.aol.com> Content-Type: application/sdp Content-Length: 159 v=0 o=schroed5244 2890844526 2890844526 IN IP4 100.101.102.103 s=Phone Call c=IN IP4 100.101.102.103 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
Thông qua hai trường Via header mà Heisenberg biết được bản tin INVITE
đã được định tuyến qua một proxy server. Khi nhận được bản tin INVITE, bản tin phúc đáp 180 Ringing sẽđược Heisenberg gửi tới cho proxy server:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK83842.1 ;received=100.101.102.105
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a To: Heisenberg <sip:werner.heisenberg@munich.de>;tag=314159
Nguyễn Đức Hùng- ĐHBKHN 58
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=42 Call-ID: 10@100.101.102.103
CSeq: 1 INVITE
Contact: <sip:werner.heisenberg@200.201.202.203> Content-Length: 0
Bản tin phúc đáp này cũng bao gồm các trường Via header, To, From, Call- ID, và trường Cseq header từ bản tin INVITE request. Bản tin này sau đó được gửi tới địa chỉ cùng với số port có trong trường Via header đầu tiên, proxy.munich.de: số port, trong trương hợp này là port 5060. Chú ý rằng trường To header bây giờ được gán một thẻ (tag) để nhận dạng một cuộc thoại riêng biệt. Chỉ có trường Via header đầu tiên là có một thông số received, kể từ trường Via header thứ hai sẽ có
địa chỉ IP có ý nghĩa trong URI. Trường Contact header sẽ có device URI của Heisenberg.
Proxy nhận được đáp ứng 180 Ringing từ Heisenberg, nó sẽ kiểm tra trường Via header đầu tiên có địa chỉ của nó (proxy.munich.de), sử dụng số nhận dạng giao tác (một giao tác là một đơn vị công việc riêng lẻ) trong trường Via header, sau đó loại bỏ trường Via header đó rồi chuyển tiếp bản tin phúc đáp đó tới địa chỉ có trong trường Via header tiếp theo: địa chỉ IP 100.101.102.103, số port 5060. Kết quả là bản tin phúc đáp được proxy gửi tới Schroedinger có dạng như sau:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a To: Heisenberg <sip:werner.heisenberg@munich.de>;tag=314159 From: E. Schroedinger <sip:schroed5244@aol.com>;tag=42 Call-ID: 10@100.101.102.103
CSeq: 1 INVITE
Contact: <sip:werner.heisenberg@200.201.202.203> Content-Length: 0
Sử dụng các trường Via header trong việc định tuyến và chuyển tiếp các bản tin SIP giúp giảm bớt sự phức tạp. Để định tuyến được bản tin request, đòi hỏi proxy phải tra cứu cơ sở dữ liệu của nó. Bản tin phúc đáp không đòi hỏi như vậy,
Nguyễn Đức Hùng- ĐHBKHN 59 bởi vì việc định tuyến đã được nhúng kết trong bản tin nhờ trường Via header. Điều này cũng đảm bảo bản tin đáp ứng được định tuyến ngược trở lại thông qua một tập các proxy giống như bản tin request. Cuộc gọi được chấp nhận khi Heisenberg gửi
đi đáp ứng 200 OK:
SIP/2.0 200 OK (adsbygoogle = window.adsbygoogle || []).push({});
Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK83842.1 ;received=100.101.102.105
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a To: Heisenberg <sip:werner.heisenberg@munich.de>;tag=314159 From: E. Schroedinger <sip:schroed5244@aol.com>;tag=42 Call-ID: 10@100.101.102.103 CSeq: 1 INVITE Contact: <sip:werner.heisenberg@200.201.202.203> Content-Type: application/sdp Content-Length: 159 v=0 o=heisenberg 2890844526 2890844526 IN IP4 200.201.202.203 s=Phone Call c=IN IP4 200.201.202.203 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
Proxy giúp chuyển tiếp bản tin 200 OK tới Schoedinger sau khi đã loại bỏ
trường Via header đầu tiên:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a To: Heisenberg <sip:werner.heisenberg@munich.de>;tag=314159
Nguyễn Đức Hùng- ĐHBKHN 60
From: E. Schroedinger <sip:schroed5244@aol.com>;tag=42 Call-ID: 10@100.101.102.103 CSeq: 1 INVITE Contact: <sip:werner.heisenberg@200.201.202.203> Content-Type: application/sdp Content-Length: 159 v=0 o=heisenberg 2890844526 2890844526 IN IP4 200.201.202.203 c=IN IP4 200.201.202.203 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000
Sự có mặt của trường Contact header với địa chỉ SIP URI của Heisenberg trong bản tin 200 OK cho phép Schoedinger có thể gửi bản tin xác nhận ACK thẳng tới Heisenberg mà không cần thông qua proxy (Chú ý rằng Request-URI được thiết lập cho Contact URI của Heisenberg và không phải là URI trong trường To header). Request này và tất cả các request khác sau đó sẽ tiếp tục sử dụng thẻ tag có trong trường To header:
ACK sip:werner.heisenberg@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKka42 Max-Forwards: 70
To: Heisenberg <sip:werner.heisenberg@munich.de>;tag=314159 From: E. Schroedinger <sip:schroed5244@aol.com>;tag=42 Call-ID: 10@100.101.102.103
CSeq: 1 ACK Content-Length: 0
Điều này cho thấy proxy server không thực sự hiện diện trong cuộc gọi (not really “in the call”). Nó chỉ giúp cho thuận tiện trong việc xác định các điểm cuối và liên kết giữa các điểm cuối đó với nhau, và ta có thể loại bỏ vai trò của nó trong
Nguyễn Đức Hùng- ĐHBKHN 61 đường báo hiệu ngay sau khi nó không còn đóng góp gì trong cuộc trao đổi. Một proxy server có thể điều khiển việc trao đổi gửi qua nó bằng cách chèn vào một trường Record-Route header. Thêm nữa, thậm chí một proxy server có thể không thu được thông tin gì về cuộc gọi, về việc đã có một phiên được thiết lập giữa Schoedinger và Heisenberg. Chú ý rằng các thiết bị luôn luôn giao tiếp có tính chất end-to-end, không thông qua proxy.
Trong SIP, đường đi của các bản tin báo hiệu là hoàn toàn độc lập với đường
đi của thông tin. Điều này cũng giống như là sự chia tách giữa kênh điều khiển và kênh mang trong dịch vụ thoại.
Phiên truyền thông được gọi là kết thúc khi Heisenberg gửi bản tin BYE:
BYE sip:schroed5244@pc33.aol.com SIP/2.0
Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bK4332 Max-Forwards: 70
To: E. Schroedinger <sip:schroed5244@aol.com>;tag=42
From: Heisenberg <sip:werner.heisenberg@munich.de>;tag=314159 Call-ID: 10@100.101.102.103
CSeq: 2000 BYE Content-Length: 0
Chú ý rằng CSeq của Heisenberg đã được khởi tạo tới 2000. Mỗi một thiết bị
SIP tự quản lý và duy trì một khoảng hợp lệ số Cseq của riêng nó. Request-URI
được thiết lập cho Contact URI của Schoedinger. Schoedinger xác thực với bản tin phúc đáp 200 OK:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bK4332 To: E. Schroedinger <sip:schroed5244@aol.com>;tag=42
From: Heisenberg <sip:werner.heisenberg@munich.de>;tag=314159 Call-ID: 10@100.101.102.103
Nguyễn Đức Hùng- ĐHBKHN 62 Trong ví dụ trên, câu hỏi chưa được đem ra thảo luận là làm cách nào cơ sở (adsbygoogle = window.adsbygoogle || []).push({});
dữ liệu được truy nhập bởi proxy lại chứa địa chỉ IP hiện thời của Heisenberg. Có rất nhiều cách để làm được điều này nhờ sử dụng SIP hay các giao thức khác. Trong
đó, cơ chế sử dụng SIP được gọi là Registration và sẽ được thảo luận trong phần tiếp theo.