Nghiên cứu giao thức thiết lập phiên ( SIP ) ứng dụng cho xây dựng hệ thống dịch vụ IP Centrex

Có thể kể tới SIP-CPL Call Processing Language mô tả kịch bản cuộc gọi với các thẻ XML, SIP-CGI định nghĩa giao diện qua đó các thành phần SIP có thể truyền tham số tới ứng dụng, hay các

LỜI CẢM ƠN

Trước khi đi vào nội dung chính của luận văn, em xin chân thành cảm ơn Tiến sĩ Hoàng Minh, phó giám đốc Học viện Bưu chính Viễn thông, người đã hết sức tạo điều kiện về thời gian và công việc cũng như đã giúp đỡ và hướng dẫn

em rất nhiều trong quá trình thực hiện và hoàn thiện đề tài Em xin chân thành cảm ơn các thày, cô giáo khoa Công nghệ thông tin – Trường Đại học công nghệ

- Đại học Quốc Gia Hà Nội đã chỉ dạy và cung cấp các kiến thức cơ bản trong suốt khóa học Các kiến thức nền tảng này đã giúp em rất nhiều trong việc nghiên cứu và thiết kế các mô hình hệ thống cũng như lập trình các thành phần phần mềm Em xin chân thành cảm ơn các anh lãnh đạo Trung tâm Công nghệ Thông tin CDiT, học viện Công nghệ Bưu chính Viễn thông nơi em công tác, đã tạo điều kiện về công việc để cho em có thêm nhiều thời gian thực hiện nghiên cứu Tôi cũng xin chân thành cảm ơn các anh chị em đồng nghiệp tại Trung tâm Công nghệ Thông tin CDiT và các anh chị tại Công ty cổ phần đầu tư phát triển công nghệ và truyền thông – NEO, những người đã cổ vũ, động viên và giúp đỡ tôi rất nhiều về mặt kỹ thuật trong quá trình thực hiện đề tài nghiên cứu Xin chân thành cảm ơn bạn bè và gia đình đã động viên, giúp đỡ tôi trong suốt quá trình học tập nghiên cứu để thực hiện thành công luận văn tốt nghiệp này

Hà Nội – tháng 11 năm 2006

Đỗ Đức Huy

MỤC LỤC

LỜI CẢM ƠN 1

MỤC LỤC 1

DANH SÁCH HÌNH VẼ 3

BẢNG CÁC TỪ VIẾT TẮT, THUẬT NGỮ 5

MỞ ĐẦU 8

1 Đặt vấn đề 8

2 Phương pháp nghiên cứu 10

3 Nội dung báo cáo 10

Chương 1: TỔNG QUAN VỀ GIAO THỨC SIP 12

1.1 Giới thiệu giao thức 12

1.1.1 Lịch sử phát triển 12

1.1.2 SIP và H323 13

1.1.3 Vai trò của SIP trong mạng viễn thông 15

1.2 Đặc điểm kỹ thuật của giao thức SIP 18

1.2.1 Các đặc điểm kỹ thuật chính 18

1.2.2 Cấu trúc giao thức 30

Chương 2: CÁC VẤN ĐỀ VÀ KHẢO SÁT THỰC NGHIỆM 36

2.1 Một số vấn đề thực tế với SIP 36

2.1.1 Ảnh hưởng của NAT 36

2.1.2 Các giải pháp vượt qua NAT 38

2.1.3 Ảnh hưởng của firewall 42

2.2 Các khảo sát thực nghiệm 43

2.2.1 Các SIP softphone 44

2.2.2 Các SIP server 45

Chương 3: IP CENTREX – MÔ HÌNH VÀ CÁC THÀNH PHẦN 47

3.1 Tổng quan về IP Centrex 47

3.1.1 Khái niệm chung 47

3.1.2 Vị trí và chức năng của IP Centrex trong mạng NGN 52

3.1.3 Cơ hội phát triển ở Việt Nam 58

3.2 Nghiên cứu một số giải pháp về IP Centrex 58

3.2.1 Cấu trúc tổng thể hệ thống IP-Centrex 58

3.2.2 Một số cấu trúc điển hình 59

3.2.3 Phân tích và lựa chọn giải pháp 67

Chương 4: ỨNG DỤNG SIP TRONG HỆ THỐNG IP-CENTREX 70

4.1 Mô hình thiết kế tổng thể hệ thống IP Centrex 70

4.1.1 Mô hình hóa hệ thống 70

4.1.2 Yêu cầu bài toán 73

4.2 Đề xuất giải pháp và mô hình thiết kế tổng thể 74

4.3 Thiết kế chi tiết các module hệ thống 75

4.3.1 Phân hệ mạng 75

4.3.2 Phân hệ media 84

4.3.3 Phân hệ dịch vụ 85

4.3.4 Phân hệ OAM 89

4.3.5 Các dịch vụ của IP-Centrex 90

Chương 5: THỬ NGHIỆM HỆ THỐNG 92

5.1 Mục tiêu thử nghiệm 92

5.2 Mô hình hệ thống thử nghiệm 92

5.3 Nội dung thử nghiệm 92

5.3.1 Dịch vụ Call Forward – Busy 93

5.3.2 Dịch vụ Single-Line Extension 93

5.3.3 Dịch vụ music-on-hold 94

5.4 Kết quả thử nghiệm 94

KẾT LUẬN 95

TÀI LIỆU THAM KHẢO 97

Tài liệu tiếng Anh 97

Địa chỉ các trang WEB 97

DANH SÁCH HÌNH VẼ

Hình 1 Vị trí của SIP trong mô hình NGN 17

Hình 2 Lưu đồ đăng ký vị trí 25

Hình 3 Lưu đồ thiết lập phiên 27

Hình 4 SIP stack 30

Hình 5 Tìm gọi không thành công do NAT timeout 38

Hình 6 Vị trí của STUN server trong hệ thống SIP 39

Hình 7 Lỗi chuyển đổi địa chỉ ngẫu nhiên 41

Hình 8 Mô hình dịch vụ Centrex truyền thống 47

Hình 9 Mô hình hệ thống cung cấp dịch vụ IP-Centrex 49

Hình 10 Vai trò vị trí của IP Centrex trong NGN 56

Hình 11 Cấu trúc tổng thể hệ thống IP Centrex 58

Hình 12 Kiến trúc hệ thống IP Centrex dựa trên chuyển mạch Class 5 60

Hình 13 Cấu trúc hệ thống IP Centrex sử dụng chuyển mạch mềm SoftSwitch 62

Hình 14 Nguyên tắc xử lý cuộc gọi có dịch vụ trong Softswitch 62

Hình 15 Hoạt động của một số dịch vụ dựa trên Softswitch 63

Hình 16 Hướng xử lý cuộc gọi trong mô hình IP Centrex sử dụng Softswitch 63

Hình 17 Giải pháp IP Centrex sử dụng Softswitch của LongBoard 64

Hình 18 Giải pháp IP Centrex sử dụng Softswitch của Convedia 65

Hình 19 Cấu trúc hệ thống IP Centrex sử dụng Call Server 65

Hình 20 Giải pháp IP Centrex của GlobalTech 66

Hình 21 Kiến trúc phát triển dịch vụ trong hệ thống SURPASS của Siemens 67

Hình 22 Mô hình tương tác giữa các tác nhân trong và ngoài IP Centrex 70

Hình 23 Thiết kế tổng thể phần mềm hệ thống IP-Centrex 74

Hình 24 Hướng cuộc gọi trong IP Centrex 75

Hình 25 Cấu trúc phần mềm phân hệ mạng 76

Hình 26 Lưu đồ xử lý client transaction 80

Hình 27 Lưu đồ xử lý server transaction: 81

Hình 28 Thiết kế phần mềm phân hệ media 84

Hình 29 Thiết kế phần mềm phân hệ dịch vụ 85

Hình 30 Mô hình hệ thống 89 Hình 31 Mô hình thử nghiệm IP-Centrex 92

BẢNG CÁC TỪ VIẾT TẮT, THUẬT NGỮ

MMI Man-Machine Interface

URL Uniform Resource Locator

MỞ ĐẦU

1 Đặt vấn đề

Central office exchange service – Centrex – là một hệ thống cung cấp dịch vụ đặt tại phía tổng đài nhằm cung cấp các dịch vụ thoại (như quay số tắt, chặn số gọi, tạm ngừng cuộc gọi…) tương tự như một hệ thống tổng đài PBX Dịch vụ này đã được triển khai từ đầu những năm 1960 với các hệ thống analog và ISDN nhằm cung cấp các đường truyền thuê riêng để tổ chức nên các nhóm thoại riêng biệt cho từng tổ chức đơn vị sử dụng Do

có nhiều lợi ích nên thời gian đầu hệ thống nhận được sự hưởng ứng và phát triển mạnh Nửa cuối những năm 1990, với xuất hiện của công nghệ Voice over IP, chi phí cho các dịch vụ viễn thông giảm đã ảnh hướng lớn đến sự phát triển của các hệ thống Centrex truyền thống Mặt khác, dịch vụ Centrex truyền thống cũng không đáp ứng được những đòi hỏi ngày càng cao của người sử dụng theo xu hướng hội tụ của viễn thông và internet

Sự ra đời của IP Centrex là một hướng tất yếu nhằm thay thế dần cho các hệ thống dịch

vụ truyền thống Thay vì sử dụng công nghệ chuyển mạch kênh PSTN truyền thống, IP Centrex sử dụng IP làm cơ sở truyền dẫn nhằm kết hợp cả mạng thoại và mạng dữ liệu, làm tăng hiệu quả hoạt động của hệ thống và mở rộng mức độ cung cấp dịch vụ từ cục bộ lên mức toàn cầu

Hiện nay, một thành phần ngày càng trở nên thiết yếu và đóng vai trò quan trọng trong IPCentrex đó là giao thức khởi tạo phiên SIP Vốn được thiết kế để phục vụ cho IP phone, nhưng SIP không chỉ đơn giản là một giao thức telephony mà cũng rất phù hợp cho các ứng dụng multimedia, đặc biệt là đối với messaging Các SIP server có thể liên kết với nhau tạo nên môi trường dịch vụ trên phạm vi rộng, có thể phối hợp với các gateway để đạt tới các vùng dịch vụ non-SIP, cũng như có thể cung cấp dịch vụ với các media server, feature server phù hợp Trước kia, trong các hệ thống Centrex truyền thống cũng như với hiện trạng hệ thống mạng viễn thông, người ta chủ yếu sử dụng giao thức H323, việc nghiên cứu ứng dụng SIP còn chưa được chú ý Hiện nay, ngày càng nhiều các hãng danh tiếng trên thế giới như BroadSoft, LongBoard… đã chú trọng đến nghiên cứu SIP để ứng dụng vào các hệ thống của họ, đặc biệt là hệ thống IP Centrex

