Affichage des articles dont le libellé est doubango. Afficher tous les articles
Affichage des articles dont le libellé est doubango. Afficher tous les articles

mardi 15 mai 2012

World's first HTML5 SIP client

After the world's first SIP video clients for Android and iOS (early 2009) we are proud to present sipML5 Project. sipML5 is the world's first open source HTML5 SIP client entirely written in javascript for integration in social networks (FaceBook, Twitter, Google+), online games, e-commerce websites... No extension, plugin or gateway is needed. The media stack rely on WebRTC project. The client can be used to connect to any SIP or IMS network from your preferred browser to make and receive audio/video calls and instant messages.

Short but not exhaustive list of supported features:

  • Audio / Video call
  • Instant messaging
  • Presence
  • Call Hold / Resume
  • Explicit Call transfer
  • Multi-line and multi-account
  • Dual-tone multi-frequency signaling (DTMF) using SIP INFO
For more information: http://www.sipml5.org
Call between Google Chrome and iPad device
Call between Google Chrome and Android device

mardi 20 septembre 2011

iDoubs for MAC OS X

We are proud to announce the availability of the first alpha release of iDoubs for MAC OS X 10.6+ (Snow Leopard).
This alpha release (1.0.0) comes with many features:- IPv4 and IPv6
- UPD, TCP and TLS transports
- Audio codecs: G.722 HD audio, Speex, and G.711
- High quality audio: AEC (based on WebRTC), Noise suppression, Adaptive jitter buffer ...
- Video codecs: VP8, H.264, H.263 and MP4V-ES
- Multiline calls
- Hold/Resume
- Media update
- …and many other features



For more information: http://code.google.com/p/idoubs


mardi 15 février 2011

OpenVCS - Open Source VideoConferencing Server

We are proud to announce the availability of the first alpha release of OpenVCS.
OpenVCS stands for Open Source Video Conferencing Server and uses SIP (RFC 3261, 3GPP TS 24.229) protocol.
OpenVCS is used as a Multipoint Control Unit (MCU) manager. The application can managed any number of MCU (a.k.a Bridge) where each Bridge can support up to 64 participants.

The application can be used as a standalone SIP server or behind an IMS Core where each Bridge will be seen as an AS (Application Server).
You can use any SIP compliant device to connect to a bridge as long as the client is RFC 3261 compliant. For example, you can use IMSDroid on Android, iDoubs on iOS (iPhone, iPod Touch or iPad), Boghe on Windows or Linphone/Bria on MAC OS X or Linux.



For more information: http://code.google.com/p/openvcs/

lundi 20 décembre 2010

Boghe - IMS/RCS Client for Windows

We are proud to announce the availability of the first alpha release of Boghe, our IMS/RCS client for Windows XP, Vista and 7.



For more information: http://code.google.com/p/boghe/

vendredi 2 octobre 2009

SMS over 3GPP IMS Network

SMS stands for Short Message Service or Silent Messaging Service and is a communication service standardized in the GSM mobile communication system, using standardized communications protocols allowing the interchange of short text messages between mobile telephone devices.

SMS technology has been specified by the ETSI in GSM 03.40 and 03.38 documents (3GPP TS 23.040 and 3GPP TS 23.038 respectively). These documents only describe how to use SMS over mobile networks (nothing for IP networks).
In real world there are two way to receive SMS messages over mobile networks: Binary (PDU) and Text mode.
In this post I will explain how to use SMS technology over IP within the IP Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP) and SIP Events as defined in 3GPP TS 24.229.
Note: In the coming chapters, « SMS over IMS Network » and « SMS over IP Network » have the same meaning.

Text mode

The message payload is transfered « as is ». This mode is out of scope.

Binary mode

Also know as PDU (Protocol Data Unit) mode, it is use to encode the payload of the SMS sent over IMS networks. In this case the payload only contains a sequence of hexa-decimal octets or decimal semi-octets strings. The overall PDU string contains some useful information (SMSC address, Service center time stamp, sender number, message reference ...) plus the actual message.

