RE: AW: [Sipping-tispan] Re: CCBS/CCNR in Version -02f

"Michael Hammer \(mhammer\)" <mhammer@cisco.com> Tue, 27 September 2005 20:00 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKLcW-0007rU-5m; Tue, 27 Sep 2005 16:00:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKLcV-0007rD-5d for sipping-tispan@megatron.ietf.org; Tue, 27 Sep 2005 16:00:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06985 for <sipping-tispan@ietf.org>; Tue, 27 Sep 2005 16:00:05 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKLjn-0008UA-Iw for sipping-tispan@ietf.org; Tue, 27 Sep 2005 16:07:40 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Sep 2005 15:59:57 -0400
X-IronPort-AV: i="3.97,150,1125892800"; d="scan'208"; a="72007421:sNHT33691268"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8RJxORF007108; Tue, 27 Sep 2005 15:59:54 -0400 (EDT)
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 15:59:47 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
Date: Tue, 27 Sep 2005 15:59:46 -0400
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E39C9773@xmb-rtp-20b.amer.cisco.com>
Thread-Topic: AW: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
Thread-Index: AcXDWaFRwtC5CsL3R+ecVyxXO9J0gQAQyrow
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: "Miguel Garcia" <Miguel.An.Garcia@nokia.com>, "Schmidt, Christian" <christian-schmidt@siemens.com>
X-OriginalArrivalTime: 27 Sep 2005 19:59:47.0246 (UTC) FILETIME=[02FF44E0:01C5C39E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Content-Transfer-Encoding: quoted-printable
Cc: Tessa Silvia <Silvia.Tessa@TILAB.COM>, sipping-tispan@ietf.org
X-BeenThere: sipping-tispan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of requirements for SIP introduced by ETSI TISPAN <sipping-tispan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sipping-tispan>
List-Post: <mailto:sipping-tispan@ietf.org>
List-Help: <mailto:sipping-tispan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=subscribe>
Sender: sipping-tispan-bounces@ietf.org
Errors-To: sipping-tispan-bounces@ietf.org

Miguel,

Continuing on my earlier comment:  By network are you taking routers?  

If you mean voice host applications such as proxies, are you suggesting
that a proxy in the middle of a network somewhere will do this
prioritization?

If you mean some service of the callee, what is the chance that 2 calls
will arrive simultaneously?

Or do you mean the callee (or his server) will know that there is a
caller camped on and will intentionally delay incoming calls while a
"subscriber free" indication is sent toward the caller and completed
with some notification or timer before moving on to the regular call?

I certainly hope you are not suggesting that we elevate CCBS calls to
the status of emergency calling.  There are only so many useful levels
of priority, and this could muddy the water.

Mike

> -----Original Message-----
> From: sipping-tispan-bounces@ietf.org 
> [mailto:sipping-tispan-bounces@ietf.org] On Behalf Of Miguel Garcia
> Sent: Tuesday, September 27, 2005 7:47 AM
> To: Schmidt, Christian
> Cc: Tessa Silvia; sipping-tispan@ietf.org
> Subject: Re: AW: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> 
> 
> 
> Schmidt, Christian wrote:
> 
> > 
> > 
> > We have already have REQ 12 stating that
> > 	 Any communication performed as a result of the execution of a 
> > CCBS/CCNR request should be distinguishable from regular 
> communications.
> > 
> > So,  all terminating call are "distinguishable" and any policy a 
> > network might have could be easily based on this, without 
> further requirements.
> > Other views ?
> > 
> > Christian: I see, perhaps you can add a short explanation 
> for this purpose:
> > 	 Any communication performed as a result of the execution of a 
> > CCBS/CCNR request should be distinguishable from regular 
> communications.
> > This can be used to priorize CCBS/CCNR calls towards the callee.
> > What do you think?
> > 
> 
> I have a proposal for this requirement:
> 
> 
>     REQ-CCBS/CCNR-12:
>     It must be possible for the network to priotirize 
> CCBS/CCNR recalls
>     towards the callee, above regular calls. This implies that any
>     communication performed as a result of the execution of a 
> CCBS/CCNR
>     request should be distinguishable from regular communications.
> 
> 
> /Miguel
> 
> 
> > Regards
> > Silvia
> > 
> 
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> sip:miguel.an.garcia@openlaboratory.net
> Nokia Research Center      Helsinki, Finland
> 
> 
> _______________________________________________
> Sipping-tispan mailing list
> Sipping-tispan@ietf.org
> https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 

_______________________________________________
Sipping-tispan mailing list
Sipping-tispan@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-tispan