Các bản tin SIP sử dụng định dạng text rất gần gũi với HTTP Định dạng text cho phép dễ dàng mở rộng nội dung của bản tin, dễ theo dõi hoạt động, cũng như tái sử dụng lại các mô hình đã thành công với HTTP (chẳng hạn mô hình servlets, digest authentication) Tuy nhiên định dạng text cũng gây nhiều khó khăn đối với người phát

triển chưa có nhiều kinh nghiệm, vì sự linh hoạt luôn tỷ lệ nghịch với sự chặt chẽ trong cú pháp

Sự linh hoạt của SIP có được là do tính độc lập của nó Bản thân SIP chỉ định nghĩa các thủ tục để thiết lập các phiên kết nối giữa các cặp SIP client (end-to-end), trong khi hoạt động của dịch vụ cũng như đặc điểm media là tùy thuộc vào client và dựa trên các chuẩn khác (chẳng hạn RTP/RSVP, SDP, audio codecs) Nói cách khác, SIP là một chuẩn

mở

Các chuẩn viễn thông truyền thống thường là rất chi tiết và chặt chẽ, đầy đủ tới tận mức ứng dụng Điều này hạn chế tính mở, tuy nhiên theo các chuyên gia thì đây lại là một trong những lý do mà H.323 sớm chiếm được ưu thế trong thị trường Internet phone Trong khi đó SIP được thiết kế để có thể tồn tại lâu dài, dễ dàng thích nghi và tiến hóa Ví

dụ đơn giản như chẳng hạn sau này xuất hiện một giao thức kiểm soát QoS hiệu quả hơn RSVP, việc bổ sung giao thức mới vào ứng dụng sẽ được thực hiện độc lập với SIP Quan điểm mở của SIP khuyến khích nhà phát triển mạnh dạn chuẩn bị trước các nền tảng cho đầu cuối của họ mà không ngại bị lỗi thời, chẳng hạn như Microsoft đã tích hợp SIP stack vào trong kiến trúc RTC client của hệ điều hành Windows XP, sẵn sàng cho việc phát triển các ứng dụng SIP-based phía người dùng cuối

Hiện nay ở trong nước, khi mà VoIP mới được đưa vào khai thác chưa lâu và đều dựa trên H.323, thì SIP hầu như còn chưa được biết đến Tuy nhiên trên thế giới thị trường SIP hiện đang đạt mức tăng trưởng khoảng 66% với dự báo sẽ đạt 2,2 tỷ USD trong năm nay (số liệu từ IDC, 2003), trong đó phần lớn là từ các doanh nghiệp sử dụng SIP-enabled

IP PBX Các nghiên cứu ứng dụng và mở rộng SIP cũng đã và đang được tiến hành từ hai năm nay, với mục tiêu khuyến khích ứng dụng giao thức này trong nhiều lĩnh vực Có thể

kể tới SIP-CPL (Call Processing Language) mô tả kịch bản cuộc gọi với các thẻ XML, SIP-CGI định nghĩa giao diện qua đó các thành phần SIP có thể truyền tham số tới ứng dụng, hay các chuẩn ứng dụng SIP phía server như SIP Servlet, JAIN SIP và PARLAY

Mô hình ứng dụng SIP có rất nhiều điểm tương đồng với mô hình ứng dụng NGN, đây cũng là lý do mà nhiều hãng đã trình làng các giải pháp NGN với hầu hết các thành phần dựa trên SIP

Nghiên cứu làm chủ giao thức SIP là cần thiết, khi mà hiện nay xu hướng chuyển dịch mạng viễn thông sang NGN đã xuất hiện và trở thành vấn đề thiết thực đối với định hướng phát triển hạ tầng viễn thông Việt Nam Mặc dù SIP chưa phải là một giao thức hoàn chỉnh song SIP cũng đã có được những ứng dụng nhất định, ngoài ra các biến thể của SIP cũng đã góp phần đáng kể trong NGN và việc ứng dụng SIP vào xây dựng hệ

thống IP Centrex là một định hướng cần được nghiên cứu Với đề tài này, tôi hy vọng sẽ đạt được những mục đích sau:

 Nghiên cứu tìm hiểu nội dung và các đặc tính kỹ thuật của giao thức SIP thông qua các RFC và các chuẩn liên quan

 Nghiên cứu mô hình và các thành phần của hệ thống IP Centrex

 Nghiên cứu ứng dụng SIP vào xây dựng hệ thống IP Centrex với một số tính năng cơ bản

2 Phương pháp nghiên cứu

Phần lớn nội dung lý thuyết về SIP sẽ được nghiên cứu từ RFC3261 và các chuẩn liên quan Ngoài ra tôi sẽ tham khảo các diễn đàn viễn thông quốc tế trên Internet để có các thông tin về các hoạt động nghiên cứu phát triển SIP trên thế giới, cũng như các khuyến nghị và kinh nghiệm của các chuyên gia về VoIP/SIP/NGN

Các nội dung và cấu trúc của hệ thống IP Centrex được tham khảo từ những cấu trúc

hệ thống đang được phát triển tại các hãng danh tiếng Từ đó tôi sẽ tổng hợp và đưa ra một mô hình phù hợp ứng dụng các thành quả nghiên cứu về SIP

Về sản phẩm, trước hết tôi sẽ nghiên cứu RFC3261 và các chuẩn liên quan, thử nghiệm một số SIP softphone và SIP server công cộng trên Internet (hoặc open source), sau đó sẽ xây dựng thử một SIP server đơn giản với tính năng hạn chế (đủ để hai đầu cuối gọi được cho nhau) SIP server đơn giản này một mặt sẽ cho phép xác định tính khả thi của đề tài, mặt khác sẽ giúp tôi có được kinh nghiệm thực tế để có thể thiết kế lại SIP server hoàn chỉnh và ứng dụng vào trong mô hình tổng thể của hệ thống IP Centrex

3 Nội dung báo cáo

Dựa theo tên đề tài và đề cương đăng ký, tôi xin được chia báo cáo đề tài ra làm hai phần chính Phần đầu của báo cáo tôi sẽ trình bày những vấn đề cơ bản nhất về giao thức thiết lập phiên SIP, với mục đích giúp cho những người mới bắt đầu có thể hình dung được quá trình phát triển, đặc điểm của giao thức, hoạt động của các thành phần trong giao thức và mối quan hệ giữa chúng (chương 1) Bên cạnh đó, trong phần này tôi cũng xin nêu các vấn đề thực tế nảy sinh trong việc ứng dụng SIP, và các giải pháp do cộng đồng nghiên cứu phát triển SIP đề xuất cùng với kết quả khảo sát một số phần mềm SIP (open-source và free-ware) đã và đang được sử dụng trong thực tế (chương 2) Ngoài ra, theo các góp ý từ các thày hướng dẫn, tôi cũng đã bổ sung các ý kiến liên quan đến việc

so sánh SIP với H.323 của một số chuyên gia nổi tiếng trong lĩnh vực VoIP cũng như những nhận xét chủ quan về vấn đề này

Phần tiếp theo của báo cáo tôi sẽ trình bày một số vấn đề cơ bản về hệ thống IP Centrex và việc ứng dụng các nghiên cứu về SIP để xây dựng mô hình hệ thống IP Centrex sử dụng call server Trong chương 3, tôi xin nêu các khái niệm tổng quan về hệ thống IP Centrex và một số nghiên cứu về các cấu trúc và giải pháp IP Centrex trên thế giới Từ các nghiên cứu đó, tôi sẽ phân tích và lựa chọn một giải pháp để phát triển trong điều kiện thực tiễn của đơn vị và thực tiễn trong nước Tiếp theo trong chương 4, tôi xin trình bày mô hình thiết kế hệ thống IP Centrex theo giải pháp được chọn và thiết kế chi tiết của một số module chính trong hệ thống Phần thử nghiệm một số dịch vụ cơ bản của

hệ thống được tiến hành tại đơn vị nghiên cứu và được trình bày tại chương 5

Ngoài ra, tại phần cuối cùng của báo cáo, tôi xin nêu ra một số kiến nghị và định hướng phát triển tiếp theo của đề tài nhằm tiếp tục bám sát các nghiên cứu trên thế giới và đưa nội dung của đề tài vào thực tiễn mạng lưới

Chương 1: TỔNG QUAN VỀ GIAO THỨC SIP

1.1 Giới thiệu giao thức

1.1.1 Lịch sử phát triển [4,5,8,9]

Từ đầu năm 1996, IETF bắt đầu có các nghiên cứu về SIP Ban đầu giao thức này có tên là SCIP (Simple Conference Invitation Protocol), sau đó đổi tên thành Session Invitation Protocol Đến bản draft thứ ba thì giao thức này được đặt tên lại là Session Initiation Protocol và giữ tên này cho đến nay

Phiên bản chuẩn đầu tiên về SIP (1.0) được IETF công bố đầu năm 1999 dưới dạng RFC2543, còn mới nhất là SIP/2.0 RFC3261[8] được công bố giữa năm 2002

Cha đẻ của SIP là Henning Schulzrinne, thuộc Trường ĐH Columbia (www.cs.columbia.edu) H Schulzrinne là một trong những thành viên đầu tiên của nhóm nghiên cứu IETF MMUSIC, và là tác giả của SCIP Hiện nay, Schulzrinne vẫn là một thành viên tích cực của IETF có nhiều đóng góp trong việc nghiên cứu phát triển SIP Một thành viên khác của IETF đáng được nhắc đến là Jonathan Rosenberg (DynamicSoft) Rosenberg bắt đầu tham gia vào nhóm MMUSIC của IETF từ giữa năm

1998, và đã có rất nhiều nghiên cứu giá trị, đặc biệt là đối với sự ra đời của phiên bản SIP/2.0 Một trong những nguồn tài liệu chính của đề tài này là thư viện của Rosenberg trên Internet (tại địa chỉ www.jdrosen.net/papers)

