[Serusers] SIP to AS communication

Mon Oct 9 14:45:20 CEST 2006

Hi Greger,

We were planning on creating a separate project on berlios for the IMS 
stuff. So far we still have to figure out what you said, how to package 
it together with SER so that we have the latest version of SER but also 
the modules stable with that.

FHoSS has Cx and Sh support. The Diameter support is provided through 
our JavaDiameterPeer libraries that inter-operate properly with the 
CDiameterPeer ones, in SER. We also had a series of successful 
interoperability trials with other Diameter stacks. However, at the 
moment the Diameter protocol is not implemented 100% (for example, there 
is no SCTP support for now), but the set in there is sufficient for IMS.

Yes, IPSec is not compatible with NAT. From an operator's point of view, 
IMS does not make too much sense if you don't control the Access Network 
because of the most hyped thing in IMS, QoS. Anyway, IPSec is optional 
now and transparent if your client does not use it.

TLS was not yet tested. I still have to write the "glue" with the pcscf 
module in order to exchange the keys. It was just an idea, but I haven't 
found anything standardized anywhere about IMS+TLS and I was waiting a 
little for that.

On this topic, some parts of other modules are pasted in. For example 
the pcscf includes some nathelper functionality. I know that the best 
thing would have been to just use the nathelper module, but the pcscf 
has its own reversed-registrar, as usrloc is not suitable.

And this is not the only thing, so I think that in the first months we 
will have to do some accommodation work on both sides in order to have 
an easily maintainable tree.

So far I know that you will be interested. Anybody else?

Cheers,
Dragos