The message length can be up to 160 characters where each character represent 7bits [160/7bits], [140/8bits] or [70/16bits]. By default, each character represent 7bits encoded as per GSM 03.38.
For IMS Networks, SMS message shall be encapsulated in RPDUs (Relay Protocol Data Unit) data string as defined in 3GPP TS 24.011, subclause 7.3. The RPDU data is transfered from SM entity to SM entity using SIP MESSAGE requests. These SIP requests shall use the MIME type "application/vnd.3gpp.sms" for this purpose.

GSM 7 bit Default Alphabet

Each character represent 7bits. For more information see 3GPP TS 23.038 or ETSI GSM 03.38.

Figure 1: GSM 7bit alphabet

3GPP IMS Registration

On sending a REGISTER request, the IMS Client shall indicate its capability to receive traditional short messages over IMS network by including a "+g.3gpp.smsip" parameter into the Contact header according to RFC 3840.

Figure 2: SIP/IMS registration request

Mobile-Originated SMS (MO-SMS)


The IMS Client sender shall build and populate RP-DATA message (RPDU encapsulating TPDU data string), containing all the information that a mobile station submitting an SMS message according to 3GPP TS 24.011 would place, for successful delivery. The sender shall parse and interpret RP- DATA, RP-ACK and RP-ERROR messages, containing all the information that a mobile station receiving an SM according to 3GPP TS 24.011 would see, in a SM submission or status report.



Figure 3: Signaling flows demonstrating successful UE originated SM submit procedure over IP as per 3GPP TS 24.341

** [1,2,4] RP-DATA (SMS-SUBMIT)

Below is represented the first request (RP-DATA(SMS-SUBMIT)) sent from the IMS Client to the P-CSCF.

Figure 4: RP-DATA(SMS-SUBMIT) from Mercuro to the P-CSCF

The SIP MESSAGE (Figure 4) request sent from the IMS client to the P-SCSF carry the RP-DATA (Mobile station to IMS Network) message encoded as per 3GPP TS 24.011 chapter 7.3.1.2.

Figure 5: RP-DATA (Mobile Station to Network) as per 3GPP TS 24.011 subclause 7.3.1.2

The SIP MESSAGE content (Figure 4) can be dissected as following:

RP-MESSAGE: 000000069133010000F019069133010000F011000A9133163254760000AA05F330BB4E07
RPDU:000000069133010000F019
TPDU (SMS-SUBMIT):069133010000F011000A9133163254760000AA05F330BB4E07

The RP-MESSAGE can be dissected as follow (Figure 6):

Figure 6: RP-DATA (Mobile Station to Network) content dissection

** [9,10,11] RP-ACK(SMS-SUBMIT-REPORT)

The SIP MESSAGE payload includes the RP-ACK message. Its RP-User-Data information element includes a TPDU of type SMS-SUBMIT-REPORT.

Figure 7: RP-ACK as per 3GPP TS 24.011 subclause 7.3.3

RP-MESSAGE:020009069133163254760080

For more information, see 3GPP TS 24.011 subclause 7.3.3 for RPDU (RP-ACK) data and 3GPP TS 23.040 subclause 9.2.2.2a for TPDU (SMS-SUBMIT-REPORT) encoding. If error occurs when decoding the message, RP-ERROR (3GPP TS 24.011 subclause 7.3.4) message is sent instead of RP-ACK.

Mobile-Terminated SMS (MT-SMS)

Figure 8: UE originated SM deliver procedure over IP signaling as per 3GPP TS 24.341

** [2,3,4] RP-DATA(SMS-DELIVER)


This request sent from the IP-SM-GW includes a vnd.3gpp.sms payload that includes the short message and routing information for the S-CSCF to forward the short message.

The payload includes the RP-DATA message. Its RP-User-Data information element includes a TPDU of type SMS-DELIVER.

Figure 9: RP-DATA (Network to Mobile Station ) as per 3GPP TS 24.011 subclause 7.3.1.1

RP-MESSAGE: 0100069133010000F0001E069133010000F0040A91331632547600000000000000000005F330BB4E07

For more information, see 3GPP TS 24.011 subclause 7.3.1.1 for RPDU (RP-DATA) data and 3GPP TS 23.040 subclause 9.2.2.1 for TPDU (SMS-DELIVER) encoding.