Sau khi IETF công bố phiên bản SIP/2.0, các nghiên cứu ứng dụng SIP trở nên sôi động hơn với sự nhập cuộc của các đại gia như Microsoft, Cisco Tuy nhiên cho đến nay, các nỗ lực ứng dụng SIP vẫn còn nhiều vấn đề cần tháo gỡ, đặc biệt là ảnh hưởng của NAT và Firewall đối với các gói tin RTP Ngoài ra nội dung trong các chuẩn vẫn còn chưa chính xác và đang được hoàn thiện, chẳng hạn đã tìm được gần 70 lỗi của RFC3261, trong đó mới giải quyết được 2 lỗi

Về các hoạt động nghiên cứu ứng dụng SIP, có thể tham khảo tại các địa chỉ sau:

 SIP Forum (www.sipforum.org): Là một diễn đàn phi lợi nhuận với mục tiêu thúc đẩy ứng dụng SIP trong lĩnh vực truyền thông multimedia/realtime qua Internet và các thiết bị không dây NGN SIP Forum được điều hành bởi DynamicSoft (công ty của Rosenberg), hiện có 32 thành viên là các hãng lớn như Alcatel, Avaya, AT&T, Siemens

 SIP Center (www.sipcenter.com): Website này cung cấp nhiều tài nguyên cho việc phát triển SIP như các softphone, các kịch bản test Đây cũng là khu trưng bày trực tuyến các sản phẩm SIP với các tên tuổi hàng đầu trong lĩnh vực truyền thông

 VoIP Forum (www.voip-forum.com): Đăng các tin tức về VoIP nói chung và SIP nói riêng

Một số website khác có thể tìm thấy các tài nguyên hỗ trợ phát triển SIP như vovida.org (nhiều open source), www.cs.columbia.edu (các SIP server công cộng) Trong đó đáng chú ý nhất là IETF Mailing-list lưu trữ các thảo luận giữa các thành viên trong các nhóm nghiên cứu của IETF (www1.ietf.org/mail-archive/working-groups), ngoài ra trên site này dễ dàng tìm thấy các RFC và các bản draft liên quan đến SIP: [14,15]

 www1.ietf.org/html.charters/sip-charter.html

 www1.ietf.org/html.charters/sipping-charter.html

1.1.2 SIP và H323 [11,12,14,15]

Trong lĩnh vực VoIP hiện nay phổ biến nhất là hai họ giao thức SIP và H.323 H.323

là chuẩn được ITU-T đề xuất và được đưa vào ứng dụng trước Trong khi đó SIP là chuẩn được xây dựng sau (1996) bởi IETF, các ứng dụng của SIP mới bắt đầu xuất hiện gần đây nhưng đã nhanh chóng thu hút được sự quan tâm của nhiều nhà phát triển Trên các diễn đàn VoIP quốc tế cũng đã có nhiều bài viết so sánh hai họ giao thức này, cũng như các tranh cãi giữa hai phe ủng hộ đối với từng giao thức Hầu hết các bài so sánh đều cho thấy

ưu điểm của SIP so với H.323

H.323 là trường hợp điển hình của một giao thức phức tạp, xác định (deterministic)

và đi theo bộ Mô tả về H.323 phân tán trên sáu tài liệu chính, định nghĩa tất cả các component của một mạng voice/video/data: đầu cuối, gateway, gatekeeper, MCUs và các feature server Ngoài ra còn có một số giao thức liên quan như Q.931 (báo hiệu), RAS (giao tiếp đầu cuối và gatekeeper) và H.245 (media codec) Để thực hiện một cuộc gọi thoại đơn giản, tất cả các giao thức này đều phải góp mặt với hàng tá bản tin báo hiệu được gửi qua lại, trong khi SIP chỉ cần 4 bản tin

Lợi thế của H.323 so với SIP chính là sự ra đời sớm hơn Có rất nhiều thư viện cho H.323 stack đã được kiểm thử, và có thể yên tâm mua lại các thư viện này để phát triển dịch vụ Tuy nhiên sự phức tạp của giao thức khiến cho H.323 rất khó khăn trong việc thích ứng với thực tế hiện nay, khi mà sự phát triển của IP network đã vượt ra khỏi những tiên liệu ban đầu của những người thiết kế H.323

Các thử nghiệm của Creative Labs trên H.323 cho thấy khả năng thiết lập cuộc gọi thành công trong các tình huống mất/lỗi gói tin là khá tệ, trong khi đó thực nghiệm cho thấy SIP chỉ gặp vấn đề đối với các tình huống trễ gói tin Các chuyên gia cho rằng nguyên nhân chính là thủ tục báo hiệu kiểu ISDN (Q.931) của H.323 không phù hợp với

IP network

Trong khi đó ý tưởng thiết kế của SIP là rất đơn giản Ban đầu SIP dự định sẽ được sử dụng như một cơ chế để kết nối các đầu cuối vào hội đàm multi-point, cho phép mọi người trong cuộc hội đàm có thể trao đổi ý kiến dưới dạng text đơn thuần Nhưng tác giả của SIP, Henning Schulzrinne, nhanh chóng nhận ra rằng SIP rất phù hợp với IP Telephony Tuy nhiên tôn chỉ của SIP vẫn là duy trì tối đa tính độc lập của giao thức đối với phần media, vì thế sử dụng SIP để thiết lập một cuộc thoại hay một trò chơi multi-player cũng không có gì khác nhau

Sử dụng định dạng text cho các bản tin SIP cũng là một quyết định tinh tế H.323 sử

dụng các bản tin đóng gói theo kiểu packet nhị phân có nhiều ưu điểm dễ thấy như chiếm

băng thông ít hơn (tính trên cùng một đơn vị dữ liệu), phân tích bằng chương trình đơn giản hơn Tuy nhiên, khi thực hành với H.323 có thể nhận thấy những người thiết kế giao thức này đã quá lạm dụng khả năng phân cấp của quy tắc đóng gói BER (Basic Encoding Ruler), khiến cho việc truy xuất vào các trường của bản tin rất phiền phức

Trong khi đó lợi thế của định dạng text là dễ đọc → dễ debug, ngoài ra tính linh hoạt

và khả năng mở rộng của định dạng text là không hạn chế Nhược điểm chiếm nhiều băng thông của định dạng text bị xóa nhòa khi mà trên thực tế các bản tin SIP chỉ có độ dài khoảng vài trăm byte Tuy nhiên việc phân tích các thành phần của bản tin SIP đòi hỏi chương trình cần phải có các thuật toán thông minh hơn so với việc phân tích một cách máy móc gói tin BER mà H.323 sử dụng

Henning Schulzrinne đã có ý đồ tận dụng lại các thuật toán text-parsing khi sử dụng

cú pháp của HTTP 1.1 cho các bản tin SIP Trong một số trường hợp SIP server được nhúng dưới dạng module vào một web server (chẳng hạn Apache) để thừa kế phần phân tích bản tin theo cú pháp HTTP 1.1 Các chuyên gia cũng lưu ý khi áp dụng các module HTTP vào SIP cần đảm bảo có sự hỗ trợ bảng mã UTF-8, và phải tách được lớp vận chuyển (vì HTTP chỉ sử dụng lớp vận chuyển là TCP)

Các chuyên gia đều nhất trí rằng ưu điểm vượt trội của SIP so với H.323 chính là kiến

trúc tích hợp theo hàng ngang, cho phép các giao thức liên quan trong một ứng dụng có

thể "lắp ghép với nhau như trò chơi Lego" (trích lời Schulzrinne) Trong khi đó H.323 có rất nhiều ràng buộc cần tuân thủ, nó mô tả mọi thứ từ media codec cho tới lớp vận chuyển Còn Rosenberg phát biểu: "Về cơ bản, sự thành công của Internet là tách được

các phần dọc (vertical) của ứng dụng thành các module ngang (horizontal), chẳng hạn như tách được lớp vận chuyển ra khỏi dịch vụ"

bị thay đổi ngẫu nhiên trên đường truyền cũng có thể làm sập SIP stack hoặc cập nhật rác vào CSDL Đáng tiếc là những người thiết kế giao thức này quá “chung thủy” với định dạng thuần text của HTTP (trong khi HTTP được thiết kế trên TCP) Nếu như SIP được thiết kế để bổ sung khả năng kiểm tra tính toàn vẹn của bản tin (điều này không khó), thì

sự kết hợp của SIP trên nền UDP sẽ là trọn vẹn

1.1.3 Vai trò của SIP trong mạng viễn thông

Có nhiều tiêu chí để đánh giá tầm quan trọng của một giao thức báo hiệu trong viễn thông Tuy nhiên một giao thức tốt phải là một giao thức hỗ trợ tốt các chức năng báo hiệu, có khả năng thích ứng linh hoạt với sự thay đổi của lớp dịch vụ điều khiển cuộc gọi bên trên và phù hợp với xu hướng phát triển của mạng lưới trong tương lai

Về khả năng hỗ trợ báo hiệu:

 Như đã phân tích ở trên, SIP là một giao thức được phát triển phục vụ cho thoại trên

IP tương tự như H.323 SIP đáp ứng đầy đủ các chức năng thiết lập phiên của một giao thức báo hiệu điều khiển cuộc gọi (đã được phân tích rất rõ trong RFC 3261).[8]

 Ngoài khả năng hỗ trợ VoIP, SIP cũng rất phù hợp với các ứng dụng truyền thông đa phương tiện, đặc biệt là với tin nhắn nhanh vì tính đơn giản của SIP Hiện tại chương trình Messenger của Microsoft đã sử dụng giao thức này

Về khả năng thích ứng:

 SIP có khả năng hỗ trợ các ứng dụng điều khiển cuộc gọi một cách linh hoạt, điều đó

có được là do tính độc lập của nó Bản thân SIP chỉ định nghĩa các thủ tục để thiết lập các phiên kết nối giữa các cặp SIP client (end-to-end), trong khi hoạt động của

dịch vụ cũng như đặc điểm media là tùy thuộc vào client và dựa trên các chuẩn khác (chẳng hạn RTP/RSVP, SDP, audio codecs)

 Các chuẩn viễn thông truyền thống thường là rất chi tiết và chặt chẽ, đầy đủ tới tận mức ứng dụng (Mô hình top-down) Điều này hạn chế tính mở, tuy nhiên theo các chuyên gia thì đây lại là một trong những lý do mà H.323 sớm chiếm được ưu thế trong thị trường Internet phone Trong khi đó SIP được thiết kế để có thể tồn tại lâu dài, dễ dàng thích nghi và tiến hóa (Mô hình bottom-up) Ví dụ đơn giản như chẳng hạn sau này xuất hiện một giao thức kiểm soát QoS hiệu quả hơn RSVP, việc bổ sung giao thức mới vào ứng dụng sẽ được thực hiện độc lập với SIP Quan điểm mở của SIP khuyến khích nhà phát triển mạnh dạn chuẩn bị trước các nền tảng cho đầu cuối của họ mà không ngại bị lỗi thời, chẳng hạn như Microsoft đã tích hợp SIP stack vào trong kiến trúc RTC client của hệ điều hành Windows XP, sẵn sàng cho việc phát triển các ứng dụng SIP-based phía người dùng cuối