Greger V. Teigre wrote:
> Hi Dragos,
> Thanks for your update on the project. Really interesting stuff!
> An idea: Once we release 0.10, maybe we could create a tar package 
> with an "IMS version" of SER, where the modules are included, maybe 
> some extra docs, etc.  Or are you planning to make available the IMS 
> modules as part of 0.10??
>
> FHoSS sounds interesting, is that a full-flegded Diameter server 
> according to HSS specification??  Are there any peculiarities that 
> make it non-suitable for general Diameter use (i.e. non-IMS)?
>
> To IPsec: To me the IPsec requirement is a typical aspect of the 
> carrier-centric approach of IMS. Supposedly both IPv4 and v6 can be 
> run independently and together, but the NAT-traversal issues with 
> IPsec is maybe even more difficult than for SIP (believe me, I have 
> spent lots of time on both...). I haven't been able to test my Nokia 
> E70 SIP client's IPsec NAT traversal capabilities yet (as I don't have 
> testing access to an IMS proxy :-).  On 3G I presume most carriers 
> have non-NATed networks, but the E-series has WiFi capabilities and 
> one of the things trumpeted with IMS is the cross-access-network 
> nature of IMS services.
> Have you tried TLS in 0.10 the way you describe?
>
> g-)
>
> Dragos Vingarzan wrote:
>> ...This is re-post, because the previous one was sent from the wrong 
>> mail-address and now it awaits moderations... sorry for duplicates if 
>> eventually it gets accepted.
>>
>> Hi all,
>>
>> Yes, IMS is quite bloated. However, for the past years we did some 
>> work at FOKUS related to it and it will be soon released. It does not 
>> have ALL what IMS demands, but it is a start and we hope that you 
>> guys, if you think that something more is required, could help us 
>> achieve that.
>>
>> I am attaching the proof that it will be, on 16.11.2006 (it is also 
>> an invitation for you to participate, but I am not making publicity 
>> on this list ;-) http://www.fokus.fraunhofer.de/event/ims_ws_06/ ). 
>> If you need further info, feel free to contact us.
>>
>> To offer you some info about it before this date, we will release a 
>> bundle of modules:
>> - cdp - for efficient diameter communication in SER (stands for 
>> CDiameterPeer)
>> - pcscf - implementing some of the P-CSCF functionality
>> - icscf - -//- ICSCF
>> - scscf- -//- SCSCF
>> - isc - for Initial Filter Criteria Triggering and communication 
>> between S-CSCF and AS
>> - sip2ims - a simple MD5 to AKA authorization gateway
>>
>> All these modules at the moment are relatively stable on SER 
>> 0.10.99-dev41. But the problem there is that the diameter 
>> functionality is integrated into the core. We are working now on 
>> stabilizing the cdp as a module in 0.10.99-dev45. Once we succeed, I 
>> hope that the modules will be usable with any new plain-CVS SER release.
>>
>> Also, we will give away FHoSS - our Java HSS implementation together 
>> with the included pure Java - Java Diameter Peer - diameter 
>> functionality.
>>
>> So, you will have a basic IMS system to play with. Almost the same 
>> Open IMS Core is used in the ETSI/TISPAN IMS Benchmarking effort as a 
>> reference implementation for the System Under Test (look for WorkItem 
>> 06024).
>>
>> Don't expect too much, but at least now we have full Cx support, 
>> Initial Filter Criteria triggering, ISC support, AKA authentication, 
>> IPSec in transport mode with clients, etc... and all this plus the 
>> wonderful SER script functionality.
>>
>> Oh yeah :)... and don't expect carrier-grade quality though. These 
>> are research projects and we care more about experimenting with the 
>> latest features than the 99.999%. For that stability, as Jiri 
>> implies, Tekelec probably has (or will have) a good solution, but we 
>> can't do that as our budgets are much lower than those of the SPs or 
>> TEMS.
>>
>> As Andrey pointed out, we are not the only ones doing this, but I 
>> hope that we could converge.
>>
>> And Jiri is right about the complexity. There are at least 4 
>> components that have to work together. For SigComp, because of it's 
>> complexity, I was considering TLS with compression. This could also 
>> replace the IPSec transport mode tunnel for security, which could be 
>> difficult on some embedded devices. Any thoughts on this? Anyway, 
>> SigComp is asked mainly by the mobile operators only and we should not .
>>
>> Looking forward for you comments,
>> Dragos Vingarzan
>>
>> Jiri Kuthan wrote:
>>> Just a warning small in size but I guess big in the impact. I think 
>>> people kind of underappreciate the effort which has to be taken. If 
>>> you consider all the 3gpp complexity (sigcomp as a prime example, 
>>> one of many being real non-trivial), size of mobile networks for 
>>> which the system has to be running, number of interfaces to speak 
>>> over and achieve interoperability (management, diameter, 
>>> applications,  cdr processing...), routing features (the 'scim' 
>>> feature with
>>> which this discussion began)...
>>>
>>> I occur to know Tekelec has gone through this exercise and generating
>>> a reasonable result has cost quite an investment.
>>>
>>>
>>> At 07:19 06/10/2006, Andrey Kuprianov wrote:
>>>  
>>>> Hi, I suppose you need to develop modules for all the the x-CSCF + 
>>>> AS (where x-CSCF is P-CSCF, S-CSCF or I-CSCF). You see, the 
>>>> functionalities/features that x-CSCF and application servers 
>>>> require (for instance, P-headers or querying for subscriber 
>>>> information from HSS) are not available in SER. That's why you need 
>>>> to make your own modules *all the way*. As for HSS, i dont think 
>>>> you need to make some special super DIAMETER-enabled database. In 
>>>> my (an in many other people's btw) point of view a simple database, 
>>>> like MySQL is more than capable of storing subscriber info or 
>>>> initial filtering criterias (iFC --> im talking about SCIM/SIMF). 
>>>> If you are really set to develop IMS on SER, then maybe you can 
>>>> start with SER 0.8.14. You can still find decent development 
>>>> documentation for it. As for later versions, I dont think any good 
>>>> docs are yet available (someone, please, correct me if im wrong)     
>>>
>>> The documentation is being worked on, but for the moment you are 
>>> unfortunately correct.
>>>
>>>  
>>>> Just for your info, INT (France) joint with France Telecom are 
>>>> developing IMS on SER as of now (dont know if it's going to be 
>>>> commerial or open-source. Contact them if you are interested, maybe 
>>>> you can even help them develop it further :). Plus, Focus is also 
>>>> set to develop a commercial version of IMS for SER and, although, 
>>>> Focus said that their IMS will be available in the last quarter of 
>>>> this year, but nothing's been released yet. :(
>>>>     
>>>
>>> That's fantastic news, I'm looking forward to GPL contributions from 
>>> these
>>> very respectable institutions. This is really a big piece of work 
>>> and I am
>>> enormously positive about every single new piece of the puzzle.
>>>
>>> -jiri
>>>
>>>  
>>>>   Good luck,     Andrey. On 10/6/06, Kamal.Mann at t-systems.com 
>>>> <Kamal.Mann at t-systems.com> wrote: > Hi All > We are using SER as 
>>>> CSCF which communicates with HSS and Application Server. > 
>>>> ï‚§       Whenever a UA sends a request to SER then it should go to 
>>>> some specific table and look for services assigned to that 
>>>> particular UA. > ï‚§       If UA is authorize to use that service 
>>>> than SER send this to AS. > ï‚§       AS then send this 
>>>> request/response to Serving SER (S-CSCF) which further serves that 
>>>> UA. > I need your suggestions for the same that what kind of module 
>>>> we need to develop for this scenario or any valuable suggestions. > 
>>>> > Thanks in anticipation > Kamal Mann > > 
>>>> _______________________________________________ > Serusers mailing 
>>>> list > Serusers at lists.iptel.org > 
>>>> http://lists.iptel.org/mailman/listinfo/serusers > > > </x-flowed>
>>>> _______________________________________________
>>>> Serusers mailing list
>>>> Serusers at lists.iptel.org
>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>     
>>>
>>> -- 
>>> Jiri Kuthan            http://iptel.org/~jiri/
>>> _______________________________________________
>>> Serusers mailing list
>>> Serusers at lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>>   
>>
>>
>

-- 
-----------------------------------------
Dipl. Eng. Dragos Vingarzan
FOKUS/NGNI
Kaiserin-Augusta-Allee 31
10589 Berlin,Germany
Phone +49 (0)30 - 3463 - 7385
Mobile +49 (0)163 - 159 - 5221
eMail vingarzan at fokus.fraunhofer.de
Web www.fokus.fraunhofer.de
We could change the world if God would give us the source code...
-----------------------------------------------------------------