** [8,9,11] RP-ACK(SMS-DELIVER-REPORT)

This request includes a vnd.3gpp.sms payload that includes the SMS-DELIVER-REPORT and routing information for the IP-SM-GW to forward the delivery report.
The payload includes an RP-ACK message. Its RP-User-Data information element includes a TPDU of type SMS-DELIVER-REPORT.

RP-MESSAGE:020109069133163254760080

For more information, see 3GPP TS 24.011 subclause 7.3.3 for RPDU (RP-ACK) data and 3GPP TS 23.040 subclause 9.2.2.1a for TPDU (SMS-DELIVER-REPORT) encoding.
If error occurs when decoding the message, RP-ERROR (3GPP TS 24.011 subclause 7.3.4) message is sent instead of RP-ACK.

References:

mercredi 31 décembre 2008

IPSec using Security Agreement (in 3GPP R5)

In this post I will try to explain how security mechanisms are negotiated between an IMS Client and the Proxy CSCF (only SIP headers) and how to setup SAs using Linux IPSec tools.
The main purpose of Security agreement is to agree on which mechanisms, algorithms or security parameters to use.

There are five main mechanisms used in VoIP networks:
  1. digest
  2. tls
  3. ipsec-ike
  4. ipsec-man
  5. ipsec-3gpp

We will focus on 3GPP IPSec because the IMS makes it mandatory.

The security mechanism to use is known after the negotiation between the IMS Client and the Proxy CSCF succeeds. This negotiation is performed during the IMS registration and authentication procedures.

Three new SIP header fields have been defined, namely Security-Client, Security-Server and Security-Verify.


Call Flow

IMS Client         P-CSCF              S-CSCF
|                    |                  |
|----(1)REGISTER---->|                  |
|                    |                  |
|                    |---(2)REGISTER--->|
|                    |                  |
|                    |<-----(3) 401 ----|
|                    |                  |
|<----(4) 494/401----|                  |
|                    |                  |
|<==IPSec in place==>|                  |
|                    |                  |
|----(5)REGISTER---->|                  |
|                    |----(6)REGISTER-->|
|                    |                  |
|                    |<---(7) 200 OK----|
|<---(8) 200 OK------|                  |
|                    |                  |

In step (1) the IMS Client sends an unprotected registration request including the security-client header. The Client must indicate that it is able to negotiate security mechanism by adding “Require” and “Proxy-Require” headers. The security-client header includes two ports (client and server ports) that the client wants to negotiate with the proxy CSCF.

In step (2) the Proxy CSCF forwards the request to the Serving CSCF.

In step (3) the Serving CSCF (registrar) challenges the Proxy CSCF. The 401 response is sent to the Proxy CSCF (challenge parameters are under WWW-Authenticated header). The Serving CSCF must include the security-server header.

In step (4) the Proxy CSCF forwards the 401/494 response to the IMS Client. At this stage the Proxy CSCF opens the IPsec security association (SA) for the IMS Client. The IMS Client also setup a SA (this is a temporary SA).

The lifetime of the created SA (between the IMS Client and the Proxy CSCF) is equal to the value of reg-await-auth timer.

In step (5) the IMS Client sends a new registration (to the Proxy CSCF) request including its credentials and copies the content of security-server header to the security-verify header. Before forwarding the request to the Serving CSCF, the Proxy CSCF will check that the previous security-server header and the security-verify headers (added by the IMS Client) are the same. If these values are different, the Proxy CSCF sends an error message to the IMS Client and terminates the created SAs.

In step (6) the Proxy CSCF forwards the request to the Serving CSCF.

In step (7) the Serving CSCF authenticates the IMS Client, and responds with 200 OK.

In step (8) the Proxy CSCF forwards the response to the IMS Client. At this step new SAs will be created. The temporary SAs will be destroyed (or not) by the Proxy CSCF.


Messages

(1)
REGISTER sip:pcscf.open-ims.test SIP/2.0
Security-Client: ipsec-3gpp; alg=hmac-md5-96; spi-c=1111; spi-s=2222; port-c=5062; port-s=5064
Require: sec-agree
Proxy-Require: sec-agree