Về khả năng phát triển trong tương lai: [4,11,12,14,15]

 Như đã phân tích, dù đều là các giao thức được thiết kế ban đầu để phục vụ cho VoiP, nhưng khác với H.323 Mô hình phát triển ứng dụng trên SIP có rất nhiều điểm tương đồng với mô hình ứng dụng trong NGN Trong NGN, các dịch vụ rất đa dạng và thường hội tụ dưới dạng ứng dụng multimedia nên rất linh hoạt, ví dụ có thể

là ứng dụng thuần thoại như VoiP, hoặc thuần text như SMS hay Instance Message nhưng cũng có thể lại là ứng dụng đa phương tiện như Video Conference… Yêu cầu của NGN chỉ có thể đáp ứng được khi giao thức lớp báo hiệu có đủ độ linh hoạt H.323 không thể đáp ứng điều đó, vì nó là một chuẩn đóng Ngược lại, SIP lại rất dễ thích nghi, đặc biệt là trong trường hợp phối hợp với các giao thức khác Ví dụ, bằng việc bổ sung các bản tin mới (MESSAGE, NOTIFY, INFO) hay sử dụng kết hợp với một giao thức khác (như giao thức mô tả phiên SDP, RFC 2327), SIP có khả năng hỗ trợ nhiều loại ứng dụng khác nhau, tuỳ theo nhu cầu phát triển dịch vụ

Từ những phân tích trên có thể thấy SIP sẽ đóng một vai trò quan trọng đặc biệt khi mạng lõi NGN chuyển sang hoạt động hoàn toàn trên IP (NGN IMS-Based) Các ứng dụng của SIP khi đó sẽ rất phong phú

Hình 1 Vị trí của SIP trong mô hình NGN

Hình trên có thể thấy trong NGN, SIP chiếm một vai trò rất quan trọng Thực thể đầu não trong NGN, Softswitch, hỗ trợ cả SIP và H.323 Tuy nhiên, như đã phân tích ở trên, H.323 chỉ là giải pháp tạm thời trong giai đoạn đầu Trong các pha kế tiếp, SIP hầu như thay thế H.323 trong vai trò giao thức báo hiệu

Có hai mô hình quan trọng phát triển dịch vụ trên SIP như trên hình vẽ:

 Mô hình Service-node: Với mô hình này, các ứng dụng (application server) sẽ giao tiếp trực tiếp với các thực thể điều khiển cuộc gọi (call agent) như Softswitch, SIP Server… bằng giao thức SIP và thực hiện điều khiển các thành phần cung cấp tài nguyên dịch vụ (Media Server, Resource Server…) bằng việc kết hợp với một số giao thức khác

 Mô hình dựa trên OSA: Trong mô hình này, SIP được sử dụng giữa Call Agent và khối OSA để cung cấp giao diện chuẩn mở (Parlay API, JAIN…) Các ứng dụng sẽ điều khiển logic cuộc gọi thông qua việc gọi các hàm chuẩn mà OSA cung cấp Mỗi mô hình đều có các đặc điểm riêng, tuy nhiên đều cho thấy SIP đóng một vai trò quan trọng trong kiến trúc phát triển dịch vụ của NGN Các ứng dụng rất phong phú, có thể kể đến như Messaging, VoiceMail, Video Conference,… và đặc biệt là IP Centrex

1.2 Đặc điểm kỹ thuật của giao thức SIP

1.2.1 Các đặc điểm kỹ thuật chính [8,18,19,20,22]

1.2.1.1 Chức năng và các thành phần

SIP được thiết kế để tạo ra các phiên (session) media giữa các đầu cuối, qua đó các đầu cuối có thể trao đổi các loại hình thông tin khác nhau như âm thanh, hình ảnh, văn bản SIP cung cấp các chức năng cho phép các đầu cuối (SIP client) thỏa thuận các đặc điểm của phiên kết nối đang được thiết lập giữa chúng (như giao thức truyền media, địa chỉ ), sửa đổi các tham số phiên trong quá trình trao đổi, và kết thúc phiên

Cũng giống như các giao thức VoIP khác, SIP được thiết kế để địa chỉ hóa chức năng của báo hiệu và quản lý phiên truyền thông trong một mạng thoại gói Các báo hiệu cho phép các thông tin về cuộc gọi có thể được chuyển tới đầu cuối kia Chức năng quản lý báo hiệu tạo ra khả năng điều khiển thuộc tính cuộc đầu cuối đến đầu cuối

SIP cung cấp các khả năng sau:

 Phát hiện vị trí đầu cuối đích – SIP cung cấp địa chỉ phân tích, ánh xạ tên và chuyển hướng cuộc gọi

 Phát hiện khả năng truyền thông của đầu cuối đích – Thông qua một giao thức mô tả (thường là SDP), SIP quyết định mức thấp nhất của dịch vụ chung giữa các đầu cuối Phiên truyền thông được thiết lập chỉ dựa trên khả năng truyền thông sẵn có của các đầu cuối

 Xác định khả năng sẵn sàng của đầu cuối đích – Một cuộc gọi sẽ không hoàn thành, không thực hiện được vì lý do đầu cuối đích không sẵn sàng cho việc truyền thông SIP quyết định xem liệu cuộc gọi được nối đến có thành công hay không hay không

có trả lời sau khi chuyển một loạt các bản tin Sau đó SIP sẽ gửi bản tin thông báo lý

do của việc đầu cuối đích không sẵn sàng

 Thiết lập phiên truyền thông giữa đầu cuối bắt đầu và đầu cuối đích – Nếu một cuộc gọi có thể hoàn thành thì SIP sẽ khởi tạo một phiên truyền thông giữa các đầu cuối SIP cũng cung cấp chức năng thay đổi cuộc gọi giữa chừng như thêm một đầu cuối vào trong một cuộc gọi hội nghị hay thay đổi thuộc tính truyền dẫn hoặc codec

 Điều khiển việc chuyển tiếp và kết thúc cuộc gọi – SIP cung cấp chức năng chuyển tiếp cuộc gọi từ đầu cuối này đến đầu cuối khác Trong quá trình chuyển tiếp SIP thiết lập một phiên truyền thông đơn giản giữa chuyển tiếp và đầu cuối mới (được

xác định bởi các bên chuyển tiếp) và kết thúc phiên truyền thông giữa người chuyển tiếp và cuộc gọi chuyển tiếp

Để các client có thể tìm được nhau, và hỗ trợ một số chức năng khác, các SIP server

được sử dụng với vị trí tương tự như gatekeeper trong H.323 Các loại SIP server gồm có:

 SIP Proxy server (SPS): Là một chương trình có nhiệm vụ trung chuyển các bản tin SIP giữa các client SPS phiên dịch các bản tin SIP nhận được, sửa đổi (nếu cần) và chuyển tiếp tới địa chỉ phù hợp Để hỗ trợ SPS trong việc quản lý các client, một chương trình hỗ trợ gọi là Location service được sử dụng (còn gọi là Location server, Location database)

 SIP Registrar server: Làm nhiệm vụ xử lý bản tin REGISTER từ các client và cập nhật vào Location service Thủ tục đăng ký này (login) cho phép SIP Proxy server có được thông tin về vị trí và tham số của các client Thông thường Proxy server tích hợp chức năng của Registrar

 SIP Redirect server: Được thiết kế phục vụ cho các đầu cuối di chuyển giữa các SIP domain Redirect server phân tích bản tin INVITE và trả về các địa chỉ tương ứng (không chuyển tiếp bản tin) Một SIP server tích hợp có thể hoạt động ở chế độ proxy, hoặc redirect, hoặc linh động

Ghi chú: Để có thể kết nối với các mạng khác (non-SIP), các SIP gateway được sử dụng Trong giao thức SIP, các gateway có vị trí tương tự như các SIP client (đều gọi là SIP end-point), nên khi nói SIP client đã bao hàm cả SIP gateway

Các đặc điểm của SIP đã được mô tả chi tiết trong RFC3261 và cũng đã có nhiều bài báo phân tích với các nội dung tổng thể đáng lưu ý như sau:

 Bản thân SIP không định nghĩa toàn bộ các thủ tục cần thiết để xây dựng một hệ thống tích hợp, mà được thiết kế dưới dạng component cho phép kết hợp với một số chuẩn khác để tạo thành một kiến trúc hoàn chỉnh Thông thường SIP được dùng kết hợp với SDP (RFC2327) để mô tả phiên, sử dụng RTP (RFC1889) để truyền dữ liệu real-time và điều khiển QoS, và RTSP (RFC2326) để truyền các dữ liệu dạng stream Tuy nhiên hoạt động của SIP là độc lập với các giao thức đó

 SIP không cung cấp một dịch vụ nào cụ thể, mà cung cấp các thủ tục căn bản (primitive) để xây dựng các dịch vụ khác nhau Đặc điểm dịch vụ được thỏa thuận giữa các đầu cuối SIP, thường là dưới dạng SDP Các dịch vụ đơn giản hay đặc thù

có thể được lập trình tại phía người dùng cuối, trong khi các dịch vụ mang tính cộng đồng có thể được thực hiện tại SIP Application Server của nhà cung cấp dịch vụ

 Các đầu cuối SIP được đánh địa chỉ theo kiểu email (username@domain) Sơ đồ địa chỉ dạng E.164 cũng được hỗ trợ (tùy theo chính sách của location service)

 SIP cung cấp một tập các chức năng bảo mật, bao gồm các kỹ thuật chống tấn công dạng DoS, nhận thực client (thừa kế từ HTTP), các kỹ thuật đảm bảo toàn vẹn và an toàn thông tin

 SIP có thể hoạt động trên nền IPv4 hoặc IPv6, sử dụng giao thức lớp vận chuyển là UDP (chủ yếu), TCP hoặc TLS

1.2.1.2 Các bản tin SIP

Hoạt động của SIP dựa trên việc trao đổi các bản tin SIP giữa các thực thể Các bản

tin SIP có thể là các request từ phần tử client (UAC - User Agent Client) gửi tới phần tử server (UAS – User Agent Server), hoặc các đáp ứng trên hướng ngược lại

