Subject: RE: [Sipping] Requirements for the identification of IMS communication services.

From: "Burger, Eric" <[email-masked]>
Date: Sun, 25 Jun 2006 19:25:45 -0400

What is being talked about here doesn't help.  My voice call and my
emergency voice call both are the voice call service.

Ieprep is looking at how to mark a SIP session as an emergency session.
That also means that it would work for my IM emergency, my video
emergency, my PoC emergency, etc.  Creating an "Emergency Call" service
is opening an nx proliferation of non-interoperable things that most
networks will, if properly implemented, ignore and most real networks
will barf on.

-----Original Message-----
From: Arjun Roychowdhury [mailto:[email-masked]] 
Sent: Friday, June 23, 2006 10:21 PM
To: Burger, Eric
Cc: sipping
Subject: Re: [Sipping] Requirements for the identification of IMS
communication services.

I am a little sympathetic towards this cause. In the last few months
of being involved in working with some folks rolling out an IMS
network, there were some valid usecases for this. Consider a case
where there is a national emergency and a carriers only needs to allow
'standard' voice calls to ensure effective available bandwidth. If
there is no classification of the 'service' then it becomes very hard
to differentiate what the primitives are doing, and yes, anything that
is not a 'standard voice call' will be blocked. Note that during these
times, it is very likely that the carrier will short circuit several
routes, eliminate application servers and only keep the critical
elements needed to route the call. So there cannot be any expensive
processing or CPL script going on, or a B2B keeping track of all
primitives and applying complex business logic to decipher what the
service really is. In these cases, mapping the services to primitives
is an important need.

regds
arjun

On 6/23/06, Burger, Eric <[email-masked]> wrote:
> My head is spinning on this one.  I suppose I should have been paying
> more attention.
>
> Let us say that I have a User Interface that looks for all purposes
like
> a push-to-talk application.  It uses presence and buddy lists, and I
> push a single button to talk to someone.  Only, it doesn't use the
> official, IMS-Registered(tm) PoC service.  Rather, it uses regular SIP
> to establish sessions.
>
> Tell me, what happens?  Will the IMS police block this sort of traffic
> at a hyper-intelligent SBC that detects I'm using presence and issuing
> an INVITE from the same User Equipment?  On the flip side, what is the
> difference between my invoking a real PoC MRFP to do low-level,
> half-duplex RTP mixing?  Hey, if I'm a service provider, I think I'd
> notice someone asking to use my resources.  I'd bill on that; who
cares
> if they have an IMS Registered(tm) User Interface or not?  Come on!
It
> will take 12 seconds for someone to hack out the 'service identifier'
> header - you might as well run your business with a sustainable, value
> generating, and value renumerating (i.e., profitable) model.
>
> In particular, this proposal is H.248 all over again.  In the words of
> another standards Grey Beard (you know who you are), this looks like a
> proposal for a "Standardized Proprietary Interface."  This to me looks
> like a brazen attempt to have a single-vendor solution, or at best, a
> pay-to-play solution, for clients and servers.
>
> Getting back to Paul's point: what PROTOCOL issue are we trying to
solve
> here?

-- 
Arjun Roychowdhury

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP