Re: [Sipping] Re: New Draft on TISPAN analysis for SIP solutions concerning the simulation Services

David R Oran <oran@cisco.com> Fri, 15 July 2005 15:28 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtS6a-0006h5-CA; Fri, 15 Jul 2005 11:28:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtS6Y-0006gu-0z for sipping@megatron.ietf.org; Fri, 15 Jul 2005 11:27:58 -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 LAA18614 for <sipping@ietf.org>; Fri, 15 Jul 2005 11:27:55 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtSZO-0005vM-23 for sipping@ietf.org; Fri, 15 Jul 2005 11:57:46 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 15 Jul 2005 08:27:48 -0700
X-IronPort-AV: i="3.93,293,1115017200"; d="scan'208"; a="648749870:sNHT54586526"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6FFRgod015576; Fri, 15 Jul 2005 08:27:42 -0700 (PDT)
Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j6FFQIM7017315; Fri, 15 Jul 2005 08:26:18 -0700
In-Reply-To: <42CA7271.5010406@nokia.com>
References: <E7666D92C64C2845AEF12636FF94F95202319C82@S4DE8PSAAGQ.blf.telekom.de> <42C4E903.7060509@nokia.com> <B640BFCA-5A68-49D9-B74A-3AD741EA1A03@cisco.com> <42CA7271.5010406@nokia.com>
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <1B2BAF08-CFC3-42BF-8C7E-FFBA17098063@cisco.com>
Content-Transfer-Encoding: 7bit
From: David R Oran <oran@cisco.com>
Subject: Re: [Sipping] Re: New Draft on TISPAN analysis for SIP solutions concerning the simulation Services
Date: Fri, 15 Jul 2005 11:27:43 -0400
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>
X-Mailer: Apple Mail (2.733)
IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1121441179.256810"; x:"432200"; a:"rsa-sha1"; b:"nofws:3419"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"INfFypV780j+UnmIMBz24a8Q9MLBqtn76hHKZcRIhmhS9NHBnxSdGK8v0tp1dHZO51tKCmLp" "QS/f3pTBn0TSSBh8KaKcqLgjpo641e4KccNu6bJyWnlezajJCaAprLGKPomUpWxJd5C2/tHi20E" "2tPJarnf0eBfaLaSqnambYpE="; c:"From: David R Oran <oran@cisco.com>"; c:"Subject: Re: [Sipping] Re: New Draft on TISPAN analysis for SIP solu" "tions concerning the simulation Services"; c:"Date: Fri, 15 Jul 2005 11:27:43 -0400"
IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; "
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7
Content-Transfer-Encoding: 7bit
Cc: sipping WG <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

On Jul 5, 2005, at 7:43 AM, Miguel Garcia wrote:

> Hi Davd:
>
> Because bodies are supposed to be end-to-end information, so if a  
> UA inserts a body, a proxy shouldn't be touching it, otherwise, it  
> wouldn't be a proxy, but a B2BUA or UA. So having a body here will  
> just limit the operation of the application server to B2BUAs.
>
I suppose that's ok, but I'd really like to see the analysis and  
justification in the draft. I'd especially like to know why the  
proxies should be involved in what it actually an end-to-end function  
as far as I can tell based on the kind of stuff people put in AOC  
fields.

I don't have web proxy caches telling me what I was being charged for  
in a web transaction...


> We want to have the possibility of the application server that  
> provides the AoC information to behave as a SIP proxy, just reading  
> the header, and then providing the information by other means. For  
> instance, it has been discussed that the application server could  
> send an Instant Message to the UA containing either the information  
> or a content indirection link. This instant message will go out of  
> the existing dialog, so the application server could be acting as a  
> UA for the instant message.
>
If you want the proxy to see this information, you can always not  
encrypt it...

> BR,
>
>       Miguel
>
> David R Oran wrote:
>
>
>> Would you please provide justification in the draft for why this   
>> should be a header and not a body? I can't for the life of me  
>> figure  out why this can't be done with a body (which would  
>> require  essentially no change to SIP, only a MIME registration)  
>> since proxies  do nothing with the header I can discern.
>> Thanks, Dave.
>> On Jul 1, 2005, at 2:56 AM, Miguel Garcia wrote:
>>
>>> And I have also submitted another draft that proposes a P-  
>>> header  to support the Advice of Charge service.
>>>
>>> Until the draft is officially distributed, it can be retrieved from:
>>>
>>> http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-etsi-  
>>> ngn-p-headers-00.txt
>>>
>>> /Miguel
>>>
>>> Jesske, R wrote:
>>>
>>>
>>>
>>>
>>>> Dear all,
>>>> A new draft regarding the analysis of the requirements on  
>>>> TISPAN  simulation services as described in draft-jesske-sipping- 
>>>> tispan- requirements-01  is now available.
>>>> It can be fond under:
>>>> http://www.ietf.org/internet-drafts/draft-jesske-sipping-tispan-  
>>>> analysis-00.txt We would like to start the discussion on  
>>>> solutions  for the requirements we stated in draft-jesske- 
>>>> sipping-tispan- requirements-01 (http://www.ietf.org/internet- 
>>>> drafts/draft-jesske- sipping-tispan-requirements-01.txt).
>>>> This draft should be seen as a discussion basis and  
>>>> brainstorming  of some people thinking about SIP solutions.
>>>> Every comment and discussion is welcome and helps to find a  
>>>> solution.
>>>> Thank you.
>>>> Best Regards
>>>> Roland
>>>> Deutsche Telekom AG
>>>> T-Com Zentrale
>>>> Roland Jesske, TE332-2
>>>> Section TE33; Signalling, Gateways and Switching Systems
>>>> Am Kavalleriesand 3, 64295 Darmstadt, Germany
>>>> Phone:  +49 6151 83-5940
>>>> Fax:      +49 6151 83-4577
>>>> email:   r.jesske@t-com.net
>>>>
>>>>
>>>
>>> -- 
>>> Miguel A. Garcia           tel:+358-50-4804586
>>> sip:miguel.an.garcia@openlaboratory.net
>>> Nokia Research Center      Helsinki, Finland
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> sip:miguel.an.garcia@openlaboratory.net
> Nokia Research Center      Helsinki, Finland
>
>
> _______________________________________________
> 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
>

_______________________________________________
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