Cần lưu ý về khái niệm phần tử client và phần tử server khi nghiên cứu RFC3261, chúng khác với SIP client và SIP server SIP client là một chương trình chạy phía người

sử dụng, còn SIP server là một chương trình khác phục vụ cho các SIP client SIP client

và SIP server đều là những thực thể SIP, trong mỗi thực thể SIP sẽ có phần tử client và phần tử server Để tránh hiểu lầm, trong tài liệu này từ đây về sau sẽ quy ước khi khi sử

dụng các thuật ngữ client và server là nói đến các thực thể SIP client và SIP server

Có hai loại bản tin SIP được định nghĩa: bản tin request và bản tin đáp ứng Các bản tin request được phân biệt theo tên (chẳng hạn như INVITE, ACK ), trong khi các bản tin đáp ứng được đánh số (như 100, 401 ) Trong các trao đổi giữa hai thực thể SIP, phần

tử gửi request và nhận đáp ứng gọi là UAC (User Agent Client), còn phần tử nhận request

và gửi trả đáp ứng gọi là UAS (User Agent Server)

Các bản tin SIP có định dạng text, sử dụng tập ký tự UTF-8 Cấu trúc của các bản tin SIP tuân theo RFC2822 (Internet Message Format), tương tự như HTTP Để có cái nhìn trực quan, hãy xem một ví dụ về bản tin INVITE dưới đây:

INVITE sip:huydd@iptel.org SIP/2.0

"INVITE", Request-URI là "sip:huydd@iptel.org", còn SIP-Version là "SIP/2.0" Các

phần này phân tách nhau bởi một dấu cách (space)

Các dòng tiếp theo mô tả các trường header của bản tin SIP, mỗi trường gồm hai phần là tên và giá trị Các phần này này tách nhau bởi dấu hai chấm (":"), hai bên có thể

có các dấu cách Bản tin ví dụ trên có 10 trường header, trong đó trường CSeq được dùng

để phát hiện các bản tin được phát lại

Danh sách các trường header được kết thúc bởi một dòng trống, sau dòng trống này

(phần còn lại của bản tin SIP) gọi là body Độ dài của phần body được xác định bằng giá

trị trường Content-Length, còn ý nghĩa phần body được xác định theo giá trị trường Content-Type (với SIP giá trị này thông thường là "application/sdp") Thông thường chỉ

có bản tin INVITE và đáp ứng 2xx (success) mới có phần body

1.2.1.2.1 Các bản tin request

RFC3261 định nghĩa 6 loại request ứng với các Method sau:

 REGISTER: Client sử dụng request này để khởi đầu thủ tục đăng ký với Registrar server Request-URI trong trường hợp này phải là SIP domain, ví dụ "sip:iptel.org"

Method Request-URI

Danh sách các trường header

Body

 INVITE: Request này được khởi đầu từ một client (chủ gọi), sẽ được chuyển tiếp qua một hoặc một số proxy server để đến được client bị gọi Request-URI trong trường hợp này là địa chỉ SIP của client bị gọi (ví dụ "sip:huydd@iptel.org") hoặc một contact-name mà bị gọi đã đăng ký

 CANCEL: Được sử dụng để hủy bỏ một request chưa kết thúc (chưa nhận được đáp ứng hoàn thành) Ví dụ sau khi gửi bản tin INVITE, trong khi client bị gọi chưa trả lời thì client chủ gọi có thể gửi CANCEL để hủy cuộc gọi Bản tin CANCEL còn

được tạo ra bởi proxy server trong trường hợp gọi forking (nhân bản INVITE tới

nhiều client), khi một client trả lời thì gửi CANCEL đến các client còn lại Một số chú ý khi dùng bản tin CANCEL:

Chỉ nên dùng CANCEL để hủy bỏ INVITE request Các request loại khác sẽ được trả lời ngay lập tức, vì vậy nếu dùng CANCEL dễ gây ra mất đồng bộ (race condition)

Không gửi CANCEL trước khi nhận được ít nhất một đáp ứng 1xx

Số thứ tự trong trường CSeq được lấy từ bản tin INVITE

CANCEL chỉ có ý nghĩa trên từng chặng, không được forward Request-URI của bản tin CANCEL phải trùng với bản tin request cần hủy

Đáp ứng cho CANCEL luôn là 200 (Ok)

 ACK: Bản tin ACK được sử dụng trong những chặng UDP, khi một UAC đã gửi

request và đã nhận được đáp ứng hoàn thành UAC này gửi ACK để báo nhận cho

đáp ứng đã nhận được, thông báo cho UAS đối tác không gửi lại đáp ứng nữa Trường hợp đặc biệt là đối với đáp ứng 200 (Ok) cho bản tin INVITE, thì bản tin ACK có thể được gửi trực tiếp từ đầu cuối tới đầu cuối (không thông qua proxy) Một số chú ý:

Không có đáp ứng cho ACK

Số thứ tự trong trường CSeq được lấy từ bản tin đáp ứng

 BYE: Request này được sử dụng để kết thúc một phiên media đã được kết nối, thường là gửi trực tiếp từ đầu cuối tới đầu cuối chứ không thông qua proxy server

 OPTIONS: Được sử dụng để truy vấn các khả năng của đầu cuối hoặc của proxy server, các khả năng này gồm có các method được hỗ trợ, các kiểu nội dung (content types), các mở rộng, các kiểu mã hóa (codecs)

Trong số các method trên, cần lưu ý CANCEL và ACK là hai trường hợp đặc biệt

Các method khác đều có nhiệm vụ khởi đầu một transaction, trong khi CANCEL và ACK

được gửi trong ngữ cảnh của một transaction đã tồn tại Ngoài ra RFC3261 cũng "phân biệt đối xử" với INVITE Chi tiết về transaction sẽ được trình bày trong các phần sau Các mở rộng của SIP sau này định nghĩa thêm một số method mới: REFER, UPDATE, INFO, MESSAGE, SUBSCRIBE, NOTIFY

1.2.1.2.2 Các bản tin đáp ứng

Các bản tin đáp ứng cũng có cấu trúc tương tự như các bản tin request, chỉ khác ở dòng đầu tiên Trong các đáp ứng, dòng đầu tiên gọi là Status-Line và có cấu trúc gồm 3

phần tách nhau bởi một dấu cách: SIP-Version, Status-Code và Reason-Phrase Ví dụ:

SIP/2.0 404 Not Found

 1xx - Thông báo (provisioning): Thông báo đã nhận được request và đang xử lý

 2xx - Thành công (success): Thông báo request đã được xử lý thành công RFC3261 chỉ định nghĩa một đáp ứng thuộc nhóm này là 200 (Ok)

 3xx - Chuyển hướng (redirect): Thông báo request cần phải thực hiện lại trên hướng khác

 4xx - Lỗi client: Bản tin request tương ứng bị lỗi, hoặc request không được chấp nhận

 5xx - Lỗi server: Thông báo request hợp lệ, nhưng không xử lý được do lỗi tại UAS

 6xx - Lỗi chung

Trong đó các đáp ứng từ 2xx đến 6xx gọi là đáp ứng hoàn thành Trên các chặng

truyền không tin cậy (UDP), các đáp ứng hoàn thành được điều khiển phát lại và cần có ACK, trong khi các đáp ứng 1xx thì không

1.2.1.2.3 Các trường header

Reason-Phrase Status-Code

Hầu hết các thông tin điều khiển của SIP được chứa trong các trường header Thông thường thì mỗi trường header nằm trên một dòng của các bản tin SIP, tuy nhiên nếu dòng quá dài thì cũng được phép tách xuống cho dễ nhìn (áp dụng một số quy tắc mở rộng)

Ví trí tương đối của các trường header trong bản tin SIP là không quan trọng, tuy nhiên một số trường header quan trọng đối với xử lý proxy được khuyến nghị là đưa lên đầu, chẳng hạn như Via, Route, Proxy-Require, Max-Forwards, Proxy-Authorization Giống như trong HTTP, mỗi trường header có cấu trúc gồm phần tên và phần giá trị Giữa hai phần này ngăn cách bởi ký tự hai chấm (":"), xung quanh có thể có các dấu cách hoặc tab Trong phần giá trị có thể có các tham số mở rộng

Phần tên của trường header là một chuỗi ký tự không chứa các ký tự đặc biệt (thông

thường chỉ gồm các chữ cái và dấu gạch nối), không phân biệt chữ hoa hay chữ thường

RFC3261 định nghĩa 46 trường header khác nhau, về sau trong các nghiên cứu mở rộng SIP xuất hiện thêm một số trường header mới Các trường header của SIP là độc lập với HTTP, mặc dù có một số trường trùng tên giữa hai giao thức

Một trường header có thể kèm theo các tham số bằng cách sử dụng dấu chấm phẩy

(";") và cú pháp "param-name[=param-value]", tên tham số không phân biệt hoa -

thường Ví dụ:

Via: SIP/2.0/UDP 10.1.1.1:4540;received=68.44.20.1;rport=9988

Nếu giá trị tham số không bao trong cặp nháy kép, thì khi so sánh cũng không phân biệt chữ hoa - chữ thường Ngoài ra cần lưu ý hai bên ";" và "=" cũng có thể có các dấu cách và/hoặc tab Ý nghĩa giá trị của một trường header cũng như tên và giá trị các tham

số hoàn toàn do trường header đó quy định

Một loại trường header có thể xuất hiện nhiều lần trong bản tin SIP, trong trường hợp này thứ tự của chúng là quan trọng Các header hay xuất hiện nhiều lần gồm có: Via, Record-Route, Route Có thể kết hợp các trường header trùng tên làm một, trong đó các phần giá trị sẽ được nối với nhau bằng dấu phẩy (comma) theo thứ tự xuất hiện

Bốn trường điều khiển nhận thực WWW-Authenticate, Authorization, Authenticate và Proxy-Authorization là các trường hợp cần được xử lý đặc biệt vì chúng

Proxy-có định dạng riêng (sử dụng dấu phẩy để phân tách các tham số)

WWW-Authenticate: Digest realm="iptel.org", nonce="3f3c5db8e0bf5bc34d9cde"

Cuối cùng, tên một số trường header có dạng viết tắt bằng một chữ cái (compact form), ví dụ như "Call-ID" có tên tắt là "i", "Contact" có tên tắt là "m"

1.2.1.3 Các địa chỉ SIP

