JJC, Journal of Communication and Computer a citit lucrarea mea despre SIP si IMS.

A Solution for Secure SIP Conferencing over IMS and SAE

si vor sa o republice, din pacate nu prea se poate asta, desi nu m-ar deranja sa apara lucrarea in Library of U.S Congress (http://catalog.loc.gov/)

Dear Dr. CRISTINA,

These are Journal of Communication and Computer (ISSN: 1548-7709, USA) & Computer Technology and Application (ISSN: 1543-7332, USA).

We have read your excellent paper ‘ A Solution for Secure SIP Conferencing over IMS and SAE ‘ from ‘The 4th EUROPEAN COMPUTING CONFERENCE (ECC ’10)‘ and we are pleased to pass on our regards to you. We are very interested in your research, if the paper mentioned has not been published in other journals or you have other unpublished papers in hand and have the idea of making our journals a vehicle for your research interests, please feel free to send electronic version to us.

JCC & CTA are collected and indexed by the Library of U.S Congress, on whose official website (http://catalog.loc.gov) an on-line inquiry can be triggered with their publication number, ISSN1548-7709 & ISSN1543-7332, as key words in “Basic Search” column. The journals are also retrieved by some renowned databases:

«     Database of EBSCO, Massachusetts, USA

«     Chinese Database of CEPS, American Federal Computer Library Center(OCLC), USA

«     Database of Cambridge Science Abstracts (CSA), USA

«     Ulrich’s International Periodicals Directory, USA

«     Summon Serials Solutions

In addition, JCC is also retrieved by Chinese Scientific Journals Database, VIP Corporation, Chongqing, China

Tags: IMS, me happy, passion, sip, techie

This is a summary of what I hope to be able to describe in the next several posts: the establishment of a basic SIP-IMS call flow, in a somewhat interesting scenario: when both Alice and Bob are in roaming.

Each of the participants talks to his/her own P, S and I servers. Here the presumption is that Alice is the one making the phone call.

Tags: 4G, Diameter, eNodeB, EPC, HSS, I-CSCF, IMS, loose routing, LTE, MME, P-CSCF, passion, PCRF, PGW, PRACK, Register, S-CSCF, SGW, sip, strict routing, techie, UE

“c1″ because…mwell, because “a” was the register and 4G/IMS architecture, “b” was the OpenIMSCore and “c” should be an actual call flow.

Unfortunately, I cannot show you the actual 4G encapsulation, because I don’t have any tool to emulate that, but, as we’ve understood from the registration flow, each IMS message coming from or going to the IMS mobile device will be encapsulated in GTPv1-u header between the eNodeB, SGW, PGW and then forwarded, without the GTPv1-u encapsulation, to the P-CSCF. Juuust as for the Register flow…

Oook, now let’s take a look at the IMS-SIP call flow. Basically, what I’m going to show here is a Basic Call with Voice.

Now, the most basic SIP (Session Initiation Protocol) call flow has the following structure:

Basically, Alice sends an INVITE message to Bob (via a sip proxy server or directly), inviting Bob to a voip message exchange, and also sending in the SDP (Session Description Protocol) header (presented as a SIP message body), the RTP (Real-Time Protocol) codecs that Alice’s phone is supporting. 1xx is provisional messaging. 100 Trying and 180 Ringing is a good sign, they mean I am actually contacting Bob, I am just waiting for him to pick-up the phone. When he does that, his device signals a 200 OK (sending in this message also the RTP codecs known by Bob’s device), and Alice’s device Acknowledges. Now the RTP session can begin, with one of the matching codecs. Once the two guys finish talking, Alice’s phone (usually) is the one signaling the end of the conversation, by sending a BYE message to Bob, and this one acknowledges. Alice can also send her supported RTP codecs barely in her ACK message, procedure called late negotiation.

Now, this may rightfully seem simple enough, but wait! We haven’t yet got to the IMS part

The same “basic” SIP call flow in the IMS context would look like this (of course, excluding the 4G encapsulation which we’ve agreed we understand):

In the next chapter I’ll detail these messages.

For the moment, let’s just observe the presence of a weird new message called PRACK. The PRACK is defined in RFC3262: Reliability of Provisional Responses in the Session Initiation Protocol (SIP). The RFC 3262 states:

   The PRACK request plays the same role as ACK, but for
   provisional responses.  There is an important difference, however.
   PRACK is a normal SIP message, like BYE.  As such, its own
   reliability is ensured hop-by-hop through each stateful proxy.  Also
   like BYE, but unlike ACK, PRACK has its own response.  If this were
   not the case, the PRACK message could not traverse proxy servers
   compliant to RFC 2543 [4]."

I believe the IETF guys are pretty explanatory

See you in the next chapter.

Tags: 4G, Diameter, eNodeB, EPC, HSS, I-CSCF, IMS, loose routing, LTE, MME, P-CSCF, passion, PCRF, PGW, PRACK, Register, S-CSCF, SGW, sip, strict routing, techie, UE

WSEAS journals

http://www.wseas.us/e-library/transactions/communications/2010/89-825.pdf

A Solution for Secure SIP Conferencing over IMS and SAE

CRISTINA Bucharest, ROMANIA <email>

Abstract: Over the latest few years, most of the major telephony and services providers have got their attention on the LTE/SAE solution, in the attempt of getting the most bandwidth and features at the least implementation and operating price. One of the major challenges that 3GPP, the creator of LTE/SAE architecture, has faced is the IMS integration with SAE. The latest standard version available at this moment on IMS integration and its security challenges is TS 33.203, which is focused on 3G security aspects. When talking about IMS- SIP security, there are several studies that propose end-to-end security for a SIP conversation over EPS infrastructure.

This paper reviews the security issues that resides in the SAE-IMS interaction and, looking at the specificities of the SIP conferencing, proposes a security model that uses GDOI management to secure the SIP conference data over IMS and SAE. One important aspect of conferencing in the mobile world is to realize the user is never stationary. One chapter of this paper describes the most complicated type of mobility scenario and also introduces the role of the Diameter server into this architecture.

Keywords: SAE, LTE, EPS, EPC, IMS, security, SIP, conference, GDOI, GCKS, IPsec, key management

Tags: conference, gdoi, IMS, ipsec, LTE, SAE, security, sip, techie

I am inviting you to visit one of my favorite sites:

http://tech-invite.com/

The reason this is one of my favorite sites is that it is, firstly, VERY TECHNICAL of course. There are several sections where the articles are placed: Organizations, Standardization work, IETF topics, 3GPP topics, ETSI topics and…Other topics. I have to thank my VoIP guru colleague Alin for telling me about this site.

To be honest, I’ve never used any other categories, other than 3GPP and IETF topics. But these ones I have used extensively. Ranging from packet by packet IPsec negotiation, to SIP headers description, example, and a lot of scenarios, database infrastructure to UMTS and SAE architecture and scenarios, with a very welcome RFC and TS classification, I believe this site is one of the best locations where one could go to clarify technical things, to view scenarios and to take a look at packets and headers along with their analysis.

The latest link I’ve used is a secure SIP basic call from roaming, using the IMS architecture over UMTS. There are diagrams with each step of the flow, the packet dump and explanations for each packet. Gold, I say

So take a look.

Tags: IMS, ipsec, passion, sip, tech-invite, techie

I’ve been searching for some old e-mails from a few years ago, trying to find a missing contact and bumped into this…

The initial instructions were something like this: ” so, it needs to call a person, play the wav and wait for dtmfs until the guy presses #.; afterwards play another wav and hang up”. I was young (and restless ), not sure I’ve covered the request completely, but I was doing this:

- picked-up good old asterisk server and abused its sip.conf extension:

; my users

Tags: asterisk, pbx, sip, techie, voicemail