[Serdev] contribution: SER module implementing Path extension(RFC3327)

[Greger V. Teigre]

:-) And there the mobile- vs Internet-approach to service delivery entered 
serdev...

Even though I share your IMS scepticism, Juha, the network supplies and 
mobile operators are strong and will impact SIP, and as we see, also SER.  I 
believe that smaller operators, as well as the new business opportunities in 
delivering mobile services over pure TCP/IP (as opposed to SIM-based 
authentication and IMS), will cause SER to be implicated both as a piece of 
software that needs to participate/interoperate with IMS, as well as 
co-exist as an alternative.  We already see this in the Path extension 
thread.  This I believe, is an opportunity, not a threat. The mobile 
industry is looking at one major paradigm shift, but they just don't know it 
yet (and they will try to prevent it).  In the end, the customer will vote: 
a few expensive mobile (IMS) based services or cheap Internet-based services 
integrated with all the other services you are used to? I think it all boils 
down to who will give the customer the best user experience?
    Here in Norway, you can get 3G Internet access at a flat monthly price, 
bring your Symbian SIP softphone and you're online. The same goes for any 
other TCP/IP based service...

IMHO, Dragos' and Fermín' efforts will only strengthen SER's position. I 
cannot see any risk that SER will be dragged into IMS yet.
g-)

Juha Heinanen wrote:
> Klaus Darilion writes:
>
>> I'm also interested in IMS.
>
> i'm not.  the reason is that ims uses sip to implement walled garden,
> which locks users to the operators and their artificial charging
> models, whose only purpose is to milk the cow as many times as
> possible.
>
> even if people manage to make ser ims compatible, it is unlikely that
> any mobile operator will start using ser as their ims.  the reason is
> that mobile operators have very strong ties with their network
> suppliers (nokia, ericsson, etc), which makes it very hard for them
> to include any third party components into their infrastructure.
>
> -- juha