Các đầu cuối SIP được đánh địa chỉ phục vụ cho việc tìm gọi, dạng địa chỉ (gọi là URL) được quyết định bởi chính sách của Location service, có thể có các dạng sau:

 Dạng sip-URL tên domain đầy đủ: sip: “Do Duc Huy” <huydd@iptel.org>

 Dạng sip-URL hỗ trợ E.164 domain: sip:5742881@hanoigw.vn;user=phone

 Dạng sip-URL tên trực tiếp: sip:huydd@66.128.1.12

 Dạng sip-URL E.164 trực tiếp: sip:5742881@203.162.99.1;user=phone

 Dạng tel-URL chuẩn: tel:+5742881

Ngoài ra nếu SIP client có khả năng messaging và Location service cho phép, các địa chỉ email cũng có thể được sử dụng (mailto:user@domain)

1.2.1.4 Hoạt động

1.2.1.4.1 Đăng ký vị trí (Registration):

Mỗi người sử dụng trên một mạng SIP được khai báo một địa chỉ SIP có dạng giống một địa chỉ mail "user@domain" SIP client đăng ký với registrar server sử dụng địa chỉ SIP đã được khai báo

SIP sẽ tra cứu một dịch vụ như location service, nơi cung cấp địa chỉ liên kết với một domain liên quan

Việc đăng ký sẽ tạo ra các kết nối trong một location service cho một địa chỉ domain

mà liên kết một địa chỉ bản ghi URI với một hoặc nhiều địa chỉ Contact

Để đăng ký, SIP client gửi đi một yêu cầu REGISTER đến registrar server Registrar

là một đầu vào của location service của một domain, đọc và tạo các ánh xạ dựa trên nội dung của bản tin yêu cầu đăng ký REGISTER

Một bản tin REGISTER có thể được dùng để thêm, xóa hoặc làm tươi (refresh) liên kết, nó phải có tối thiểu các trường header sau đây:

 Request-URI: cho biết domain dự định đăng ký

 To: Chứa địa chỉ bản ghi mà việc đăng ký tạo ra

 From: Chứa địa chỉ user đăng ký

 Call-ID: Tất cả các UAC phải sử dụng chung một giá trị trường header Call-ID khi gửi các bản tin đăng ký đến registrar cụ thể

 CSeq: giá trị của trường header CSeq đảm bảo tính hợp lệ của yêu cầu đăng ký Một

UA phải tăng giá trị này thêm một cho mọi bản tin đăng ký với cùng một Call-ID

 Contact: Bản tin yêu cầu đăng ký có thể có hoặc không có trường header Contact Nếu có, các giá trị Contact sẽ được gắn với SIP client để phục vụ cho việc tìm gọi về sau

UAC không phải gửi thêm bất cứ một bản tin yêu cầu đăng ký nào cho đến khi nhận lại bản tin đáp ứng cuối cùng cho bản tin đăng ký trước đó hoặc timeout

Khi nhận được một bản tin yêu cầu đăng ký registrar thực hiện tuần tự những bước sau:

 Kiểm tra Request-URI để quyết định xem liệu nó có thực hiện được việc truy nhập vào kết nối mà đã được chỉ ra trong Request-URI hay không

 Để xác nhận rằng registrar cung cấp các phần mở rộng cần thiết thì registrar cần phải

xử lý trường Required

 Xác nhận UAC Registrar phải quyết định xem liệu user đã được xác nhận có được cấp phép để thay đổi kết nối cho bản ghi địa chỉ hay không

 Registrar trích địa chỉ bản ghi (address-of-record) ra khỏi trường header To

 Registrar kiểm tra xem bản tin đăng ký có hay không có trường header Contact Nếu

là thao tác xóa liên kết (chẳng hạn logout), Contact có thể nhận giá trị "*"

Sau khi việc xử lý hoàn tất nếu thành công thì Registrar sẽ trả về bản tin 200 (Ok), và cập nhật thông tin đăng ký cho Location service

Mỗi client chỉ được đăng ký với một address-of-record (AOR) có dạng

"user@domain", và có thể đăng ký thêm các Contact riêng Nhiều client có thể dùng chung AOR, nhưng các Contact không được trùng nhau Khi thiết lập phiên, có thể đặt AOR hoặc Contact của bị gọi vào vị trí của Request-URI trong bản tin INVITE

1.2.1.4.2 Thiết lập phiên (Invitation)

Một SIP invitation thành công bao gồm 2 yêu cầu: một INVITE theo sau là ACK Bản tin yêu cầu INVITE sẽ yêu cầu đối tượng được gọi tham gia vào một cuộc gọi có liên quan hay khởi tạo một cuộc gọi hai bên Sau khi đối tượng được gọi đồng ý tham gia vào một cuộc gọi với một bản tin đáp ứng, người chủ gọi xác nhận rằng đã nhận được bản tin đáp ứng đó bằng cách gửi đi một bản tin ACK Thông thường bản tin yêu cầu INVITE bao gồm một sự mô tả về phiên truyền thông cung cấp cuộc gọi với đầy đủ thông tin để tham gia vào phiên truyền thông Nếu người được gọi chấp nhận cuộc gọi nó sẽ trả lời bằng một đáp ứng 2xx có mô tả về phiên truyền thông giống như vậy

Hình 3 Lưu đồ thiết lập phiên

Để thiết lập một SIP invitation thì SIP phải thực hiện các thủ tục sau:

 Client gửi bản tin INVITE đến SIP server, các bản tin này có thể được forward bởi proxy đến các UAS Các UAS sẽ liên tục truy vấn xem liệu người được gọi có chấp nhận lời mời hay không Nếu chấp nhận thì nó sẽ trả về bản tin đáp ứng 2xx, nếu không nó sẽ trả lại bản tin đáp ứng 3xx, 4xx, 5xx, 6xx Để gửi được một bản tin yêu

cầu SIP hợp lệ thì tối thiểu bản tin đó phải có các trường header sau: To, From,

Call-ID, CSeq, Max-Fowards và Via

- To: chứa địa chỉ logic của bản tin yêu cầu hoặc là địa chỉ bản ghi của user hay resource của đầu cuối đích, ngoài ra nó có thể có giá trị URI

- From: Xác định địa chỉ của người gửi bản tin yêu cầu Cũng giống như trường header To, nó có thể bao gồm giá trị URI

- Call-ID: Là giá trị duy nhất có vai trò nhóm các bản tin có liên quan lại với nhau Giá trị này phải giống nhau trong tất cả các bản tin yêu cầu và đáp ứng được gửi đi

từ bất kỳ UA trong một dialog Nó cũng nên giống nhau trong mọi bản tin đăng ký

từ một UA

- CSeq: Một trường header CSeq trong một bản tin yêu cầu bao gồm một một chuỗi thập phân và phương thức yêu cầu Chuỗi số phải được trình bày như là một số nguyên không dấu 32 bits Phần phương thức của CSeq phải phù hợp với bản tin yêu cầu

- Max-Forwards: Xác định số chặng tối đa mà bản tin yêu cầu được phép vượt qua trước khi đến đầu cuối đích Thông thường nó có giá trị ban đầu là 70, sau khi qua mỗi chặng thì proxy server sẽ giảm giá trị này đi 1

- Via: chỉ ra giao thức vận chuyển được sử dụng cho transaction và xác định vị trí bản tin đáp ứng được gửi đi Giá trị của trường này chỉ được thêm vào khi giao thức vận chuyển được sử dụng trong chặng tiếp theo được chọn

- Ngoài các trường trên bản tin INVITE nên có thêm các trường: Contact, Allow, Accept, Expires, Subject, Organization và User-Agent

 UAS nhận bản tin yêu cầu từ UAC và tiến hành các thủ tục sau:

- Kiểm tra phương thức của bản tin yêu cầu: UAS phải kiểm tra thông tin về phương thức của bản tin yêu cầu, nếu phương thức đó không được đáp ứng bởi UAS thì nó

sẽ đáp ứng bằng bản tin 405 (Method Not Allowed)

- Duyệt phần header của bản tin yêu cầu: Nếu UAS không hiểu một trường header trong bản tin request thì server sẽ phải bỏ qua nó để tiếp tục xử lý bản tin

- Xử lý nội dung bản tin yêu cầu: UAS phải xử lý nội dung của bản tin và các trường

có liên quan để xác định các phần mở rộng yêu cầu của client Nếu UAS không hiểu được nội dung của bản tin yêu cầu nó sẽ trả về bản tin 415 (Unsupported Media Type) và chỉ ra những kiểu nội dung mà nó có thể hiểu được trong trường header Accept

- Đưa ra những phần mở rộng: Nếu một UAS muốn thêm vào những phần mở rộng trong bản tin đáp ứng thì nó phải thêm trường header Require

- Xử lý bản tin yêu cầu: Việc xử lý bản tin INVITE tại UAS phải tuân thủ theo một số bước Nếu bản tin INVITE có trường header Expires thì UAS sẽ khởi tạo một timer Nếu việc xử lý làm cho timer=0 bản tin yêu cầu bị hết hạn và UAS phải gửi lại đáp ứng 487 (Request Terminated) cho UAC

- Phát bản tin đáp ứng: Nếu bản tin INVITE được chấp nhận thì UAS sẽ trả về bản tin 2xx (success), nếu không thì UAS sẽ gửi bản tin từ chối 3xx, 4xx, 5xx, 6xx

 Client nhận bản tin đáp ứng từ phía server và tiến hành xử lý bản tin đáp ứng Việc

xử lý được tiến hành tùy theo từng loại bản tin Nếu bản tin đáp ứng là 2xx thì client

sẽ gửi trả lại bản tin ACK đến server Nếu không phải là 2xx thì client sẽ phân tích lỗi trong bản tin đáp ứng và cố gắng thử khởi tạo lại lần nữa sau khi đã sửa lỗi

Nếu hệ thống SIP server bao gồm SIP proxy và SIP registrar riêng biệt thì bản tin 407

là cần thiết để đảm bảo nhận dạng đúng chủ gọi Trong trường hợp SIP server tích hợp cả chức năng proxy và registrar (phổ biến) thì có thể bỏ qua bản tin này Đôi khi bản tin 407 còn được sử dụng để nhận thực giữa các proxy với nhau

1.2.1.4.3 Định vị người sử dụng

Một đầu cuối có thể di chuyển giữa các hệ thống cuối khác nhau trong một thời gian Việc địch vị người sử dụng cho phép đăng ký động đối với SIP server Khi SIP server truy vấn về vị trí của đối tượng được gọi từ Location service nó sẽ trả về một danh sách các vị trí có khả năng có mặt callee

