2 BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI LUẬN VĂN THẠC SỸ KHOA HỌC LẬP TRÌNH SIP CHO THIẾT BỊ DI ĐỘNG BẰNG JAVA NGÀNH : XỬ LÝ THÔNG TIN VÀ TRUYỀN THÔNG MÃ SỐ: MỤC LỤC Trang Trang Lời cam đoan Mục lục Danh mục chữ viết tắt Danh mục hình vẽ MỞ ĐẦU 10 Chương – GIAO THỨC ĐIỀU KHIỂN PHIÊN (SIP) 11 1.1 Khái niệm 11 1.2 Các đặc điểm SIP 11 1.3 Các phần tử mạng SIP 12 1.3.1 User agent (UA) 12 1.3.2 Proxy Server 12 1.3.2.1 Proxy server không trạng thái 12 1.3.2.2 Proxy server trạng thái 13 1.3.3 Registrar server 13 1.3.4 Redirect server 13 1.4 Các tin SIP TRẦN XUÂN THẢO Người hướng dẫn khoa học: TS HÀ QUỐC TRUNG 1.4.1 Các tin yêu cầu 14 1.4.2 Các tin phúc đáp 17 1.5 Các giao dịch SIP 19 1.6 Các hội thoại SIP 20 1.6.1 Các hội thoại làm cho định tuyến thuận tiện 21 1.6.2 Nhận dạng hội thoại 22 1.7 Những kịch SIP điển hình HÀ NỘI 2015 14 23 1.7.1 Đăng ký 1.7.2 Khởi tạo phiên 23 23 1.7.3 Kết thúc phiên 24 1.7.4 Định tuyến ghi 25 Chương - BỘ CÔNG CỤ KHÔNG DÂY J2ME 41 1.8 So sánh SIP H.323 26 3.1 Giới thiệu 41 Chương - CƠ BẢN VỀ LẬP TRÌNH CHO THIẾT BỊ DI 29 3.1.1 Các công cụ công cụ 41 3.1.2 Đặc điểm công cụ 41 2.1 Giới thiệu 29 3.1.3 Các công nghệ hỗ trợ 42 2.2 Máy ảo Java (JVM – Java Virtual Machine) 29 3.2 Phát triển MIDlet 42 2.3 Cấu hình thiết bị 29 3.2.1 Dự án (Project) 42 2.3.1 Cấu hình thiết bị kết nối 29 3.2.2 Quy trình phát triển đơn giản 44 2.3.2 Cấu hình thiết bị hạn chế kết nối 30 3.2.3 Quy trình phát triển đầy đủ 44 ĐỘNG BẰNG JAVA 2.3.2.1 Những khác biệt CLDC so với Java chuẩn 30 2.3.2.2 Các lớp CLDC kế thừa từ J2SE 30 3.3.1 Lựa chọn API 45 2.3.2.3 Khung kết nối chung (GCF – Generic Connection 32 3.3.2 Thay đổi thuộc tínhcủa MIDlet 45 3.3.3 Thao tác MIDlet 46 Framework) 3.3 Làm việc với project 45 2.4 Profile 33 3.3.4 Cấu trúc thư mục dự án 46 2.5 Máy ảo Java cho CLDC 33 3.3.5 Sử dụng thư viện bên thứ ba 46 2.6 Xác minh file lớp (.class) 34 3.3.5.1 Các thư viện bên thứ ba cho project 47 2.6.1 Tiền xác minh 34 3.3.5.2 Các thư viện bên thứ ba cho tất project 47 2.6.2 Xác minh thiết bị 34 3.4 An toàn đánh dấu MIDlet 47 34 3.4.1 Sự cho phép (permission) 47 2.7.1 Cơ MIDlet 34 3.4.2 Các vùng bảo vệ (protect domain) 48 2.7.1.1 Quản lý ứng dụng môi trường thực thi Runtime 35 3.4.3 Đánh dấu MIDlet 49 2.7.1.2 File lưu trữ Java (JAR) 35 3.4.4 Quản lý khóa 49 36 3.4.4.1 Tạo cặp khóa 3.4.4.2 Nhận khóa thực 49 51 2.7 MIDLET 2.7.1.3 Bộ mô tả ứng dụng Java (file JAD) 2.7.2 Vòng đời MIDlet 37 2.7.3 Tạo MIDlet 2.7.4 MIDlet API 38 39 2.7.5 Giao tiếp từ quản lý ứng dụng Chương - GIAO TIẾP LẬP TRÌNH ỨNG DỤNG CHO J2ME 52 4.1 SipConnection 53 39 4.2 Tích hợp vào khung kết nối chung 53 2.7.6 Giao tiếp tới quản lý ứng dụng 40 4.3 Định tuyến yêu cầu gửi đến 54 2.7.7 Truy vấn thuộc tính MIDlet 40 10 MỞ ĐẦU 4.4 SipClientConnection 55 4.5 SipServerConnection 56 Ngày công nghệ thông tin di động phát triển Các máy điện thoại 4.6 SipConnectionNotifier 57 di động việc thực chức thoại bình thường tích hợp thêm 4.7 SipClientConnectionListener 58 nhiều tính khác cho phép người sử dụng cài đặt thêm chương 4.8 SipServerConnectionListener 58 trình Hãng Sun MicroSystem phát triển phần mềm Java cho lập trình di động 4.9 SipDialog 58 (J2ME) mà nhiều nhà sản xuất thiết bị tích hợp vào Song song với 4.10 SipHeader 60 thông tin di động mạng IP phát triển nhanh chóng Đã có nhiều nhà 4.11 SipAddress 60 4.12 SipRefreshHelper 61 4.13 SipRefreshListener 62 4.14 SipException 62 Chương - LẬP CHƯƠNG TRÌNH 63 Trong trình học cao học ngành xử lý thông tin truyền thông, em 5.1 Điều kiện thực chương trình 63 tâm đắc với môn học lập trình hệ phân tán thầy giáo, TS Hà Quốc Trung Do 5.2 Lưu đồ thuật toán 63 em định chọn đề tài “Lập trình SIP cho thiết bị di động Java” 5.3 Đăng nhập SIP 65 Em xin chân thành cảm ơn thầy giáo TS Hà Quốc Trung tận tình hướng dẫn em 5.4 Gọi 69 trình thực luận văn Em xin cảm ơn bạn bè, đồng nghiệp 5.5 Chờ gọi đến trả lời 71 5.6 Tạo project đóng gói chương trình 73 Luận văn gồm chương: 5.7 Mô 73 Chương nghiên cứu giao thức điều khiển báo hiệu phiên (SIP) KẾT LUẬN 74 Chương nghiên cứu lập trình cho thiết bị di động TÀI LIỆU THAM KHẢO 75 cung cấp dịch vụ thoại qua mạng IP thoại qua mạng IP sử dụng thiết bị đầu cuối di động Giao thức điều khiển báo hiệu phiên (SIP) giao thức báo hiệu đơn giản có khả cao để điều khiển báo hiệu mạng IP hỗ trợ em trình thực luận văn Chương nghiên cứu sử dụng công cụ để phát triển MIDlet Chương nghiên cứu giao diện ứng dụng chương trình SIP Chương lập chương trình SIP có chức đăng nhập, gọi đến thiết bị SIP khác, chờ trả lời gọi từ thiết bị SIP khác đến CHƯƠNG 1: GIAO THỨC ĐIỀU KHIỂN PHIÊN (SIP) 1.1 Khái niệm SIP giao thức lớp ứng dụng thiết kế phát triển IETF 11 12 Đặc tả SIP có vài RFC, quan trọng RFC 3261 liên lạc đồng thời tùy thuộc sách địa phương SIP giao thức báo hiệu cho điều khiển phiên đa phương tiện Nói cách khác, SIP cung cấp cách thiết lập truyền thông thoại, video tin nhắn thiết bị SIP dựa HTTP (Hyper Text Transfer Protocol – giao thức truyền siêu văn bản) SIP giao thức Client/Server, yêu cầu bên gọi (client) đưa bên bị gọi (server) trả lời 1.2 Các đặc điểm SIP • Tính di động: SIP cho phép client vị trí cố định bất kỳ, gọi định tuyến tới sử dụng địa biết địa email • Cấu trúc tin mềm dẻo: tin SIP có dạng văn (text) làm cho dễ dàng mở rộng thêm ứng dụng • Phân tán chức thiết bị: SIP cho phép yêu cầu định tuyến động qua thiết bị khác nhau, cho phép chức phân tán yêu cầu định tuyến qua thiết bị liên quan • Sự thỏa thuận tính hỗ trợ: điều làm cho SIP thích nghi mở rộng phương tiện giao thức sử dụng cho gọi riêng biệt thỏa thuận client 1.3 Các phần tử mạng SIP 1.3.1 User agent (UA) UA thiết bị đầu cuối mạng SIP UA máy tính cài phần mềm SIP, điện thoại SIP, điện thoại di động, PDA … UA thường đề cập tới UA server (UAS) UA client (UAC) UAS UAC thực thể logic, UA chứa UAS UAC UAC phần UA mà gửi yêu cầu nhận trả lời UAS phần UA mà nhận yêu cầu gửi trả lời 1.3.2 Proxy Server Proxy server thiết bị trung gian UA Proxy server chuyển yêu cầu trả lời UA Có loại proxy server proxy server trạng thái (stateful) proxy server không trạng thái (stateless) 1.3.2.1 Proxy server không trạng thái Proxy server không trạng thái đơn giản chuyển tiếp tin Nó chuyển tiếp tin độc lập với Mặc dù tin xếp vào giao dịch không quan tâm đến giao dịch gọi Kết SIP thiết lập kiểu hội Proxy server không trạng thái đơn giản nhanh proxy server trạng thái thoại bao gồm thoại, video, tin nhắn Một hạn chế proxy server không trạng thái khả • Tách riêng báo hiệu thông tin: SIP đường báo hiệu thông tin hoàn toàn độc lập • Sự chia nhánh: điều cho phép thiết bị liên kết với địa đơn, tất lựa chọn thiết bị truyền lại tin thực định tuyến phức tạp ví dụ chia nhánh 1.3.2.2 Proxy server trạng thái Proxy server trạng thái phức tạp Khi nhận yêu cầu, proxy server tạo trạng thái, trạng thái trì kết thúc phiên 13 14 giao dịch Một số giao dịch, đặc biệt giao dịch tạo “INVITE” động báo cho người nhận yêu cầu Bản tin trả lời để xác nhận kéo dài lâu (đến bị gọi nhấc máy từ chối gọi) Bởi máy chủ yêu cầu nhận xử lý chứa trạng thái việc xử lý phải quản lý trạng thái suốt thời gian giao dịch nên thực thi bị giới hạn Khả liên kết tin SIP vào giao dịch làm cho proxy 1.4.1 Các tin yêu cầu • INVITE : tin sử dụng để thiết lập phiên Ví dụ tin INVITE sau: server có số tính thú vị Proxy server thực việc chia nhánh, tức nhận tin hai hay nhiều tin khác gửi INVITE sip:7170@iptel.org SIP/2.0 Via: SIP/2.0/UDP 195.37.77.100:5040;rport Proxy server thực việc truyền lại tin từ trạng thái giao dịch biết nhận tin chưa Proxy server thực phương pháp phức tạp để tìm kiếm người sử dụng, ví dụ máy người sử dụng quan không trả lời chuyển gọi đến máy di động người Max-Forwards: 10 From: "jiri" ;tag=76ff7a07-c091-4192-84a0d56e91fe104f To: Call-ID: d10815e0-bf17-4afa-8412-d9130a793d96@213.20.128.35 CSeq: INVITE Hầu hết SIP proxy trạng thái cấu hình chúng thường Contact: phức tạp User-Agent: Windows RTC/1.0 1.3.3 Registrar server Proxy-Authorization: Registrar server thiết bị nhận yêu cầu đăng ký lưu trữ thông tin algorithm="MD5", uri="sip:jiri@bat.iptel.org", Digest username="jiri", realm="iptel.org", người sử dụng nonce="3cef753900000001771328f5ae1b8b7f0d742da1feb5753c", 1.3.4 Redirect server Redirect server thiết bị nhận tin yêu cầu gửi trả lại tin trả lời chứa danh sách vị trí người sử dụng 1.4 Các tin SIP Truyền thông sử dụng SIP (thường gọi báo hiệu) bao gồm dãy tin Các tin truyền độc lập mạng Thông thường response="53fe98db10e1074 b03b3e06438bda70f" Content-Type: application/sdp Content-Length: 451 v=0 o=jku2 0 IN IP4 213.20.128.35 s=session c=IN IP4 213.20.128.35 b=CT:1000 t=0 tin truyền gam liệu UDP Mỗi tin bao gồm phần dòng đầu tiên, phần đầu đề phần thân tin Phần dòng loại tin m=audio 54742 RTP/AVP 97 111 112 101 Có hai loại tin SIP Bản tin yêu cầu sử dụng để khởi tạo số hành a=rtpmap:97 red/8000 a=rtpmap:111 SIREN/16000 15 16 a=fmtp:111 bitrate=16000 a=rtpmap:112 G7221/16000 a=fmtp:112 bitrate=24000 a=rtpmap:6 DVI4/16000 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=rtpmap: GSM/8000 a=rtpmap:101 telephoneevent/8000 a=fmtp:101 0-16 • CANCEL : dùng để hủy bỏ phiên không thiết lập đầy đủ • REGISTER : dùng để máy chủ registrar biết vị trí user Thông tin địa IP cổng user chứa tin REGISTER Máy chủ registrar lấy thông tin đưa vào sở liệu vị trí Cơ sở liệu sau sử dụng Phần đầu dòng cho ta biết tin INVITE Sau địa bước truyền proxy server để định tuyến gọi tới user Việc đăng ký hạn tin chế thời gian cần phải làm tươi theo chu kỳ Trường đầu đề “Via” sử dụng để ghi lại đường tin yêu cầu Sau sử dụng để định tuyến tin trả lời theo xác đường Bản tin INVITE chứa trường “Via” tạo UA gửi tin Trường đầu đề “From” “To” địa người gọi người bị gọi 1.4.2 Các tin phúc đáp Khi UA proxy server nhận yêu cầu gửi lại phúc đáp Tất yêu cầu phải phcs đáp trừ yêu cầu ACK Một phúc đáp điển sau: Trường “Call-ID” để nhận dạng tin gọi SIP/2.0 200 OK Các tin có môt “Call-ID” Via: SIP/2.0/UDP 192.168.1.30:5060;received=66.87.48.68 Trường “Cseq” dùng để thứ tự yêu cầu From: sip:sip2@iptel.org Trường “Contact” chứa địa IP cổng mà người gửi đợi yêu cầu từ To: sip:sip2@iptel.org;tag=794fe65c16edfdf45da4fc39a5d2867c.b713 người bị gọi Call-ID: 2443936363@192.168.1.30 Đầu đề tin phân cách với phần thân dòng trống Phần thân CSeq: 63629 REGISTER tin INVITE chứa mô tả kiểu liẹu chấp nhận người gửi Contact: ;q=0.00;expires=120 mã hóa SDP Server: Sip EXpress router (0.8.11pre21xrc (i386/linux)) • ACK : tin công nhận nhận tin trả lời cuối cho Content-Length: INVITE Thiết lập phiên sử dụng bắt tay bên Việc tốn Warning: 392 195.37.77.101:5060 "Noisy feedback tells: pid=5110 thêm thời gian trước bị gọi chấp nhận từ chối gọi Bị req_src_ip=66.87.48.68 req_src_port=5060 in_uri=sip:iptel.org gọi gửi lại tin trả lời cuối theo chu kỳ nhận out_uri=sip:iptel.org via_cnt==1" tin ACK • BYE : tin dùng để kết thúc phiên đa phương tiện Bên muốn kết thúc phiên gửi BYE cho bên Dòng tin phúc đáp chứa phiên giao thức (SIP2.0), mã phúc đáp lý 17 18 • 5xx có nghĩa vấn đề nằm phía server Yêu cầu hợp lệ Mã phúc đáp số nguyên từ 100 đến 699 loại phúc đáp Có lớp phúc đáp: server lỗi không thực • 1xx phúc đáp tạm thời Một phúc đáp tạm thời phúc đáp mà • 6xx có nghĩa yêu cầu đáp ứng server báo cho bên nhận biết yêu cầu tương ứng nhận Phúc đáp thường gửi server mà có thông tin cuối kết xử lý Phúc đáp tạm thời gửi user cụ thể Các UA thường gửi tin 603 từ chối trả lời user không muốn tham dự vào phiên việc xử lý không hoàn thành Người gửi phải dừng việc gửi lại yêu cầu 1.5 Các giao dịch SIP Thông thường proxy server gửi phúc đáp với mã 100 chúng bắt đầu xử lý INVITE UA gửi phúc đáp với mã 180 (đổ chuông) • 2xx phúc đáp xác thực cuối Phúc đáp cuối đồng Mặc dù nói tin SIP gửi cách độc lập qua mạng, chúng thường xếp vào giao dịch UA proxy server Vì SIP gọi giao thức giao dịch thời kết thúc giao dịch Phúc đáp với mã từ 200 đến 299 phúc Một giao dịch chuỗi tin SIP trao đổi phần tử đáp xác thực có nghĩa yêu cầu xử lý thành công mạng SIP Một giao dịch bao gồm yêu cầu tất phúc đáp cho yêu cầu chấp nhận Ví dụ phúc đáp 200 OK gửi user chấp nhận Đó bao gồm không nhiều phúc đáp tạm thời nhiều tin lời mời tới phiên ( yêu cầu INVITE ) cuối • 3xx dùng để định hướng lại người gọi Một phúc đáp định Nếu giao dịch khởi tạo yêu cầu INVITE giao dịch hướng lại cho thông tin vị trí user dịch vụ mà bao gồm ACK phúc đáp cuối phúc đáp người gọi sử dụng Phúc đáp định hướng lại thường gửi 2xx Nếu phúc đáp cuói 2xx ACK phần giao proxy server Khi proxy nhận yêu cầu không muốn dịch xử lý lý gì, gửi phúc đáp định hướng lại tới người gọi đặt vị trí khác vào phúc đáp mà người gọi muốn thử lại Nó vị trí proxy khác vị trí bị gọi (từ sở liệu vị trí registrar) Chủ gọi sau gửi lại yêu cầu tới vị trí Các phúc đáp 3xx cuối • 4xx phúc đáp cuối từ chối Một phúc đáp 4xx có nghĩa vấn đề phía chủ gọi Yêu cầu xử lý chứa cú pháp sai thực server 19 20 Giao dịch Hình 1.2 Hội thoại SIP Một số tin thiết lập hội thoại, số không Điều cho phép biểu diễn rõ ràng mối quan hệ tin đồng thời để gửi tin mà không liên quan tới tin khác hội thoại Điều thực dễ dàng UA giữ trạng thái hội thoại Ví dụ tin INVITE thiết lập hội thoại kèm theo Giao dịch sau yêu cầu BYE để kết thúc phiên thiết lập INVITE Bản tin BYE gửi hội thoại thiết lập INVITE Nhưng Hình 1.1 Các 1.6 Các giao dịch SIP hội thoại SIP hội thoại tương ứng với quan hệ SIP đồng đẳng (peer-to-peer) hai UA Các hội Một UA gửi yêu cầu MESSAGE yêu cầu không thiết lập hội thoại Các tin sau gửi độc lập với tin trước 1.6.1 Các hội thoại làm cho định tuyến thuận tiện thoại làm cho việc xếp thứ tự định tuyến tin điểm cuối Chúng ta biết hội thoại sử dụng để định tuyến tin SIP thuận tiện UA Các hội thoại định danh sử dụng trường Call-ID, From To Các Giả sử user sip:bob@a.com muốn nói chuyện với user:pete@b.com Chủ tin có ba trường giống hội thoại Một hội thoại gọi biết địa SIP bị gọi địa không nói điều vị dãy giao dịch Hình 1.2 tin hội thoại trí user – chủ gọi phải gửi yêu cầu tới host Vì yêu cầu INVITE gửi tới proxy server Yêu cầu sau gửi từ proxy đến proxy tới đến proxy mà biết vị trí bị gọi Quá trình gọi định tuyến Khi yêu cầu Giao dịch đến bị gọi, bị gọi tạo phúc đáp gửi lại cho chủ gọi Bị gọi đồng thời đưa trường đầu đề “Contact” vào phúc đáp chứa địa Hội h i user Yêu cầu gốc chứa trường đầu đề “Contact” có nghĩa hai UA biết vị trí Bởi UA biết vị trí nên không cần thiết phải gửi yêu cầu qua Giao dịch proxy nữa, chúng gửi trực tiếp từ UA đến UA Đó hội thoại làm cho định tuyến thuận tiện 21 22 Các tin hội thoại sau gửi trực tiếp từ UA đến UA From tag tạo chủ gọi nhận dạng hội thoại UA Điều giúp cải thiện hiệu proxy không xem tất tin chủ gọi hội thoại, chúng thường sử dụng để định tuyến yêu cầu đầu To tag tạo bị gọi nhận dạng hội thoại UA bị tiên mà thiét lập hội thoại Các tin trực tiếp đồng thời truyền với gọi độ trễ nhỏ nhiều proxy thường thực phép toán logic định tuyến phức tạp Hình 1.3 ví dụ minh họa điều Sự nhận dạng hội thoại phân cấp cần thiết mời gọi tạo vài hội thoại chủ gọi phải có khả phân biệt chúng 1.7 Những kịch SIP điển hình Phần trình bày cách khái quát kịch SIP điển hình thường xảy 1.7.1 Đăng ký Người sử dụng phải đăng ký với registrar để người sử dụng khác liên lạc đến Một đăng ký bao gồm tin “REGISTER” phúc đáp “200 OK” từ registrar đăng ký thành công Sự đăng ký thường phải xác thực phúc đáp “407” gửi người sử dụng không cung cấp tin cậy hợp lệ Hình 1.4 ví dụ đăng ký Hình 1.3 Hình thang SIP 1.6.2 Nhận dạng hội thoại Chúng ta biết nhận dạng hội thoại bao gồm ba phần : CallId, From tag To tag Nhưng không rõ ràng phần nhận dạng hội thoại lại tạo xác đóng góp phần Hình 1.4 Sự đăng ký Call-Id gọi phần nhận dạng gọi Nó phải chuỗi ký tự để nhận dạng gọi Một gọi bao gồm hay nhiều hội thoại 1.7.2 Khởi tạo phiên Đa UA phúc đáp cho yêu cầu proxy phân nhánh yêu cầu Một khởi tạo phiên bao gồm yêu cầu “INVITE” mà thường gửi tới Mỗi UA gửi phúc đáp 2xx thiết lập hội thoại riêng rẽ với chủ gọi Tất proxy Proxy gửi phúc đáp “100 Trying” để ngừng việc gửi lại hội thoại phần gọi có tham số “Call- chuyển yêu cầu sau Id” 23 24 Tất phúc đáp tạm thời tạo bị gọi gửi lại cho chủ gọi Khi bị gọi Tất yêu cầu hội thoại mặc định gửi trực tiếp từ UA đến đổ chuông gửi phúc đáp cho chủ gọi tin “180 Ringing” Khi bị gọi nhấc UA khác Chỉ yêu cầu hội thoại qua proxy Cách máy gửi lại tin “200 OK”và gửi lại nhận làm cho mạng SIP mềm dẻo có số nhỏ tin đến proxy “ACK” từ chủ gọi Phiên thiết lập điểm Hình 1.5 ví dụ minh họa khởi tạo phiên Có tình mà proxy cần lưu lại đường tất tin Ví dụ proxy điều khiển hộp NAT proxy thực tính cước cần phải lưu lại đường yêu cầu “BYE” định tuyến ghi có định tuyến ghi Hình 1.6 Chấm dứt phiên Kỹ thuật mà proxy cho UA biết muốn lưu lại đường tất tin gọi định tuyến ghi Proxy chèn trường đầu đề “Record-Route” vào tin SIP mà có chứa địa proxy Các Hình 1.5 Khởi tạo phiên 1.7.3 Kết thúc phiên Kết thúc phiên thược cách gửi tin “BYE” Bản tin “BYE” gửi trực tiếp từ UA đến UA khác trừ proxy đường yêu cầu “INVITE” phải theo cách sử dụng định tuyến ghi Bên muốn kết thúc phiên gửi yêu cầu “BYE” tới bên Bên gửi lại phúc đáp “200 OK” để xác nhận yêu cầu “BYE” phiên chấm dứt 1.7.4 Định tuyến ghi tin gửi hội thoại qua tất proxy mà chèn trường “Record-Route” vào tin Bên nhận yêu cầu nhận tập trường “Record-Route” tin Nó phải ánh xạ lại tất trường vào phúc đáp bên phát yêu cầu cần phải biết tập proxy 1.8 So sánh SIP H.323 Ngoài SIP có giao thức báo hiệu khác sử dụng phổ biến H323 53 54 CHƯƠNG : GIAO TIẾP LẬP TRÌNH ỨNG DỤNG CHO J2ME Chương giới thiệu đặc tả JSR 180, SIP API cho J2ME Đặc tả định nghĩa gói tuỳ chọn J2ME mà cho phép thiết bị hạn chế tài nguyên (sau gọi thiết bị đầu cuối) gửi nhận tin SIP API cung cấp chức SIP mức giao dịch SIP API sử dụng chương trình ứng dụng để thực chức SIP UA Các lớp giao diện SIP API: Lớp / giao diện Chức SipClientConnection SipClientConnection mô tả giao dịch SIP client SipClientConnectionListener Giao diện nghe phúc đáp SIP đến SipConnection giao diện sở cho kết nố SIP SipConnection SipRefreshHelper Lớp thực chức làm thuận tiện việc xử lý làm tươi yêu cầu ứng SipException Đây lớp ngoại lệ cho lỗi SIP cụ thể 4.1 SipConnection SipConnection giao diện cho kết nối SIP SipConnection giữ thuộc tính chung cho giao diện SipClientConnection SipServerConnection Khai báo : public interface SipConnection extends javax.microedition.io.Connection Các giao diện cha : javax.microedition.io.Connection Các giao diện : SipClientConnection, SipServerConnection SipConnectionNotifier Giao diện định nghĩa thông báo kết nối SIP server SipDialog SipDialog mô tả SIP Dialog SipRefreshListener Giao diện nghe kiện RefreshHelpe SipServerConnection SipServerConnection mô tả giao dịch SIP server SipServerConnectionListener Giao diện nghe yêu cầu SIP gửi đến SipAddress SipAddress cung cấp phân tích địa SIP chung SipHeader SipHeader cung cấp trợ giúp phân tích đầu đề SIP 4.2 Tích hợp vào khung kết nối chung Tích hợp vào javax.microedition.io.Connector Một kết nối SIP tạo Connector.open() Một ứng dụng phải gọi close ( ) muốn kết thúc kết nối Chú ý Connector.open()cho kết nối chế độ client (SipClientConnection) kết nối chế độ server (SipConnectionNotifier) tuỳ thuộc vào chuỗi (SIP URI) Connector.open() SIP URI định nghĩa RFC3261 Mẫu chung sau: {scheme}:[{target}][{params}] Trong đó: • scheme lược đồ SIP hỗ trợ hệ thống SIP • target địa mạng người sử dụng có dạng {user_name}@{target_host}[:{port}] {telephone_number} 55 56 • params: tham số khác cho SIP URI ví dụ transport=udp an toàn người gửi định nghĩa luật định tuyến mà không bị thay ứng dụng khác 4.3 Định tuyến yêu cầu gửi đến Luật định tuyến sau dựa vào thông tin yêu cầu gửi đến Việc thực định nghĩa sách địa phương mà thay luật lý an toàn Yêu cầu gửi đến định tuyến dựa vào thông tin sau: • Trường đầu đề Accept-Contact • Trường đầu đề Reject-Contact 4.4 SipClientConnection Khai báo: public interface SipClientConnection extends SipConnection Các giao diện cha : javax.microedition.io.Connection, SipConnection • SDP media : tên phương tiện cổng địa Yêu cầu định tuyến theo luật sau, dựa vào thông tin có sẵn Tất yêu cầu có trường đầu đề Accept-Contact RejectContact Yêu cầu INVITE có tải SDP Accept SipClientConnection đại diện cho giao dịch SIP client Ứng dụng tạo SipClientConnection với đối tượng Connector SipDialog SipClientConnection có biểu đồ trạng thái hình 4.1: - SDP media Routing Contact Trường đầu đề chứa tập thuộc tính mô tả UA mà chủ gọi muốn gọi đến Trong đặc tả yêu cầu tối thiểu ứng dụng kiểu MIME định tham số “type” 1) Có - 2) Có Có Giống trường hợp 1) 3) - Có (Tuỳ chọn) Yêu cầu định tuyến dựa vào thông tin phương tiện SDP Hình 4.1 Biểu đồ trạng thái SipClientConnection Các trạng thái: • Created: SipClientConnection tạo Connector Luật 1) định nghĩa yêu cầu tối thiểu hoạt động cho đặc tả Người gửi SIP phải thực luật định định nghĩa đặc tả RFC 3841 Vì lý • Initialized: yêu cầu khởi tạo với initRequest( ) initAck initCancel() 57 58 • Request SipDialog.getNewClientConnection( ) • Stream Open: OutputStream mở với openContentOutputStream() Mở InputStream để nhận phản hồi không làm thay đổi trạng thái • Proceeding: yêu cầu gửi đợi phúc đáp, Received: SipServerConnection trả lại từ SipConnectionNotifier (không ACK) phúc đáp tạm thời (1xx) • Initialized: phúc đáp khởi tạo gọi initResponse() • Stream Open: OutputStream mở với nhận phúc đáp tạm thời 1xx initCancel() gọi mà xuất openContentOutputStream() Việc mở InputStream để nhận yêu cầu SipClientConnection trạng thái không làm thay đổi trạng thái Initialized • Completed: giao dịch hoàn thành với việc gửi phúc đáp cuối • Completed: giao dịch hoàn thành với phúc đáp cuối (2xx, 3xx, 4xx, 5xx, 6xx) Trong trạng thái ACK khởi tạo Nhiều phúc đáp 200 OK nhận Riêng phúc đáp 401 407 chuyển trạng thái khác (2xx, 3xx, 4xx, 5xx, 6xx) gửi lại 2xx SipServerConnection cho ACK từ SipConnectionNotifier • Terminated: trạng thái cuối mà kết nối SIP chấm dứt lỗi đóng • Unauthorized: giao dịch hoàn thành với phúc đáp 401 (Unauthorized) 407 (Proxy Authentication Required) Ứng dụng bắt đầu lại yêu cầu với khả thích hợpbằng cách gọi setCredentials() method Sau SipClientConnection trở lại trạng thái Proceeding • Terminated: trạng thái cuối mà kết nối SIP kết thúc lỗi hay đóng lại 4.5 SipServerConnection Khai báo: public interface SipServerConnection extends SipConnection Các giao diện cha: Hình 4.2 Biểu đồ trạng thái SipServerConnection javax.microedition.io.Connection, SipConnection SipServerConnection đại diện cho 4.6 SipConnectionNotifier giao dịch SIP server SipServerConnection tạo SipConnectionNotifier yêu cầu nhận Các trạng thái SipServerConnection: • Created: SipServerConnection tạo Khai báo: public interface SipConnectionNotifier extends javax.microedition.io.Connection Các giao diện cha: javax.microedition.io.Connection 59 60 Giao diện định nghĩa thông báo kết nối SIP server Kết nối SIP server mở với Connector.open() sử dụng chuỗi SIP URI với việc bỏ qua host user 4.7 SipClientConnectionListener Khai báo: public interface SipClientConnectionListener Đây giao diện nghe phản hồi SIP gửi đến 4.8 SipServerConnectionListener Khai báo: public interface SipServerConnectionListener Đây giao diện nghe yêu cầu SIP gửi đến 4.9 SipDialog Khai báo: public interface SipDialog SipDialog diễn đạt hội thoại SIP SipDialog nhận từ đối tượng SipConnection Có hai yêu cầu SIP mở hội thoại: • INVITE-1xx-2xx-ACK mở hội thoại 61 62 SipClientConnection hội thoại thu cách gọi phương thức getNewClientConnection(String method) Hội thoại chấm dứt giao dịch BYE-200 OK hoàn thành • SUBSCRIBE-200 OK(hoặc khớp NOTIFY) mở hội thoại Tiếp theo sau SipClientConnection hội thoại đạt cách gọi phương thức getNewClientConnection(String method) Hội thoại chấm dứt thông báo gửi yêu cầu NOTIFY với “Subscription-State” “terminated” subscription sống với hội thoại Hình 4.3 Biểu đồ trạng thái SipDialog (phía clien) SipDialog có trạng thái sau (cho client server side): • Initialized: trạng thái bên hội thoại tạo Trạng thái không hữu hình với người sử dụng • Early: phúc đáp tạm thời 101-199 nhận (hoặc gửi) • Confirmed: phúc đáp cuối 2xx response nhận (hoặc gửi) cho yêu cầu gốc Hoặc NOTIFY xác nhận subscription nhận (hoặc gửi) • Terminated: phúc đáp phúc đáp lỗi (3xx-6xx) nhận (hoặc gửi) Hội thoại chấm dứt với BYE unSUBSCRIBE Hình 4.4 Biểu đồ trạng thái SipDialog (phía server) 4.10 SipHeader Khai báo: class public SipHeader java.lang.Object | + javax.microedition.sip.SipHeader 63 64 SipHeader cung cấp trợ giúp phân tích đầu đề SIP chung Lớp Lớp thực chức làm cho thuận tiện việc làm tươi yêu cầu sử dụng để phân tích giá trị đầu đề ký tự tối thiểu mà đọc từ tin SIP sử ứng dụng số yêu cầu SIP (REGISTER, SUBSCRIBE, ) cần phải dụng phương thức SipConnection.getHeader().SipHeader lớp trợ giúp làm tươi lúc Ví dụ yêu cầu REGISTER cần phải gửi lại để đảm bảo riêng rẽ không bắt buộc sử dụng cho tạo kết nối SIP Do SIP headers điểm khởi tạo hoạt động Tính hợp lệ yêu cầu đề điểm cuối xây dựng với lớp SipHeader sử dụng khuôn dạng chung để phân yêu cầu xác nhận phúc đáp registrar/notifier ví dụ tích giá trị header tham số expires header Việc xử lý làm tăng đáng kể độ phức tạp kích thước chương trình SipRefreshHelper đwocj sử dụng để làm cho dễ dàng 4.11 SipAddress Khai báo: class công việc Khi ứng dụng muốn gửi yêu cầu làm tươi sẽ: public SipAddress java.lang.Object • Thực SipRefreshListener gọi lại giao diện • Tạo SipClientConnection thiết lập | • Gọi phương thức enableRefresh(SipRefreshListener) + javax.microedition.sip.SipAddress • Nếu công việc làm tươi bị lỗi kiện lỗi gửi đến SipAddress cung cấp phân tích địa SIP chung Các địa hợp lệ xây dựng với lớp SipAddress có yêu cầu chức sau: • SipAddress không tránh chuỗi ký tự địa • SipAddress bỏ qua phần đầu đề SIP URI • Khuôn dạng hợp lệ SipAddress giống định nghĩa SIP BNF cho URI tuyệt đối • Địa Contact hợp lệ “*” chấp nhận SipAddress Trong trường hợp thuộc tính null số cổng 4.12 SipRefreshHelper Khai báo: public class SipRefreshListener Một tham chiếu tới đối tượng SipRefreshHelper thu cách gọi phương thức tĩnh SipRefreshHelper.getInstance() Cuối sử dụng mã làm tươi từ enableRefresh(SipRefreshListener) ứng dụng có thể: • Dừng làm tươi: liên kết điểm cuối server bị hủy bỏ • Cập nhật làm tươi với tham số 4.13 SipRefreshListener Khai báo: public interface SipRefreshListener SipRefreshListener giao diện nghe kiện RefreshHelpe Giao diện định nghĩa kiện mà chứa refreshID để nhận dạng công việc làm tươi tương ứng, statusCode diễn tả kết trình làm tươi (0 = SipRefreshHelper bị hủy, 200 = thành công, lại = không thành công) statusCode tương ứng với java.lang.Object phúc đáp nhận cho yêu cầu nguyên thủy gửi SipRefreshHelper | + javax.microedition.sip.SipRefreshHelper reasonPhrase cho tin nguyên thành công hay không công việc làm tươi 4.14 SipException 65 66 Khai báo: public class SipException extends java.io.IOException java.lang.Object • Nếu có gọi đến trả lời không trả lời • Nếu muốn gọi chuyển sang chế độ gọi • Nếu đến thời gian phải làm tươi thực lại đăng nhập tới server | + java.lang.Throwable | • Nếu muốn kết thúc chương trình đóng chương trình giải phóng nhớ + java.lang.Exception | + java.io.IOException Bắt đầu | + javax.microedition.sip.SipException Đăng nh ập Đây lớp ngoại lệ cho lỗi cụ thể SIP Ngoại lệ bao gồm tin lỗi nguyên khuôn dạng tự mã lỗi để phân loại lỗi Chờ CHƯƠNG : LẬP CHƯƠNG TRÌNH 5.1 Điều kiện thực chương trình Y Gọi Để thực chương trình cần phải có điều kiện sau: Gọi đi? N • Thiết bị di động phải có cài đặt CLDC MIDP Hiện loại Có gọi đến? điện thoại di động phổ biến cài đặt CLDC 1.1 MIDP 2.0 Ngoài thiết bị phải có kkhả kết nối mạng, có đủ nhớ để cài đặt N thực chương trình Làm t ươi? • Đã có SIP server (proxy server, registrar server, redirect server) N • Có tài khoản SIP server N Kết thúc? 5.2 Thuật toán chương trình Các bước thuật toán: • Khi bắt đầu chạy chương trình, thiết bị đăng nhập vào SIP server • Sau thiết bị vào trạng thái chờ gọi đến Trả lời Y Kết thúc Y 67 68 Hình 5.1 Lưu đồ thuật toán 5.3 Đăng nhập SIP Bắt đầu Khi bắt đầu chạy, chương trình phải thực đăng nhập vào mạng SIP cách gửi tin REGISTER Trước tiên phải nhập tên mật Khởi tạo REGISTER Các bước thực sau: + Ứng dụng khởi tạo yêu cầu REGISTER gốc + Ứng dụng gọi send() Gửi yêu c ầu Nhận phúc đáp + SIP API thực gửi yêu cầu REGISTER đến server + Ứng dụng gọi receive( ) để đợi phúc đáp + Nếu tên mật không hợp lệ SIP server gửi phúc đáp “401 Unauthorized” Nếu hợp lệ SIP server gửi phúc đáp “200 OK” + Ứng dụng gọi getStatusCode() + Ứng dụng kết thúc kết nối phương thức close( ) Hợp lệ? N Y Kết thúc Hình 5.2 Thu ật toán đăng nh ập SIP 69 70 new String(“sip:user@”+scn.getLocalAddress()+“:”+scn.getLocalPort( )); open client connection to the SIP registrar in this case “host.com” scc =SipClientConnection)open(“sip:host.com”); initialize REGISTER with appropriate headers scc.initRequest(“REGISTER”, scn); scc.setHeader(“From”, “sip:user@host.com”); setHeader(“To”,sip:user@host.com”); setHeader(“Contact”, contact); = false; int scode = 0; scc.send(); boolean handled while(!handled) { SipHeader sh; // wait max 30 secs for response scc.receive(30000); scode = scc.getStatusCode(); switch(scode) { Hình 5.3 Quá trình thực đăng nhập case 401: sh = new SipHeader(“WWW-Authenticate”, Mã chương trình: scc.getHeader(“WWW-Authenticate”)); public void doRegister(String username, String password, String realm) realm = sh.getParameter(“realm”); { // here for example, prompt user for password for this realm SipClientConnection scc = null; // set credentials to initiate re-REGISTER scc.setCredentials(username, password, realm); case 407: SipConnectionNotifier scn = String contact = try { break; sh = new SipHeader(“Proxy-Authenticate”, // open listener in application specific port 5080 scn = (SipConnectionNotifier) Connector.open(“sip:5080”); // build the contact URI scc.getHeader(“Proxy-Authenticate”)); realm = sh.getParameter(“realm”); contact = // here for example, prompt user for password for this realm 71 72 // set credentials to initiate re-REGISTER Client Server scc.setCredentials(username, password, realm); INVITE break; 100 Trying case 200: // handle OK response handled = true; default: handle other responses handled = } } scc.close(); } catch(Exception ex) { 180 Ringing 200 OK ACK Media BYE 200 OK // handle Exceptions Hình 5.4 Quá trình thực gọi } } 5.4 Gọi Quy trình gọi sau: • Khởi tạo gửi tin INVITE • Nhận tin phúc đáp tạm thời 100, 180 nhận tin cuối 200 OK • Khởi tạo gửi tin ACK để thiết lập phiên • Trao đổi liệu • Khởi tạo gửi tin BYE • Nhận tin 200 OK cho BYE, kết thúc phiên 73 74 • Trao đổi liệu Bắt đầu • Chờ nhận yêu cầu BYE: phiên kết thúc Khởi tạo g ửi INVITE • Gửi phúc đáp 200 OK Client Nhận phúc đáp Server Open connection 200 OK? N INVITE 180 Ringing Y Khởi tạo g ửi ACK 200 OK ACK Trao đổi liệu Kết thúc? Media N Y Khởi tạo g ửi BYE BYE 200 OK Hình 5.6 Quá trình thực trả lời gọi đến Nhận 200 OK Kết thúc Hình 5.5 Thuật toán gọi 5.5 Chờ gọi đến trả lời Quy trình chờ gọi đến trả lời sau: • Mở kết nối để chờ yêu cầu gửi đến • Nhận yêu cầu INVITE • Khởi tạo gửi phúc đáp 180 200 OK • Chờ nhận yêu cầu ACK :phiên khởi tạo 75 76 Sau viết xong mã nguồn, sử dụng J2ME Wireless Toolkit để lập dự án đóng Bắt đầu gói chương trình Trước hết ta khởi động chương trình KToolbar Đặt tên dự án “SIP” Sau copy file nguồn vào thư mục \SIP\src\ Tiến hành biên dịch M k ết n ố i tiền xác minh file nguồn cách chọn Project → Package → Create Package Trong trình dịch có lỗi phải sửa lỗi file nguồn Sau Nhận tin dịch tiền xác minh xong công cụ tạo file JAD, JAR lưu trữ N INVITE? Y Gửi 180 Ringing Gửi 200 OK Nhận tin N ACK? Y Trao đổi liệu Nhận tin N BYE? Y Gửi 200 OK Kết thúc Hình 5.7 Thuật toán trả lời gọi đến 5.6 Tạo project đóng gói chương trình vào thư mục \SIP\bin\ 77 78 79 80 5.7 Mô Sau đóng gói chương trình chạy trương trình mô máy tính Hình mô hình 5.8: Hình 5.8 Mô điện thoại di động KẾT LUẬN Luận văn thực vấn đề sau: Tìm hiểu J2ME, SIP, tìm điểm mạnh, điểm yếu, so sánh với công nghệ tương tự 81 Ứng dụng xây dựng chương trình có tính năng: a Đăng nhập vào mạng SIP b Thực khởi tạo phiên để gọi đến thiết bị SIP khác c Trả lời có gọi từ thiết bị SIP khác đến Phân tích, đánh giá, tổng hợp tạo qui trình xây dựng ứng dụng dựa J2ME giao thức truyền thông Hướng nghiên cứu mở rộng framework giao thức truyền tải thời gian thực (RTP- Real-time Transport Protocol) thực RTP J2ME Một lần em xin chân thành cảm ơn thầy giáo TS Hà Quốc Trung tận tình hướng dẫn em trình thực luận văn Đồng thời em xin cảm ơn bạn bè, đồng nghiệp hỗ trợ em trình thực luận văn Nếu có thiếu sót em mong thầy cô giáo bạn đồng nghiệp bảo [...]... nhiệm 2.1 Giới thiệu Java được hãng Sun Microsystem giới thiệu vào năm 1995 Ban đầu là phiên bản chuẩn được thiết kế để chạy trên destop và máy trạm Hai năm sau hãng đưa ra phiên bản mới gọi là phiên bản xí nghiệp dùng cho những ứng dụng lớn Năm 1999 Sun đưa ra phiên bản nhỏ gọn dùng cho những thiết bị nhúng và cầm tay mà không hỗ trợ thực hiện phiên bản chuẩn Từ tháng 12/1998 Sun giới thiệu tên mới “Java... startApp() Phương thức này có thể được gọi suốt vòng đời của một J2ME (J2ME Wireless Toolkit) để hỗ trợ việc này Chương này sẽ giới thiệu cách MIDlet Phương thức pauseApp() thông báo cho MIDlet sắp sửa được đặt vào sử dụng bộ công cụ này để tạo các ứng dụng trạng thái tạm ngừng Lúc này MIDlet có thể tranh thủ giải phóng những tài 3.1 Giới thiệu nguyên chưa cần đến Phương thức destroyApp() báo hiệu cho MIDlet... được sử dụng r ộng rãi Báo hiệu quảng bá Có hỗ trợ Không Chất lượng dịch vụ Sử dụng các giao thức khác như RSVP, OPS, OSP để đảm Gatekeeper điều khiển bảo chất lượng dịch vụ băng thông H.323 khuyến nghị dùng RSVP để lưu trữ tài nguyên mạng Bảo mật Đăng ký tại registrar server, Chỉ đăng ký khi trong 27 28 có xác nhận đầu cuối và mã hoá mạng có gatekeeper, xác CHƯƠNG 2 : CƠ BẢN VỀ LẬP TRÌNH nhận và mã... là giao diện cơ bản cho các kết nối SIP SipConnection giữ các thuộc tính và chung cho các giao diện con SipClientConnection và SipServerConnection Khai báo : public interface SipConnection extends javax.microedition.io.Connection Các giao diện cha : javax.microedition.io.Connection Các giao diện con : SipClientConnection, SipServerConnection SipConnectionNotifier Giao diện này định nghĩa một thông báo. .. tạo các loại kết nối như file, http, datagram… Phương thức mở kết nối có dạng sau: Connector Open( giao thức: địa chỉ; các tham số”); Hình 2.1 cho thấy phân cấp kết nối trong GCF: 2.5 Máy ảo Java cho CLDC Đối với các thiết bị cấu hình dạng CLDC, Sun cài đặt một phiên bản thu nhỏ hơn dành cho JVM gọi là K virtual machine (KVM) KVM được thiết kế để điều khiển và chạy trên những thiết bị có nguồn tài nguyên... javax.microedition.io.Connection Các giao diện cha: javax.microedition.io.Connection 59 60 Giao diện này định nghĩa một bộ thông báo kết nối SIP server Kết nối SIP server được mở với Connector.open() sử dụng một chuỗi SIP URI với việc bỏ qua host và user 4.7 SipClientConnectionListener Khai báo: public interface SipClientConnectionListener Đây là giao diện nghe các phản hồi SIP gửi đến 4.8 SipServerConnectionListener Khai báo: public... những thiết bị nhúng và cầm tay mà không hỗ trợ thực hiện phiên bản chuẩn Từ tháng 12/1998 Sun giới thiệu tên mới “Java 2” thay cho phiên bản Java 1.2 Tên mới này được dùng để quy ước cho cho tất cả các phiên bản của Java: phiên bản chuẩn (J2SE), phiên bản xí nghiệp (J2EE) và phiên bản nhỏ gọn (J2ME) Tính năng thoại Hội nghị Hỗ trợ các tính năng của cuộc Hỗ trợ các tính năng của gọi cơ bản cuộc gọi cơ... sử dụng những dịch vụ như bảng thông báo, trao đổi dữ liệu, hoặc hội nghị video • SIP hỗ trợ điều khiển cuộc gọi từ một đầu cuối thứ 3 Hiện nay H.323 đang được nâng cấp để hỗ trợ chức năng này Dưới đây là b ảng so sánh gi ữa hai giao th ức: SIP Khuôn dạng bản IETF ITU Quan h ệ kết nối Ngang c ấp Ngang c ấp Khởi điểm Dựa trên mạng Internet và C s ở là m ạng tho ại Giao Trễ thiết lập cuộc gọi Giám sát... điểm này } 2.7.6 Giao tiếp tới bộ quản lý ứng dụng } 2.7.4 MIDlet API Khi một MIDlet cần đóng lại (chấm dứt), phương thức notifyDestroyed() có thể được gọi để báo hiệu cho bộ quản lý ứng dụng yêu cầu này Tuần tự có thể diễn MIDlet class: javax.microedition.midlet.MIDlet Phương thức Mô tả Giao tiếp từ bộ quản lý ứng dụng đến MIDlet abstract void destroyApp(boonlean unconditional) MIDlet chuẩn bị shutdown... CHƯƠNG 4 : GIAO TIẾP LẬP TRÌNH ỨNG DỤNG CHO J2ME Chương này giới thiệu đặc tả JSR 180, SIP API cho J2ME Đặc tả này định nghĩa một gói tuỳ chọn J2ME mà cho phép các thiết bị hạn chế tài nguyên (sau đây gọi là thiết bị đầu cuối) gửi và nhận các bản tin SIP API này cung cấp chức năng SIP ở mức giao dịch SIP API được sử dụng bởi các chương trình ứng dụng để thực hiện các chức năng SIP UA Các lớp và giao diện