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@t-systems.com Kamal.Mann@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@lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > > > </x-flowed> _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
...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@t-systems.com Kamal.Mann@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@lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > > > </x-flowed> _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@t-systems.com Kamal.Mann@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@lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > > > </x-flowed> _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@t-systems.com Kamal.Mann@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@lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > > > </x-flowed> _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Dragos Vingarzan wrote:
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.
Hi Dragos!
Is it really necessary for the PCSCF to have a location table? I thought the Path: extension will take care of routing incoming calls to the clients and stateless proxies can be used as PCSCF.
btw: do you have added support for the Path extension?
regards klaus
Hi Klaus,
Yes, it is quite necessary. The P-CSCF's main functionality is to firewall the home domains. As such, it has to maintain a registrar for those users and that has to be a reversed one - it is not resolving identities to contacts but contacts to identities. This registrar is kept in sync with the one on the S-CSCF by P-CSCF subscribing to the "reg" event at the S-CSCF (see RFC3680).
Also it is responsible for the securing the communication with each individual client and of course for making sure that all UEs play nice by following Service-Routes and Record-Routes and by not injecting any attack traffic into the IMS core network.
The path extension is there already. On the P-CSCF it's a matter of adding it to REGISTER. Then the S-CSCF uses it when routing any requests towards the P-CSCF and the P-CSCF uses it to identify the session case. The processing of requests is quite twisted and my config files are already quite long.
Also adding more things to the Path is possible, like a Topology Hiding node, used to hide the information from the visited network.
-Dragos
Klaus Darilion wrote:
Dragos Vingarzan wrote:
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.
Hi Dragos!
Is it really necessary for the PCSCF to have a location table? I thought the Path: extension will take care of routing incoming calls to the clients and stateless proxies can be used as PCSCF.
btw: do you have added support for the Path extension?
regards klaus
Dragos Vingarzan writes:
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.
well, i just heard that in current 3g networks pdp contexts with different QoSes have not been implemented at all. neither does QoS pdp context support in 3g phones.
what comes to ims in general, i don't see it having any chance of success, because it locks users into walled gardens. this, of course, doesn't prevent the community from developing IMS features in ser, but i would feel that much more relevant would be to focus on XMPP/SIP integration.
even if ser would include full IMS support, what would the use case be? mobile operators are not likely to deploy third party IMS solutions, because they are locked to their mobile vendor.
-- juha
That is relative. Almost all new mobile phones support now also WiFi ,so it is not only about UMTS and what the phones are implementing by default. Both Symbian and Windows Mobile are capable of running IMS soft-clients on top. And let's not forget TISPAN's NGN and the fixed networks.
About the walled garden, well, no operator would give to end-users QoS control because simply it would just cost too much and nobody would afford it. As such, I do not see any opened solutions.
Then we could just take 90% of these IMS modules and brand them as "Diameter SIP Application". It's practically the same thing and you get a nice network architecture with great scalability properties.
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-12.txt
But you would miss the Application Server thing, with the possibility of easily enabling per-user functionality. Sure that you can do this now from the SER script, but the effort of maintaining it dynamic, per user and with the AS having access to the subscriber data is just huge. In my opinion SER's script is great for managing things at the SIP level, but once you build applications on top, you just want to abstract from that. And let's not forget the standardization aspect - any IMS core network should be able to use and standard IMS Application Servers.
The target use case? I would just say: same as until now ;-). Plus that any Service Provider is looking into IMS as a possibility to get out of the provider lock by asking for interface-standard components and avoiding black-box solutions. As such, SER is great as experimentation toy.
-Dragos
Juha Heinanen wrote:
Dragos Vingarzan writes:
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.
well, i just heard that in current 3g networks pdp contexts with different QoSes have not been implemented at all. neither does QoS pdp context support in 3g phones.
what comes to ims in general, i don't see it having any chance of success, because it locks users into walled gardens. this, of course, doesn't prevent the community from developing IMS features in ser, but i would feel that much more relevant would be to focus on XMPP/SIP integration.
even if ser would include full IMS support, what would the use case be? mobile operators are not likely to deploy third party IMS solutions, because they are locked to their mobile vendor.
-- juha
Dragos Vingarzan writes:
Then we could just take 90% of these IMS modules and brand them as "Diameter SIP Application". It's practically the same thing and you get a nice network architecture with great scalability properties.
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-12.txt
what scalability advantages does diameter give you over radius?
But you would miss the Application Server thing, with the possibility of easily enabling per-user functionality. Sure that you can do this now from the SER script, but the effort of maintaining it dynamic, per user and with the AS having access to the subscriber data is just huge. In my opinion SER's script is great for managing things at the SIP level, but once you build applications on top, you just want to abstract from that. And let's not forget the standardization aspect - any IMS core network should be able to use and standard IMS Application Servers.
what are those applications that ASes handle? why can't i put users' application info into radius raply table?
-- juha
Juha Heinanen wrote:
Dragos Vingarzan writes:
Then we could just take 90% of these IMS modules and brand them as "Diameter SIP Application". It's practically the same thing and you get a nice network architecture with great scalability properties.
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-12.txt
what scalability advantages does diameter give you over radius?
I was referring to SIP application level scalability, not to diameter/radius. The CSCF architecture solves the problem of the big home registrar being hard to replicate once one single machine can no longer handle all your subscribers. Of course there are other solutions, but this is a standardized one so that you can use different components and get out of the provider lock.
But you would miss the Application Server thing, with the possibility of easily enabling per-user functionality. Sure that you can do this now from the SER script, but the effort of maintaining it dynamic, per user and with the AS having access to the subscriber data is just huge. In my opinion SER's script is great for managing things at the SIP level, but once you build applications on top, you just want to abstract from that. And let's not forget the standardization aspect - any IMS core network should be able to use and standard IMS Application Servers.
what are those applications that ASes handle? why can't i put users' application info into radius raply table?
of course you can. But again, the standard is not there for what you say. Also radius has drawbacks, like the fact that it is not bi-directional so that you can not push updates back and forth.
-- juha
At 00:19 10/10/2006, Dragos Vingarzan wrote:
That is relative. Almost all new mobile phones support now also WiFi ,so it is not only about UMTS and what the phones are implementing by default. Both Symbian and Windows Mobile are capable of running IMS soft-clients on top. And let's not forget TISPAN's NGN and the fixed networks.
I personally suggest to forget TISPAN and leave it out of scope of this mailing list.
About the walled garden, well, no operator would give to end-users QoS control because simply it would just cost too much and nobody would afford it. As such, I do not see any opened solutions.
With all respect I absolutely fail to see the argument's logic here.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Probably I did not put it right :)....
So everybody sees the devil in IMS now because of this QoS. But let's not couple it with the fear of discriminative access. That is something else, coming from the bit-carriers frustration that other people are making loads of money by adding value to the bits.
I see the Internet now as largely not QoSed. We are playing with this nice price-cutting thing called VoIP and suddenly we see the potential, but the services can't really evolve and equal the classic ones without QoS. As such we ask for it.
So the bit-movers will eventually upgrade their networks and add support for this and this will cost. This cost has to be supported by end-user and as such the prices for QoSed will probably be higher than that of non-QoSed access. And now we come back and we whine that we don't want to pay for it and we don't want it anymore if the bit-movers will have preferential access to it.
But hey, of course that it is going to cost. Anyway, we did not had flat-rates since the beginning, right? But eventually the "gardens" will start to open-up.
Conclusion: if you want extra QoS with that, you will have to pay for it. But this is no reason to bash IMS and to stop building open gardens.
Jiri Kuthan wrote:
At 00:19 10/10/2006, Dragos Vingarzan wrote:
That is relative. Almost all new mobile phones support now also WiFi ,so it is not only about UMTS and what the phones are implementing by default. Both Symbian and Windows Mobile are capable of running IMS soft-clients on top. And let's not forget TISPAN's NGN and the fixed networks.
I personally suggest to forget TISPAN and leave it out of scope of this mailing list.
About the walled garden, well, no operator would give to end-users QoS control because simply it would just cost too much and nobody would afford it. As such, I do not see any opened solutions.
With all respect I absolutely fail to see the argument's logic here.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Dragos Vingarzan writes:
Conclusion: if you want extra QoS with that, you will have to pay for it. But this is no reason to bash IMS and to stop building open gardens.
i don't get this. i said that current 3g networks don't offer any qos and then you mentioned wlans. wlans are customer property and telcos has no way to control their qos. so how can ims help with qos, when the underlaying networks don't have any?
-- juha
Inline.
Jiri Kuthan wrote:
At 00:19 10/10/2006, Dragos Vingarzan wrote:
That is relative. Almost all new mobile phones support now also WiFi ,so it is not only about UMTS and what the phones are implementing by default. Both Symbian and Windows Mobile are capable of running IMS soft-clients on top. And let's not forget TISPAN's NGN and the fixed networks.
I personally suggest to forget TISPAN and leave it out of scope of this mailing list.
I'm curious: why?
About the walled garden, well, no operator would give to end-users QoS control because simply it would just cost too much and nobody would afford it. As such, I do not see any opened solutions.
With all respect I absolutely fail to see the argument's logic here.
I think it depends on where you come from ;-) The underlying assumption is that an operator has made an investment where it wants some return. The big question from an operator's point of view is what is the best approach to get the return? There will different answer depending on your market position and your feeling of strength. Operators are afraid of becoming just a bitpipe. It was the same issue for big network operators a few years back (and still is): become an efficient bitpipe (Level3) or a full communication services provider (AT&T).
The truth is that a walled-garden approach works as long as you have some assets people want. But as the value chains disintegrate operators have to take a position somewhere along the value chain.
I think the big questions that operators are asking themselves now are these: - How long time will my assets allow me to keep a walled garden? - Exactly what are my true assets as the value chains disintegrate? - When the walled garden comes down, what is the position I want?
Some operators will be protective and keep a walled garden as long as possible, while others will try to open up, invite third parties in and try to make the pie bigger... Most operators will probably do both as they don't really have any answers to the questions above yet :-) g-)
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
At 10:10 13/10/2006, Greger V. Teigre wrote:
Inline.
Jiri Kuthan wrote:
At 00:19 10/10/2006, Dragos Vingarzan wrote:
That is relative. Almost all new mobile phones support now also WiFi ,so it is not only about UMTS and what the phones are implementing by default. Both Symbian and Windows Mobile are capable of running IMS soft-clients on top. And let's not forget TISPAN's NGN and the fixed networks.
I personally suggest to forget TISPAN and leave it out of scope of this mailing list.
I'm curious: why?
I dont think this is adding value to the SER community and would thus prevent not to spend time on this too much.
About the walled garden, well, no operator would give to end-users QoS control because simply it would just cost too much and nobody would afford it. As such, I do not see any opened solutions.
With all respect I absolutely fail to see the argument's logic here.
I think it depends on where you come from ;-) The underlying assumption is that an operator has made an investment where it wants some return. The big question from an operator's point of view is what is the best approach to get the return? There will different answer depending on your market position and your feeling of strength. Operators are afraid of becoming just a bitpipe. It was the same issue for big network operators a few years back (and still is): become an efficient bitpipe (Level3) or a full communication services provider (AT&T).
Sure, there is some 'I'm just a bitpipe guy' sentiment here. But what's the argument for QoS here?
The truth is that a walled-garden approach works as long as you have some assets people want. But as the value chains disintegrate operators have to take a position somewhere along the value chain.
I think the big questions that operators are asking themselves now are these:
- How long time will my assets allow me to keep a walled garden?
- Exactly what are my true assets as the value chains disintegrate?
- When the walled garden comes down, what is the position I want?
Some operators will be protective and keep a walled garden as long as possible, while others will try to open up, invite third parties in and try to make the pie bigger... Most operators will probably do both as they don't really have any answers to the questions above yet :-)
Sure but I still fail to see how this establishes a case for investing in QoS.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
So, you "dont think [TISPAN] is adding value to the SER community and would thus prevent not to spend time on this too much."
I'm not very well updated on TISPAN, but I thought TISPAN was an effort to adapt IMS to the needs of ISPs and fixed providers. With IMS implemented from FOKUS, why would a discussion on TISPAN not add value to the SER community? I would say that anything SIP that is of interest to some of the SER users would be within the scope of this mailing list. g-)
Jiri Kuthan wrote:
At 10:10 13/10/2006, Greger V. Teigre wrote:
Inline.
Jiri Kuthan wrote:
At 00:19 10/10/2006, Dragos Vingarzan wrote:
That is relative. Almost all new mobile phones support now also WiFi ,so it is not only about UMTS and what the phones are implementing by default. Both Symbian and Windows Mobile are capable of running IMS soft-clients on top. And let's not forget TISPAN's NGN and the fixed networks.
I personally suggest to forget TISPAN and leave it out of scope of this mailing list.
I'm curious: why?
I dont think this is adding value to the SER community and would thus prevent not to spend time on this too much.
About the walled garden, well, no operator would give to end-users QoS control because simply it would just cost too much and nobody would afford it. As such, I do not see any opened solutions.
With all respect I absolutely fail to see the argument's logic here.
I think it depends on where you come from ;-) The underlying assumption is that an operator has made an investment where it wants some return. The big question from an operator's point of view is what is the best approach to get the return? There will different answer depending on your market position and your feeling of strength. Operators are afraid of becoming just a bitpipe. It was the same issue for big network operators a few years back (and still is): become an efficient bitpipe (Level3) or a full communication services provider (AT&T).
Sure, there is some 'I'm just a bitpipe guy' sentiment here. But what's the argument for QoS here?
The truth is that a walled-garden approach works as long as you have some assets people want. But as the value chains disintegrate operators have to take a position somewhere along the value chain.
I think the big questions that operators are asking themselves now are these:
- How long time will my assets allow me to keep a walled garden?
- Exactly what are my true assets as the value chains disintegrate?
- When the walled garden comes down, what is the position I want?
Some operators will be protective and keep a walled garden as long as possible, while others will try to open up, invite third parties in and try to make the pie bigger... Most operators will probably do both as they don't really have any answers to the questions above yet :-)
Sure but I still fail to see how this establishes a case for investing in QoS.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
And then to QoS :-)
I'm not sure that I see the argument for investing in QoS either. I think the costs are higher than the willingness to pay ;-) There seems to be some operators that believe there is a business case in it though. Maybe they extrapolate from the success of QoS sales in MPLS networks and assume that enterprises are willing to pay for QoS extended into the mobile data network? g-)
About the walled garden, well, no operator would give to end-users QoS control because simply it would just cost too much and nobody would afford it. As such, I do not see any opened solutions.
With all respect I absolutely fail to see the argument's logic here.
I think it depends on where you come from ;-) The underlying assumption is that an operator has made an investment where it wants some return. The big question from an operator's point of view is what is the best approach to get the return? There will different answer depending on your market position and your feeling of strength. Operators are afraid of becoming just a bitpipe. It was the same issue for big network operators a few years back (and still is): become an efficient bitpipe (Level3) or a full communication services provider (AT&T).
Sure, there is some 'I'm just a bitpipe guy' sentiment here. But what's the argument for QoS here?
The truth is that a walled-garden approach works as long as you have some assets people want. But as the value chains disintegrate operators have to take a position somewhere along the value chain.
I think the big questions that operators are asking themselves now are these:
- How long time will my assets allow me to keep a walled garden?
- Exactly what are my true assets as the value chains disintegrate?
- When the walled garden comes down, what is the position I want?
Some operators will be protective and keep a walled garden as long as possible, while others will try to open up, invite third parties in and try to make the pie bigger... Most operators will probably do both as they don't really have any answers to the questions above yet :-)
Sure but I still fail to see how this establishes a case for investing in QoS.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
At 16:45 09/10/2006, Juha Heinanen wrote:
Dragos Vingarzan writes:
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.
well, i just heard that in current 3g networks pdp contexts with different QoSes have not been implemented at all. neither does QoS pdp context support in 3g phones.
what comes to ims in general, i don't see it having any chance of success, because it locks users into walled gardens. this, of course, doesn't prevent the community from developing IMS features in ser,
In short, I think that IMS bad or good, is not the critical problem in our life. In an attempt to be fair to IMS, it is reasonable to say that the standard became too complicated but many have chosen to take out rational parts of it and ignore the less rational parts (to which IMO QoS ultimately belongs including the policy stuff....) Other IMS items for life in mobile networks such as sigcomp appear meaningful.
The really interesting part to me is indeed the "walled-garden" aspect. I think however that's "sub-IMS" problem living in the IP access space. IMS products can be built with such configuration option turned on or off, but as long as an IP subsriber can use any SIPs server in the world it does not really matter much. The real harm potential is in discriminative control of IP access. (Which is why I guess many are excited by the QoS and PDP aspect.)
but i would feel that much more relevant would be to focus on XMPP/SIP integration.
Well -- There is not much to be done but build a gateway if that's what you mean by integration. It is two competing technologies, time will show which is less popular, in the meantime gateways can be used.
-jiri
even if ser would include full IMS support, what would the use case be? mobile operators are not likely to deploy third party IMS solutions, because they are locked to their mobile vendor.
-- juha _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Jiri Kuthan writes:
Well -- There is not much to be done but build a gateway if that's what you mean by integration. It is two competing technologies, time will show which is less popular, in the meantime gateways can be used.
yes, they are competing technologies, but nothing prevents having both in our basket. what i meant by integrated sip/xmpp solution is a server that support both sip and xmpp clients on a common presence/subscriber database and is able to publish in dns both sip and xmpp srv records.
-- juha
-
Dragos Vingarzan -
Greger V. Teigre -
Jiri Kuthan -
Juha Heinanen -
Klaus Darilion