1.2.1.5 Các dịch vụ gia tăng

SIP có khả năng cung cấp một số dịch vụ sau:

1.2.1.5.1 Tạm dừng cuộc gọi (Call Hold)

Sau khi phiên media đã được thiết lập, một client (chẳng hạn B) có thể yêu cầu tạm dừng (cắt phiên media), sau đó khôi phục lại phiên Trong thời gian tạm dừng, client B có thể thiết lập một phiên khác tới client C, ngoài ra có thể yêu cầu một media server nối tới

A trong thời gian chờ (ví dụ hold-on-music server)

Kỹ thuật được sử dụng cho dịch vụ này là re-INVITE

1.2.1.5.2 Chuyển cuộc gọi (Call Transfer)

Sau khi phiên media đã được thiết lập, client A có thể yêu cầu client B gọi sang một client C khác Sau khi đã nối với C, B sẽ thông báo thành công cho A Dịch vụ này sử dụng một số bản tin mới như REFER, NOTIFY, 202 (Accepted)

Call Transfer có thể lai với Call Hold để có thêm kịch bản dịch vụ Chẳng hạn sau khi kết nối với A, client B có thể tạm dừng, sau đó kết nối sang C Khi đã kết nối với C, client

B cũng lại tạm dừng, sau đó sẽ hướng dẫn để A kết nối với C

Một kịch bản transfer khác có thể được thực hiện mà không cần phải sử dụng Call Hold, đó là sử dụng bản tin MESSAGE Sau khi kết nối với A, B có thể gửi bản tin

MESSAGE tới yêu cầu C thay thế vị trí C dựa trên thông tin được cung cấp sẽ kết nối tới

A

1.2.1.5.3 Chuyển tiếp cuộc gọi (Call Forwarding)

Một client có thể đăng ký chuyển các cuộc gọi tới nó sang một client khác, hoặc sang mạng khác Các phương thức chuyển tiếp có thể là: chuyển khi bận, chuyển khi không trả lời Kỹ thuật được sử dụng là các bản tin 181 (Call is Being Forwarded) và/hoặc các bản tin 3xx

1.2.1.5.4 Gọi tay ba (3-way Call Conference)

Để thực hiện cuộc gọi hội nghị thì ít nhất một client phải có khả năng trộn media (chẳng hạn B), client này có thể gọi thêm một client thứ ba tham gia vào Client thứ ba cũng có thể chủ động tham gia hội nghị bằng cách kết nối tới B nếu biết các tham số của cuộc gọi Call conference được thực hiện chủ yếu nhờ vào các khả năng của client mà không cần sự hỗ trợ của proxy server, tuy nhiên phía nhà cung cấp dịch vụ cũng có thể đưa ra các media server hỗ trợ conference

1.2.1.5.5 Single Line Extension

Với dịch vụ này, một cuộc gọi có thể ring nhiều client cùng một lúc, và khi một client trả lời thì không CANCEL các client còn lại như trường hợp forking thông thường Các client còn lại vẫn có khả năng answer, khi đó cuộc gọi sẽ trở thành gọi hội nghị Dịch vụ này áp dụng cho thuê bao chủ gọi có khả năng trộn media

Điều khiển logic của thực thể Lớp TU quản lý các TU object theo Call-ID Transaction Quản lý và điều khiển các transaction:

phát lại, gửi sự kiện lên TU

Định dạng và phân tích các bản tin SIP

Transport Xác định các phương thức vận chuyển

các bản tin SIP giữa các thực thể Hình 4 SIP stack

Khái niệm transaction được định nghĩa trong RFC3261 gồm một request đơn và các đáp ứng cho request đó (có thể có 1xx, và ít nhất một đáp ứng hoàn thành?) Thông thường transaction tính cả bản tin ACK, tuy nhiên trong trường hợp request là INVITE và đáp ứng hoàn thành là 2xx (success) thì ACK có thể không được tính vào transaction này RFC3261 phân biệt hai loại transaction là Client Transaction và Server Transaction, tương ứng với hoạt động của UAC và UAS Trong mỗi loại lại phân biệt giữa INVITE transaction và non-INVITE transaction

Lớp transaction quản lý các transaction trong một thực thể SIP Các client transaction được tạo ra theo chỉ thị từ TU, trong khi các server transaction được tạo ra dựa trên các bản tin request nhận được Mỗi transaction hoạt động dưới dạng state-machine, có nhiệm

vụ điều khiển việc phát lại các bản tin và chuyển các bản tin chính (hợp lệ) lên các TU để

xử lý Các sự kiện khác cũng được gửi lên TU để giám sát và đồng bộ