(4)
SIP/2.0 [494 Security Agreement Required / 401 Unauthorized]
Security-Server: ipsec-3gpp; q=0.1; alg=hmac-md5-96; spi-c=3333; spi-s=4444; port-c=5066; port-s=5068

(5)
REGISTER sip:pcscf.open-ims.test SIP/2.0
Security-Client: ipsec-3gpp; alg=hmac-md5-96; spi-c=1111; spi-s=2222; port-c=5062; port-s=5064
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-md5-96; spi-c=3333; spi-s=4444; port-c=5066; port-s=5068
Require: sec-agree
Proxy-Require: sec-agree

--> Captures done with Mercuro IMS Client.

Setting up SAs using Linux Tools

Here we suppose that:
- We are using Ubuntu (Linux Kernel 2.6 + KAME-tools)
- the Proxy-CSCF address is '192.168.0.10' and Mercuro IMS Client address is '192.168.0.11'
- for secure ports see above SIP capture
- protocol is esp
- algorithm is 'hmac-md5'
- encrypt-algorithm is 'des-ede3-cbc'
- mode is 'transport'
- confidentiality key is '123456789012123456789012' (see function f2345 in 3GPP milenage algorithms)
- integrity key is '1234567890123456' (see function f2345 in 3GPP milenage algorithms)

1. Install the tools

sudo apt-get install ipsec-tools

2. Edit /etc/ipsec-tools file and add the following script

#Incoming Requests [US <- PC]

spdadd 192.168.0.10/32[5066] 192.168.0.11/32[5064] udp -P in ipsec esp/transport//require;
add 192.168.0.10 192.168.0.11 esp 2222 -m transport -E des-ede3-cbc "123456789012123456789012" -A hmac-md5 "1234567890123456";

#Incoming Replies [UC <- PS]
spdadd 192.168.0.10/32[5068] 192.168.0.11/32[5062] udp -P in ipsec esp/transport//require;
add 192.168.0.10 192.168.0.11 esp 1111 -m transport -E des-ede3-cbc "123456789012123456789012" -A hmac-md5 "1234567890123456";

#Outgoing Requests [UC -> PS]
spdadd 192.168.0.11/32[5062] 192.168.0.10/32[5068] udp -P out ipsec esp/transport//unique:1;
add 192.168.0.11 192.168.0.10 esp 4444 -m transport -u 1 -E des-ede3-cbc "123456789012123456789012" -A hmac-md5 "1234567890123456";

#Outgoing Replies [US -> PC]
spdadd 192.168.0.11/32[5064] 192.168.0.10/32[5066] udp -P out ipsec esp/transport//unique:2;
add 192.168.0.11 192.168.0.10 esp 3333 -m transport -u 2 -E des-ede3-cbc "123456789012123456789012" -A hmac-md5 "1234567890123456";


3. Run the script

sudo /etc/init.d/setkey start

The same can be done under Windows vista using WFP(Windows Filtering Platform) API. For more information on How IPSec (in IMS context) feature could be implemented under Windows you can contact Mercuro Team at [tech dot mercuro -at- inexbee dot com].

For more information visit:
http://www.mercuro.net
http://www.ietf.org/rfc/rfc3329.txt
http://www.arib.or.jp/IMT-2000/V310Sep02/T63/Rel5/33/A33203-520.pdf
http://www.arib.or.jp/IMT-2000/V310Sep02/S3g/Rel5/24/24229-510.pdf
http://www.3gpp.org/FTP/TSG_SA/WG3_Security/TSGS3_24_Helsinki/Docs/PDF/S3-020385.pdf

mercredi 10 septembre 2008

Free IMS Clients


  • IMSDroid, for Android
  • iDoubs, for iOS (iPhone, iPad and iPod Touch)
  • The UCT IMS Client is available under the GPL (open source)
  • The IMS Communicator is available under the GPL (open source)
  • FOKUS' OpenIC (Open IMS Client) is available only commercially. Yet, there is also a free binary OpenIC_Lite version available right here