Subject: RE: [Sipping] Requirements for the identification of IMScommunicationservices.

From: Prakasha <[email-masked]>
Date: Fri, 30 Jun 2006 09:57:23 +0530

One way the terminating network know that the call should be routed to PoC
application server 
is using some "prefix" in the reqeuest URI. But in this case both the
originating and terminating 
network routing policies have to be in sync (in the similar manner as the
normal IN services work). 
But if it is not possible to synchronize these policies, then there has to
be some kind of standardized
identifier identifying the service that is being requested by the UA. But
with many different services 
beeing thought of, won't it be difficult to manage this standardized service
identifier?

Regards,
Prakash

Huawei Technologies India Pvt. Ltd
Bangalore, India

http://www.huawei.com

**********************************************************************
This  e-mail and its  attachments  contain  confidential information 
from HUAWEI,  which is intended only for the  person or entity whose 
address is listed above.  Any use of the information contained herein 
in any way (including, but not limited to, total or partial disclosure, 
reproduction, or  dissemination) by  persons other  than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please 
notify the sender by phone or email immediately and delete it!
***********************************************************************

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Thursday, June 29, 2006 11:05 PM
To: Burger, Eric
Cc: Andrew Allen; sipping; Stephen Terrill (MI/EEM)
Subject: Re: [Sipping] Requirements for the identification of
IMScommunicationservices.

Hi,

still trying to facilitate discussions...

I guess what Stephen is asking below is a way for the terminating 
network (i.e., the terminating S-CSCF) to know that this call should be 
routed to the PoC application server.

Earlier in this thread loose-routes were proposed. Even earlier in this 
thread, it was noted that the issues at the originating and the 
terminating networks are different. For example, loose routing could 
work well for the originating network, but does not seem to work for the 
terminating side.

You may want to discuss the differences between both sides (originating 
and terminating) of the call and which mechanisms work for which side.

Thanks,

Gonzalo

Burger, Eric wrote:
> Because that is what the S-CSCF / SCIM does?
> 
> -----Original Message-----
> From: Stephen Terrill (MI/EEM) [mailto:[email-masked]]
> Sent: Monday, June 26, 2006 3:38 AM
> To: Burger, Eric; Andrew Allen
> Cc: sipping
> Subject: RE: [Sipping] Requirements for the identification of 
> IMScommunication services.
> 
> Hi,
> 
> In the example given below, how will the "network" know to invoke the
> application server that the described "Push-to-talk application"?.
> 
> BTW - I assuming that you have seen that the related requirement draft
> related to this now "draft-loreto-sipping-3gpp-ics-requirements-00.txt
> 
> BR,
> 
> ..//Steve
> 
> -----Original Message-----
> From: Burger, Eric [mailto:[email-masked]]
> Sent: Friday, June 23, 2006 10:19 PM
> To: Andrew Allen
> Cc: Stephen Terrill (MI/EEM); sipping
> Subject: RE: [Sipping] Requirements for the identification of 
> IMScommunication services.
> 
> 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?
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, April 11, 2006 4:52 PM
> To: Andrew Allen
> Cc: sipping; Dean Willis; Stephen Terrill (E2/EEM); Gonzalo Camarillo
> (JO/LMF); Rohan Mahy
> Subject: Re: [Sipping] Requirements for the identification ofIMS 
> communicationservices.
> 
> Andrew,
> 
> I started this response just before the end of the ietf meeting, and
> never finished it. The whole conversation has gotten a bit stale, but 
> maybe it is time to revive it. Maybe some others will have opinions 
> now.
> 
> See inline.
> 
> 	Paul
> 
<snip>

_______________________________________________
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