So với phiên bản SIP/1.0, khái niệm transaction trong SIP/2.0 đã được bổ sung nhiều nội dung, trong đó chủ yếu tạo điều kiện thuận lợi cho việc tương ứng (matching) các bản tin với các transaction (sử dụng tham số branch trong trường Via, với giá trị đặc biệt

 Mỗi khi request đi qua một proxy thì proxy đó sẽ chèn thêm một trường Via vào đầu danh sách (Via list) trong bản tin request đó, trường Via này chứa địa chỉ của proxy

 Client bị gọi khi tạo bản tin đáp ứng cần sao chép nguyên xi danh sách Via từ bản tin request, và gửi theo địa chỉ trong trường Via đầu tiên (top-most Via)

 Khi proxy nhận được một đáp ứng, nó loại bỏ trường Via đầu tiên, sau đó forward đáp ứng theo địa chỉ trong Via tiếp theo (lúc này là top-most Via)

Trên thực tế Via list được sử dụng để các stateless proxy cũng có thể hoạt động được Các stateful proxy không nên sử dụng top-most Via để xác định địa chỉ forward đáp ứng,

mà nên lưu lại địa chỉ đã gửi request tới nó để phục vụ cho thao tác này

1.2.2.2.2 Định tuyến request

Trong quá trình thiết lập phiên, thông thường sau khi chủ gọi nhận được đáp ứng khác với 100, các request tiếp theo như CANCEL, ACK, BYE hay re-INVITE sẽ được trao đổi trực tiếp giữa hai client mà không đi qua proxy Khả năng này có được là do trong các đáp ứng non-100 đã có trường Contact chứa địa chỉ của bị gọi Tuy nhiên các

trao đổi vẫn phải đảm bảo nguyên tắc là đáp ứng cho request nào thì phải đi ngược lại vết

mà request đó đã đi qua

Tuy nhiên một số proxy có thể yêu cầu request tiếp theo trong cùng dialog (F2) vẫn đi qua proxy Để làm được điều này, proxy chèn thêm trường Record-Route trong bản tin request trước đó (F1) trước khi forward đi, còn client nhận request sẽ sử dụng các Record-Route này trong đáp ứng cho F1 (không tính 100 Trying) Sau trao đổi này, cả hai client đều có tập route cho request tiếp theo (thứ tự các proxy trong tập route tại mỗi client là ngược nhau)

Chú ý: Tập route có thể nhỏ hơn tập Via, vì không phải proxy nào trên tuyến cũng có nhu

cầu route

Khi một client gửi F2, nó kiểm tra tập route hiện thời Nếu tập route này rỗng thì F2

sẽ có Request-URI là Contact đã nhận được từ trước, và được gửi thẳng cho client phía bên kia theo giá trị trong trường Contact đó Nếu tập route không rỗng, client sẽ lấy route đầu tiên làm Request-URI, các route còn lại để tạo nên các trường Route trong F2, và add thêm một trường Route với giá trị của Contact đã nhận từ trước, sau đó gửi tới địa chỉ trong route đầu tiên

Về phía proxy, khi nhận được F2 có danh sách các trường Route, proxy sẽ kiểm tra Request-URI (nếu không phù hợp sẽ trả lời 400 Bad Request), thay thế Request-URI bằng giá trị của Route đầu tiên, loại bỏ Route này khỏi danh sách và forward F2 tới địa chỉ trong Route đó

Ví dụ một cuộc gọi từ U1 đến U2 qua 4 proxy, trong đó P1, P3 và P4 yêu cầu route:

U1 -> P1 -> P2 -> P3 -> P4 -> U2

Bản tin INVITE đến U2:

INVITE sip:callee@u2.domain.com SIP/2.0

BYE sip:p4.domain.com SIP/2.0

Kỹ thuật nói trên được định nghĩa từ SIP/1.0 (RFC2543), còn gọi là Strict Routing

Đặc điểm của strict routing là khi forward giữa các chặng thì Request-URI phải thay đổi liên tục, và có nhiều ý kiến cho rằng định tuyến như vậy là hơi quá "strict" Vì vậy khi

thiết kế RFC3261 (SIP/2.0), một quy tắc định tuyến mới gọi là Loose Routing đã được

đưa vào, với nguyên tắc căn bản là không thay đổi Request-URI Tuy nhiên để tương thích với version cũ thì Loose Routing cũng khá phức tạp:

Khi một proxy muốn F2 sẽ được gửi qua nó, proxy chèn thêm trường Record-Route trong bản tin F1 với giá trị là địa chỉ của proxy và tham số "lr" (viết tắt của loose routing) Đáp ứng của F1 giữ nguyên các trường Record-Route, để sau trao đổi thì hai bên đều có tập route giống nhau (nhưng thứ tự ngược lại, tất nhiên!)

Khi client tạo F2, nếu thấy route đầu tiên không có tham số "lr" (hoặc tập route rỗng) thì sẽ xử lý theo kiểu strict routing như đã nói ở trên Nếu route đầu tiên là "loose", Request-URI của F2 sẽ là Contact trong bản tin nhận được trước đó, còn các route sẽ được dùng để tạo nên các trường Route, và bản tin F2 sẽ được chuyển đi theo địa chỉ trong route đầu tiên Tuy nhiên client vẫn có thể sử dụng quy tắc của Strict Routing như ở mục trên cũng không sao

Khi một proxy loại loose nhận được F2, nó kiểm tra Request-URI Nếu Request-URI phù hợp với nó (nghĩa là proxy trước đó là strict) thì sẽ thay thế Request-URI bằng giá trị của trường Route cuối cùng, rồi loại bỏ trường Route này Nếu không phù hợp (proxy

trước đó cũng là loose), thì kiểm tra trường Route đầu tiên và loại bỏ nếu phù hợp (nếu trường Route đầu tiên không phù hợp thì đáp ứng 400 và dừng tại đây)

Bây giờ proxy kiểm tra trường Route đầu tiên (next hop), nếu có tham số "lr" thì forward F2 theo địa chỉ trong trường Route đó Nếu không có nghĩa là proxy tiếp theo sẽ

là strict, và cần phải xử lý tương thích như sau: đưa Request-URI xuống thành Route cuối cùng, đưa Route đầu tiên lên làm Request-URI và forward theo địa chỉ của Request-URI mới

Ví dụ một cuộc gọi từ U1 đến U2 qua 4 proxy, trong đó P1, P3 và P4 yêu cầu loose routing:

U1 -> P1 -> P2 -> P3 -> P4 -> U2

Bản tin INVITE đến U2:

INVITE sip:callee@u2.domain.com SIP/2.0

Contact: sip:caller@u1.example.com

Record-Route: <sip:p4.domain.com;lr>

Record-Route: <sip:p3.middle.com;lr>

Record-Route: <sip:p1.example.com;lr>

Giả sử U2 chủ động kết thúc cuộc gọi Khi tạo bản tin BYE, U2 vẫn sử dụng quy tắc

cũ và gửi tới P4 như sau:

BYE sip:p4.domain.com;lr SIP/2.0

BYE sip:caller@u1.example.com SIP/2.0

Route: <sip:p3.middle.com;lr>

Route: <sip:p1.example.com;lr>

P3 nhận thấy Request-URI là không phù hợp với nó, nên giữ nguyên Request-URI và

kiểm tra trường Route đầu tiên (sip:p3.middle.com;lr) Do trường Route đầu tiên phù hợp nên P3 loại bỏ trường Route đó Bây giờ Route đầu tiên sẽ là <sip:p1.example.com;lr>, P3 nhận thấy Route này có tham số "lr" nên forward bản tin BYE theo địa chỉ trong Route

đó (tới P1):

BYE sip:caller@u1.example.com SIP/2.0

Route: <sip:p1.example.com;lr>

P1 nhận thấy Request-URI là không phù hợp với nó, nên giữ nguyên Request-URI và

kiểm tra trường Route đầu tiên (sip:p1.example.com;lr) Do trường Route đầu tiên phù

hợp nên P1 loại bỏ trường Route đó Bây giờ trong bản tin không còn trường Route nào nữa, nên P1 sẽ forward theo địa chỉ trong Request-URI (tới U1):

BYE sip:caller@u1.example.com SIP/2.0

Vì vậy giải pháp được chọn hiện nay là sử dụng chung địa chỉ IP với kỹ thuật NAT (Network Address Translation)

Với NAT, nhiều máy tính trong một mạng LAN có thể sử dụng chung một hoặc một vài địa chỉ IP "thật" để truy nhập Internet Đối với các dịch vụ hướng kết nối như WWW thì NAT không gây ra ảnh hưởng gì, nhưng đối với các dịch vụ sử dụng giao thức phi kết nối như SNMP, TFTP, SIP hay RTP thì các trao đổi end-to-end thường là không hoạt động Trên thực tế NAT đã được sử dụng rộng rãi để truy cập Internet, chẳng hạn như các thuê bao leased-line hay ADSL, vì vậy khi nghiên cứu ứng dụng SIP qua Internet phải tính đến ảnh hưởng này

2.1.1.1 Hoạt động của NAT

Với mục đích sử dụng chung địa chỉ IP, hầu hết các NAT router hoạt động theo phương thức NATP (còn gọi là Full cone NAT), nghĩa là một cặp IP:port thuộc mạng private (LA) sẽ được ánh xạ sang một cổng trên một IP chung Ánh xạ này được hình thành dựa trên gói tin đầu tiên gửi từ LA ra bên ngoài, và được hủy sau một khoảng thời gian timeout không có trao đổi trên ánh xạ này

1965 192.168.0.4:53 34 s

43245 192.168.0.54:1324 112 s

Bảng 1: Ví dụ một bảng ánh xạ NAT

Để sử dụng NAT, các trạm trong mạng private đặt default-gateway là địa chỉ mặt trong của NAT router Khi NAT router nhận được một packet từ mạng private, nó sẽ search địa chỉ nguồn trong bảng địa chỉ ánh xạ và re-send packet sử dụng địa chỉ mà NAT cấp cho địa chỉ private này sau đó NAT sẽ reset lại thời gian timeout của cổng địa chỉ với giá trị mặc định Ví dụ: nếu NATP router có địa chỉ public là 203.162.10.97 và bảng ánh

xạ hiện thời như hình trên, khi nhận được packet từ địa chỉ 192.168.0.4:53 ra một địa chỉ public, địa chỉ nguồn của packet sẽ được thay thế bằng 203.162.10.97:1965 trước khi gửi

Khi không có sự trao đổi thông tin trên một port thì NAT router sẽ giải phóng ánh xạ trên port đó nếu hết thời gian timeout, đối với ánh xạ TCP mặc định là 10 phút, còn đối

với UDP là 60 giây (trong trường hợp của TCP, ánh xạ cũng được giải phóng khi NAT

router phát hiện cờ FIN trong gói tin TCP)

Với đặc điểm hoạt động như trên, một phiên trao đổi giữa hai trạm chỉ có thể thực hiện được nếu thỏa mãn cả 3 điều kiện sau:

 Ít nhất một trong hai trạm có địa chỉ public (ngoài NAT)

 Nếu có một trạm nằm trong NAT, trao đổi phải được khởi đầu từ trạm này

 Thời gian gián đoạn không vượt quá thời gian timeout

Đối với các ứng dụng client-server như WWW thì trạm server thường có địa chỉ public, và các phiên kết nối đều được khởi đầu từ client nên không bị ảnh hưởng của NAT Tuy nhiên các ứng dụng end-to-end như SIP thì vấn đề là nghiêm trọng

2.1.1.2 Ảnh hưởng của NAT đối với SIP

Đối với ứng dụng SIP, cả hai thành phần là báo hiệu và media đều chịu ảnh hưởng của NAT Lý do chính là trên thực tế mặc dù SIP server có địa chỉ public, nhưng các SIP client có thể nằm phía trong NAT Về mặt báo hiệu, khi đăng ký vị trí hay thiết lập cuộc gọi, các bản tin SIP từ chủ gọi có thể đến được SIP server Tuy nhiên việc tìm gọi sẽ không thực hiện được do không thỏa mãn điều kiện thứ hai Ngoài ra, trong quá trình thiết lập và giải phóng cuộc gọi vẫn phải tồn tại giai đoạn hai SIP client trao đổi trực tiếp với

nhau (các bản tin ACK và BYE), mà với điều kiện 1 thì trao đổi này sẽ không thực hiện được

200 Ok Add mapping

REGISTER

Timeout INVITE

INVITE

Add mapping

Stop here

Hình 5 Tìm gọi không thành công do NAT timeout

Về mặt media thì vấn đề còn phức tạp hơn do mỗi client cần sử dụng đến 2 UDP socket, một cho RTP và một cho RTCP Khi thiết lập phiên, địa chỉ RTP của chủ gọi được gửi trong phần body của bản tin INVITE (thường là dưới dạng SDP) Giả sử rằng bị gọi có nhận được bản tin này đi chăng nữa, thì nó cũng không thể tìm tới địa chỉ RTP mà chủ gọi đã chỉ ra

Bên cạnh đó trong phần SDP của bản tin INVITE chỉ có địa chỉ cổng RTP của chủ gọi, và quy ước địa chỉ cổng RTCP là địa chỉ RTP + 1 Nhưng khi qua NAT, các cổng này sẽ được chuyển đổi không liên tiếp nhau, vì vậy phiên media sẽ không thực hiện được

2.1.2 Các giải pháp vƣợt qua NAT

Đối với việc trao đổi các bản tin SIP, có hai vấn đề cần giải quyết:

 Duy trì ánh xạ NAT đối với các client

 Cung cấp được địa chỉ mặt ngoài NAT của client này cho client kia

2.1.2.1 Duy trì ánh xạ NAT

Việc duy trì ánh xạ NAT cho các client là cần thiết đối với đường báo hiệu Có ba phương án thực hiện: một là yêu cầu client gửi keep-alive tới SIP server; hai là SIP server sẽ chủ động gửi keep-alive; ba là SIP server sẽ hạn chế thời gian expire của client

để buộc client đăng ký lại theo chu kỳ Các tín hiệu keep-alive chỉ cần là các bản tin UDP rỗng, gửi theo chu kỳ nhỏ hơn timeout của NAT router là được

 Phương án thứ nhất đơn giản và hiệu quả, ngoài ra có thể hỗ trợ SIP server trong việc phát hiện các client bị lỗi Tuy nhiên khó khăn là không phải client nào cũng hỗ trợ

kỹ thuật này

 Phương án thứ hai đơn giản và có tính chủ động cao, không yêu cầu thay đổi phía client Hạn chế của phương án này là trong trường hợp SIP server bị down thì các đăng ký hiện thời sẽ không khôi phục lại được, ngoài ra có thể chiếm dụng tài nguyên của NAT router nếu như client sử dụng DHCP và hay bị khởi động lại

 Phương án thứ ba có vẻ như trọn vẹn hơn, tuy nhiên khi số lượng thuê bao tăng thì tải của SIP server cho việc đăng ký sẽ rất nặng Hơn nữa việc đăng ký và expire liên tục còn gây rất nhiều khó khăn đối với việc đồng bộ giữa SIP server và Location service

Trước mắt nhóm chúng tôi dự kiến sẽ sử dụng phương án 2

Đối với phần media (RTP/RTCP) thì không cần quan tâm đến việc duy trì ánh xạ NAT, vì các cổng media chỉ tồn tại trong phiên Một khi đã có kết nối RTP/RTCP giữa hai đầu cuối thì các trao đổi trên kết nối này là liên tục

2.1.2.2 Sử dụng STUN để xác định địa chỉ mặt ngoài NAT

STUN (Simple Traversal of UDP through NAT) là một giao thức cho phép một UDP socket phía trong NAT biết được địa chỉ mặt ngoài NAT của nó, sử dụng cơ chế hỏi đáp

Hình 6 Vị trí của STUN server trong hệ thống SIP

Thông thường cấu hình của STUN được biểu diễn như hình trên Một STUN client (STUN client thường được tích hợp cùng SIP client) được nối với một mạng private network, mạng này được nối đến mạng public Internet thông qua NAT STUN server nằm trên mạng public Internet nên đương nhiên là ở bên ngoài NAT Để chắc ăn, thậm chí có thể đặt STUN server trên cùng một máy với SIP server