2013年1月29日 星期二

live555 -- Compile and test on MAC and iOS

Below is the test procedure to use live555 on iOS and Mac OSX.

Mac OS X 10.8.2
1. Download file
   http://www.live555.com/liveMedia/public/, What I download is live.2013.01.25.tar.gz
 
2. unzip the file
   $tar -xvf live.2013.01.25.tar.gz 
3. build file
   $ ./genMakefiles macosx
   $ make

4. run the test file
   $ ./testRTSPClient rtsp://192.168.0.3:554/livestream
 
5. and then you can see many logs dump by testRTSPClient   

PJSIP -- compiled and execute in iOS simulator

為了要在 iOS 上實作 NAT Traversal 的功能,因此選擇了 PJSIP 當做參考資料,以下記錄實驗過程。

1. 下載程式
http://www.pjsip.org/download.htm,本次測試使用的版本為 version 2.0.1

FFMPEG -- Compile FFPLAY on MAC

FFMPEG won't compile ffplay be default. Below list the procedure to compile ffplay correctly.

1. Install MacPorts (v2.1.2)
Download from http://www.macports.org/,Choose the Mac OS version of your platform,download the dmg file and install.  After installed, we should update MacPorts to latest version, run below command.
$sudo port -fvds selfupdate

2013年1月27日 星期日

FFMPEG -- 編譯 ffmpeg library for iOS

本篇介紹如何在 MAC 環境下編譯 FFMPEG,並且使用 iphone simulator 進行測試。

文章中使用的軟體版本皆是 2013/01/27 時的最新版本:
  • Virtual Box 4.2.6 r82870
  • Mac OS X 10.8.2
  • Xcode 4.5.2
  • git 1.7.10.2
  • FFMPEG, checkout the latest version of Jan 27, 2013 
  • iFrameExtractor, checkout the latest version of Oct 21, 2012

轉載 -- Building FFmpeg for iPhone

轉載 http://blog.sina.com.cn/s/blog_51396f890102dyde.html,作者:观自己

事先申明,此文涉及所有代码、文档均为网上搜集整理,本人只做整合修改。目前我写的代码就归公司所有吧,不贴出来了。所有遇到问题,均从google上获得答案。可能需要翻*墙。
http://www.iphonedevsdk.com/forum/iphone-sdk-development/51697-rtsp-streaming-iphone-works-great.html该网页上下载iXen上传的rtspclient rtspsample代码。这两个代码都不能运行。稍作修改。把rtspclient中的RTSPClientSession.h RTSPClientSession.m添加到rtspsample中去。
参照http://www.cocoachina.com/bbs/read.php?tid-8466-page-1.html这里面制作静态库的方法,把live555的静态库加入进去。编译的时候会有一些小问题,稍加修改即可。这个时候,一个完整的rtsp客户端就ok了。

2013年1月24日 星期四

STUN -- RFC 3489 與 RFC 5389


本篇整理 RFC3489 RFC5389內容,針對STUN技術作一基本介紹,並將重點放在比較兩份規範之不同。

RFC3489 
STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
RFC5389 
Session Traversal Utilities for NAT (STUN)

2013年1月21日 星期一

ONVIF -- 重現錯誤的方式

在 client 與 server 的互通測試過程中,有時候客戶僅會使用我們所提供的client進行測試,但是卻不會想要讓我們擁有他們的server以自行進行測試。如此一旦遇到問題時,便只能夠靠 wireshark 封包來分析猜測可能原因。Debug工作將會變得非常不方便。

下面介紹的便是如何藉著 wireshark 封包的內容,讓問題重現。

2013年1月15日 星期二

ONVIF -- audio channel

許多 IPCAM 都支援了將聲音由 NVR 傳至IPCAM 的功能,ONVIF 組織針對此功能定義了一套標準作法,稱為 audio backchannel,首先會利用 AudioOutputConfiguration 內的 Send-Primacy 設定 audio in/out 方向,接著再使用 RTSP ,利用其擴充功能 "Require" 來傳送接收 audio stream。


根據 ONVIF 規範,我們將其分成兩部分來討論

2013年1月10日 星期四

RTSP -- Keep alive 的作法

用來實作 RTSP KeppAlive 的方法,大致上分成兩類。

1. 使用 RTSP method,例如:Play, GET_PARAMETER, SET_PARAMETER, OPTIONS
2. 使用 Receiver report RTCP packet


2013年1月9日 星期三

STUN協議簡介


轉載自 http://basiccoder.com/stun-protocal-introduction.html


STUN( Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs))是一种轻量级的协议,它允许应用程序发现它们和公网之间是否存在NATs和防火墙,并确定NATs和防火墙的类型。它也可以让应用程序确定NAT分配给它们的公网IP地址和端口号。STUN是一种client-server的协议,也是一种request-response的协议,STUN的默认端口是3478。

2013年1月8日 星期二

NAT -- 基本概念

NAT (Network Address Translation) 是用來解決IPv4位址不足的一個方法,當IP封包通過路由器或防火牆時,建立一個Private IP與Public IP的對應表格,並且重寫封包內的源IP地址或/和目的IP地址的技術。這種技術被普遍使用在有多台主機但只通過一個公有IP位址訪問網際網路的私有網路中。

IETF 定義的 Private IP如下:
  • Class A: 
    • 10.0.0.0/8 (255.0.0.0) 
    • 10.0.0.0 - 10.255.255.255
  • Class B: 
    • 172.16.0.0/12 (255.240.0.0)
    • 172.16.0.0 - 172.31.255.255
  • Class C: 
    • 192.168.0.0/16 (255.255.0.0)
    • 192.168.0.0 - 192.168.255.255

2013年1月7日 星期一

斷電時的檔案內容保護

當程式執行過程中,發生不預期的斷電,可能會讓正在寫入的檔案發生錯誤,當重新開機之後,系統便產生錯誤。

參考 POSIX 針對 rename() 函數的定義
if a power-cut happens during the re-naming, the original file will be intact because the re-name operation is atomic

NAT -- STUN 測試

近期因為工作上的需要,因此針對 NAT 技術做一粗略的了解,本篇將紀錄使用 STUN 的實驗過程。


STUN簡介

STUN 全名為 Simple Traversal of UDP Through Netwoek Address Translators,利用位於 Internet 上的伺服器幫助防火牆內的UA獲知他們被NAT 轉換過的外部位址, 並協助他人的VoIP呼叫穿透防火牆送達牆內的UA。很多應用層的 VoIP程式必須仰賴 UA 主動提供自身的IP 位址及port number, 讓VoIP兩端的UA 彼此知道對方的IP 位址及port number, 才能互送封包, 建立雙向的通話。但是如果UA 是在NAT 後面, 在沒有外部的協助下,一個UA 無法看到 它自己被NAT 轉換過的外部位址,就無法提供此項資訊,讓 VoIP順利運作。原理部分可參考http://www.cs.nccu.edu.tw/~lien/Writing/NGN/firewall.htm


網路上提供了許多免費的 STUN Server,如下:
  • stun.stunprotocol.org
  • stun.fwdnet.net
  • stun.fwd.org (no DNS SRV record)
  • stun01.sipphone.com (no DNS SRV record)
  • stun.softjoys.com (no DNS SRV record)
  • stun.voipbuster.com (no DNS SRV record)
  • stun.voxgratia.org (no DNS SRV record)
  • stun.xten.com
  • stun1.noc.ams-ix.net (DNS SRV record on domain ams-ix.net not noc.ams-ix.net)