Re: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

Paul Kyzivat <pkyzivat@cisco.com> Mon, 17 October 2005 23:56 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERepz-0004YN-Fk; Mon, 17 Oct 2005 19:56:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERepx-0004XB-00 for sipping@megatron.ietf.org; Mon, 17 Oct 2005 19:56:13 -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 TAA16967 for <sipping@ietf.org>; Mon, 17 Oct 2005 19:56:04 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERf1M-0000WD-FY for sipping@ietf.org; Mon, 17 Oct 2005 20:08:01 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 17 Oct 2005 19:56:02 -0400
X-IronPort-AV: i="3.97,225,1125892800"; d="scan'208"; a="73901876:sNHT25464832"
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 j9HNtwEi004012; Mon, 17 Oct 2005 19:55:59 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 19:55:58 -0400
Received: from [161.44.79.76] ([161.44.79.76]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 19:55:58 -0400
Message-ID: <43543A0E.3070405@cisco.com>
Date: Mon, 17 Oct 2005 19:55:58 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Francois Audet <audet@nortel.com>
Subject: Re: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt
References: <1ECE0EB50388174790F9694F77522CCF04C4DBBF@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF04C4DBBF@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Oct 2005 23:55:58.0417 (UTC) FILETIME=[51EF5C10:01C5D376]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Content-Transfer-Encoding: 7bit
Cc: "Elwell, John" <john.elwell@siemens.com>, sipping <sipping@ietf.org>
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org

Francois,

I'm sorry if I seem to be putting words into your mouth. That isn't my 
intent. But it does indicate that we still aren't understanding each 
other. I was restating what I thought I understand from what you had 
said, and I guess I got it wrong.

More below.

	Paul

Francois Audet wrote:
>>At the time the parameters are to be inserted, the element 
>>doing so most 
>>likely doesn't know if the target is a gateway or not. All it really 
>>knows is that the new target is a phone number. That *might* 
>>get routed 
>>to a gateway. Or it *might* turn out to be something 
>>reachable via SIP.
> 
> 
> What?
> 
> When you retarget, you know what you are retargeting to. You don't 
> randomly retarget to anywhere and expect it to work.
> 
> You have a phone (or a proxy) that supports Call Forwarding on busy. 
> The phone or proxy is configured with a SIP URI of where to direct the
> call if it is busy.
> 
> That URI can be anything. This URI will be provided by the service 
> operator. It puts whatever value it wants to get the service working.

There is what the service operator does, and there is what the user does 
to enable the service. Lets be very concrete:

I have an (sip-based) operator that lets me configure forwarding and VM 
over the web. For the busy or no answer case I have two choices:
- VM
- Forward to NNNNNNNNN (Where I fill in the NNNNNNNNN.)

I understand your point that if I pick the VM option, then the operator 
can put whatever URI it wants in for the VM, either a native sip uri or 
a phone number in sip or tel format. And it knows it is a VM. If it 
knows that the VM wants these parameters, it can put them in at 
provisioning time or remember to do so at runtime.

But the case I was concerned with is the other one. I don't tell the 
provider this is a VM. It *could* be the dedicated phone number of a VM. 
Or it could be the phone number of my Deputy. How would the service 
operator know?

Lets assume it is the phone number of my deputy - a person with a phone 
and his own VM feature.

According to your draft, I *thought* there was a goal that the 
retargetting information be passed along to the deputy. (For use however 
it sees fit, including the case where it just happens to be a VM.) If 
that is not the case, then I think we have few remaining issues.

I'm not going to comment on any of the other points because I think that 
would just compound misunderstandings.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP