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

From: Miguel Garcia <[email-masked]>
Date: Fri, 01 Jul 2005 09:56:03 +0300

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:   [email-masked]
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: David R Oran <[email-masked]>
Date: Tue, 5 Jul 2005 09:19:21 -0400

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.
>
>> 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.

---

From: Arjun Roychowdhury <[email-masked]>
Date: Tue, 5 Jul 2005 09:21:51 -0400

Miguel: Some comments:

General 1: The word 'simulation' does not sit well, somehow. It seems to me
that 'simulation' is somewhat of a test environment where the services being
executed are not real. 

General 2: After reading draft-jesske-sipping-tispan-analysis-00.txt
and draft-jesske-sipping-tispan-requirements-01.txt together, my impression
is that the non-PSTN oriented community will find it hard to offer suggestions
since neither draft really describes the motivation for the requirements besides
stating that it is required. What would help is to add motivations in
the requirement
document that also describe how things work in the network that needs
to be 'simulated'
(call flows would help)

2.2 ACR:
On reading RFC 3326, it does not look like Reason can only be
used for requests. The language used is loose where they suggest
that since a response already has a status area, it is more likely
that Reason will be used in requests. In section 2, it goes on to state:
" The Reason header field MAY appear in any request within a dialog, in
   any CANCEL request and in any response whose status code explicitly
   allows the presence of this header field."

So it looks like you could use the Reason header.

2.2.1: 
How exactly will this work in the SIP world ? Here we make an
assumption that the serving Proxy/AS knows that user A has an ACR service.
However, what is User A simply sent a REGISTER message to its registrar with
the contact of the ACR without explicitly defining that its an ACR - how does
the proxy know who is the real user and how to route directly to the "real" UA ?

On the other hand, if the assumption is that ACRs will be explictly defined
and managed centrally, can you consider extending the scope of the
header applicability ?

It looks like the general requirement is that you need to reach the
"real" user directly.
Whether an ACR happens to be registered or something else is not the
real issue - so maybe
the header should reflect the final reachability issue rather than an ACR

2.21, para just after definition of header syntax
"The draft-ietf-sip-identity was not considered ......"

The para is very densely worded (in other words, I did not understand
the reasoning ;-)

2.3.1: P-Additional-Identity

I am concerned that from an overall perspective, figuring out who a
call came from
is becoming a huge mess for the called party. We already have request uri, from,
asserted-identity. Adding a p-additional-identity just adds to the
melee. Can this document
describe scenarios as to why adding this information to the
request-uri/asserted-identity
combination will not work ? accordingly we can judge if this is to be
remedied by
sticking another header or requesting that intermediaries follow a
certain standard
procedure for callflow to make the identification work.

2.4: AOC header
I read (either in this draft or some other) that the goal of TISPAN
NGN is to merge
wireline and wireless networks based on IMS rel7 arch.
I believe IMS already specifies a charging header which can be
populated by several
tokens - why can't AoC be another token instead of a new header ?

2.7: MCID1 and MCID-2

What are the motivations for this requirement ? What constitutes a
'malicious call'
and what does does the AS do when such a call is detected ? I assume that since
this seems to be a walled network, relevant information about the call
will be logged
as admin CDR - if a malicious call were to reach a user, a user could
use any offline
mechanism to notify the admin of the malicious call and action could
be taken. Why does this require event packages and such ?

regds
arjun

-- 
Arjun Roychowdhury

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 5 Jul 2005 12:11:40 -0400

> From: Arjun Roychowdhury

Some document that I read on the subject explained the term "simulation".
The problem being that SIP cannot exactly implement these PSTN features, so
the SIP feature is considered a "simulation" of the original.

> stating that it is required.

My impression is that these features are already being offered by the PSTN,
and that from their point of view, the requirement is to act as much like
the PSTN features as possible.

(It would help if these points were explained in the draft.)

> melee.

Someone once explained to me that in the PSTN Signaling System 7, there were
*4* different "calling party" identifiers, and that under various scenarios,
it made sense to distinguish them all.

Dale

---

From: David R Oran <[email-masked]>
Date: Tue, 5 Jul 2005 12:47:47 -0400

On Jul 5, 2005, at 12:11 PM, Dale Worley wrote:

>> From: Arjun Roychowdhury
>>
>> General 1: The word 'simulation' does not sit well, somehow. It  
>> seems to
>>
> me
>
>> that 'simulation' is somewhat of a test environment where the  
>> services
>>
> being
>
>> executed are not real.
>>
>
This is a very suspect use of the term "simulation". What is meant  
here is either "approximation" or "equivalent". I'll also remind  
people of the technical definition of "compatible"

Compatible. n. Different. (If they were the same you'd say "the  
same", not "compatible".
Software Compatible. n. Very Different.
User Interface Compatible. n. Very Very different. Likely to violate  
the principle of least astonishment.

> the PSTN features as possible.
In other words, it seems they want it to be "bug for bug compatible".  
an Important question that often gets missed is whether they want the  
feature to work or fail in cases where the equivalent PSTN feature  
fails. In order to be truly equivalent, one needs to design to  
explicitly force failure where using the native SIP facilities it  
would "just work".

> it made sense to distinguish them all.
It's a good idea to keep the protocol and UI issues separate here. If  
there are really four useful identities that can/should be carried by  
the protocol, then we should carry them. However, we should be  
careful to not throw identities in where other constructs would  
capture the semantics better. For example, things like CPC are really  
equivalence classes or "roles" and not identities.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 5 Jul 2005 12:07:49 -0500

> >> General 1: The word 'simulation' does not sit well, somehow.

Agree, though maybe for a different reason. The questionable value of
network simulations has been documented in an IEEE magazien article showing
that about 3,000 (from my unreliable memory) or so papers have been written
in the last 20 years on network simulation and most were wrong. Besides, the
self replicating nature (fractal behviour) of IP traffic makes simulation
even more suspect, at least to what is happening on the IP side.

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David R Oran
Sent: Tuesday, July 05, 2005 11:48 AM
To: Dale Worley
Cc: [email-masked]
Subject: Re: [Sipping] Re: New Draft on TISPAN analysis for
SIPsolutionsconcerning the simulation Services

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 5 Jul 2005 20:00:08 +0200

Roland,

My general comment would be: if it can be implemented using existing 
mechanisms / headers / body formats / protocols, that would always be 
preferrable. If not, then there should be a detailed and convincing 
motivation on why not, listing all alternatives considered and stating what 
makes them inappropriate

I feel that the current drafts mentioned below too easily propose new 
headers, without sufficient reflection on existing work

I think this principle would hold in general, for anyone authoring a draft

Regards,

Jeroen

-- 
Arjun Roychowdhury

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 06 Jul 2005 10:12:44 +0300

Hi Arjun:

Thanks for your comments, see inline discussion.

> that 'simulation' is somewhat of a test environment where the services being

I agreee. Unfortunately, whether we wanted or not, botu ITU-T and ETSI 
have agree on using the terms "PSTN/ISDN simulation" to refer to, say, 
SIP networks in NGN, and "PSTN/ISDN emulation" to refer to packet 
networks with classic phones, where one of this network could be a SIP 
networks that carries ISUP bodies.

In other words, I am not the "owner" of the terminology, I am just 
referring to it.

> document that also describe how things work in the network that needs

Ok, we will try to help as much as we want with the description. 
Although we have devoted quite a few time to the requirements draft, I 
recognize that the analysis draft has still room for further 
improvement. We will add call flows to those services that we are 
considering, but will be difficult to get something done before the IETF 
blockout period.

> So it looks like you could use the Reason header.

This has been discussed with some folks, I believe the authors of RFC 
3326, perhaps with other people, and they idea we got is that the RFC 
indicates that you can use the Reason header in those responses where it 
is specified that it can be used. This is leaving an open door for a 
future specfication that allows in certain response codes to include the 
Reason header, particularly, it was thought to solve the HERFP problem. 
However, up to date, there is not such RFC that allows the Reason header 
to be used in any response. That's the reason of our wording in the I-D.

> the proxy know who is the real user and how to route directly to the "real" UA ?

I think there is something wrong in your interpretation, so let me 
clarify the idea.

User B (in the future it will be a callee), has the ACR service 
activated, meaning that he does not want to receive anonymous sessions.

User A invites B. User A is a police officer or any other type of 
authority who typically will remain anonymous. This session has to 
bypass the ACR service at B, so the session is established no matter 
whether B has the ACR service active or not.

What we propose is that the proxy that has A's user profile always 
inserts a P-ACR header indicating that, in the event the INVITE request 
reaches a user that has the ACR service active, the session should proceed.

Note that the P-ACR header field will be subject to the same transitive 
trust domain considerations that the P-Asserted-Identity, and thus, it 
does not offer a complete solution. But at least it will work in a 
majority of scenarios.

> The para is very densely worded (in other words, I did not understand

Will do.

> procedure for callflow to make the identification work.

I fully agree with you, and although I am author in the analysis 
documents, I don't agree with the existance of the P-Additional-Identity 
header field. In my opinion what we need here is just the 
P-Asserted-Identity header field in responses. Full period.

> tokens - why can't AoC be another token instead of a new header ?

The IMS P-Charging-Function-Addresses and P-Charging-Vector headers 
specified in RFC3455 are for proxy-to-proxy communication, so they don't 
reach the UA. However, the Advice of Charge information contains 
information that should reach the UA.

In this draft we are discussing the invocation of the service. We are 
not discussing how to convey the information. Most likely, to convey the 
AoC information we will define a MIME type with some structure (this 
does not have an impact on SIP). But for the invocation of the service 
we need an indication, and this is the scope of the P-AoC header.

> be taken. Why does this require event packages and such ?

This seems to be a regulatory requirement, at least here in Europe, to 
provide this service. Basically, a user suspects that a call is 
malicious, perhaps becase is offensive or whatever... I don't care of 
the reasons... but the point is that the human user indicates that "I 
suspect this call is malicious". Then the network has to mark it in a 
log, providing the identity of the caller (if available). This log might 
be requested by the authorities.

So an offline mechanism does not work. Even today the old PSTN has 
mechanisms to provide online indication of malicious calls. So we need a 
mechanism to indicate that a call is considered malicious by a user. We 
are proposing an event package, but we are open to hear other suggestions.

BR,

      MIguel

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 6 Jul 2005 18:07:44 +0200

>document that also describe how things work in the network that needs

I fully agree with this comment. Would it be possible to motivate why one 
would need / want these simulated services, other than that they are being 
defined by the TISPAN NGN project?

Regards,

Jeroen

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 6 Jul 2005 18:49:19 +0200

All,

Triggered by the discussion on ISDN simulation services: is there any work 
being done on some kind of framework for 'features', i.e. functionality that 
can be enabled on a per-entity basis which affects the way calls to/from 
them are handled?

Such a framework could e.g. define:
- how features are identified
- how features are enabled / disabled
- how features can be overruled (like in the "Anonymous Communication 
Rejection" example)
- how the effect of features is reported back to callers / callees

NB what I call 'features' here some would call 'services', but I hope you 
get the notion

Regards,

Jeroen

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 6 Jul 2005 13:01:24 -0400

> From: Jeroen van Bemmel
>
> NB what I call 'features' here some would call 'services',
> but I hope you get the notion

My impression is that the Sip Forum Technical Committee is supposed to look
at SIP in this manner, that is, how user-level "features" are implemented
with SIP protocol actions.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Jul 2005 18:56:29 -0400

Miguel Garcia wrote:

>> 2.2.1: How exactly will this work in the SIP world ? Here we make an

> does not offer a complete solution. But at least it will work in a 

I think this "feature" sucks.

I end up with an ACR feature that sometimes lets anonymous calls 
through. Apparently I am supposed to trust that it is wise in which ones 
those are.

I think a better solution would be to provide some sort of non-anonymous 
identity for those callers. It doesn't have to be their specific 
identity, but perhaps some abstract identity. E.g. sip:[email-masked], or 
sip:[email-masked].

	Paul

---

From: David R Oran <[email-masked]>
Date: Wed, 6 Jul 2005 19:07:27 -0400

On Jul 6, 2005, at 6:56 PM, Paul Kyzivat wrote:

>> bypass the ACR service at B, so the session is established no  
>> matter whether B has the ACR service active or not.
>> inserts a P-ACR header indicating that, in the event the INVITE  
>> request reaches a user that has the ACR service active, the  
>> session should proceed.
>> Note that the P-ACR header field will be subject to the same  
>> transitive trust domain considerations that the P-Asserted- 
>> Identity, and thus, it does not offer a complete solution. But at  
>> least it will work in a majority of scenarios.
>>
>
> through. Apparently I am supposed to trust that it is wise in which  
> ones those are.
>
> I think a better solution would be to provide some sort of non- 
> anonymous identity for those callers. It doesn't have to be their  
> specific identity, but perhaps some abstract identity. E.g.  
> sip:[email-masked], or sip:[email-masked].
>
I emphatically agree with Paul here.

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 07 Jul 2005 08:59:22 +0300

Paul Kyzivat wrote:
>> request reaches a user that has the ACR service active, the session 
>> should proceed.
>>
>> transitive trust domain considerations that the P-Asserted-Identity, 
>> and thus, it does not offer a complete solution. But at least it will 
>> work in a majority of scenarios.
> 
> 

Well, unfortunately the "feature" itself is beyond my control, it seems 
that it is a regulatory requirement.

> through. Apparently I am supposed to trust that it is wise in which ones 

Yes, that is the case.

> sip:[email-masked].

We can try to investigate if this solution is feasible, but honestly 
speaking, considering that this is a regulatory requirement I think this 
wlil take time.

/Miguel

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 7 Jul 2005 08:19:20 +0200

> that it is a regulatory requirement.

That would be something worth mentioning in the draft as part of a 
motivation on why this is needed. Is this perhaps the common denominator for 
all services listed in the draft? Because I currently don't see why this 
particular set of 14 features should be treated as a group.

>>
>> I end up with an ACR feature that sometimes lets anonymous calls through. 
>> Apparently I am supposed to trust that it is wise in which ones those 
>> are.
>
> Yes, that is the case.
>
>>

What about taking a broader perspective on this, and define an override 
mechanism that will also work for other features besides ACR?

Jeroen

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 07 Jul 2005 10:18:53 +0300

Jeroen van Bemmel wrote:

> 
>> Paul Kyzivat wrote:
>>
>>>
>>>
>>> Miguel Garcia wrote:
>>>
>>> I think a better solution would be to provide some sort of 
>>> non-anonymous identity for those callers. It doesn't have to be their 
>> speaking, considering that this is a regulatory requirement I think 
>> this wlil take time.
>>
> 

I have no problem in taking such approach. This is even part of the goal 
of the requirements, to explore if there is a need for a generalized 
solution.

So you are suggesting a generalized mechanism to override... I am not 
sure what else can be overriden than ACR, but the idea is good enough 
and deserves some thought.

/Miguel

---

From: Dean Willis <[email-masked]>
Date: Thu, 07 Jul 2005 06:50:09 -0500

> sip:[email-masked], or sip:[email-masked].

I also agree completely.

The problem with the PSTN is that it cannot differentiate between 
identity and routing information. The requirement for anonymous calling 
is generally to prevent the called party from learning the routing 
information of the caller, and being therefore able to call back. The 
requirement for anonymous call rejection is to prevent the called party 
from being disturbed by parties unwilling to disclose their identity.

I believe that "anonymous call rejection override" for "official 
purposes" within a SIP system that simulates telephony can be met 
entirely within that system without the need for a SIP extension. Use of 
an "official purpose" (or more precise) role  identifier seems like a 
reasonable way to do this. There are probably other ways to do this as 
well, none of which require a SIP extension.

A note for consideration: While I support discussing TISPAN's 
requirements, I do not in general condone arbitrarily extending SIP so 
that it replicates ISDN's behavior. Further, I do not plan to endorse 
proposed extensions that can be readily replaced by system-specific 
behavior such as the "authorized identity" approach suggest in this 
thread. If we go that route, it won't be long before we've replaced the 
request -URI with a set of "extension headers" scaled to fit the product 
of every user that might exist multiplied by every feature that somebody 
might imagine.
--
Dean

--
Dean

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 7 Jul 2005 10:03:12 -0400

> From: Paul Kyzivat

In a purely abstract sense, any workable ACR-override feature must do
something like this, even if it is only to provide one single verifiable
identity "[email-masked]".  Because of course, the SIP system can't
override ACR just because some INVITE is marked "ACR override", the marking
has to be verifiable by the target of the INVITE.  And the target system, in
order to implement ACR,  *already* has the machinery to verify identities,
since it can't just trust the markings on an INVITE.  So why not just define
an ACR-override identity, and "authorized" requests simply apply that
identity?  That requires no specialized processing for ACR override at the
target system, and not much specialized processing at the source system.

This approach also allows issuing multiple "ACR override" identities, one to
each authorized organization -- while it may be undesirable to identify the
individual that places the call, it is very useful to identify the
*organization*, since it is the organization that vouches for the actions of
the individual.  This will probably become increasingly important as SIP
becomes ubiquitous -- every police organization *in the world* will be able
to place ACR override calls to *any phone in the world*, and a lot of abuses
can be avoided if the originating organization must be identified.

Dale

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 7 Jul 2005 09:38:06 -0500

Thus spake "Miguel Garcia" <[email-masked]>
> > seems to me that 'simulation' is somewhat of a test environment
> > where the services being executed are not real.
>
> I agreee. Unfortunately, whether we wanted or not, botu ITU-T and
> ETSI have agree on using the terms "PSTN/ISDN simulation" to
> refer to, say, SIP networks in NGN, and "PSTN/ISDN emulation"
> to refer to packet networks with classic phones, where one of this
> network could be a SIP networks that carries ISUP bodies.
>

You might want to explicitly define the terms at the top of the draft and
explain why they're used (reference to another standards body) instead of
the terms IETFers will expect -- if you haven't already (I haven't read this
particular draft).

> > assumption that the serving Proxy/AS knows that user A has an
> > ACR service.  However, what is User A simply sent a REGISTER
> > message to its registrar with the contact of the ACR without
> > explicitly defining that its an ACR - how does the proxy know
> > who is the real user and how to route directly to the "real" UA ?
>
> authority who typically will remain anonymous. This session has
> to bypass the ACR service at B, so the session is established no

So you're suggesting that UASes be modified so they cannot reject a call
from the police?  I find this highly questionable and hope it wasn't what
you meant.

Also, as a user, I know that if I have ACR enabled and I receive an
anonymous call, I will know that the caller _must_ be the police.  If the
police are calling me anonymously, odds are I don't want to talk to them, so
I simply wouldn't answer the call (or in the case above, unplug the phone).

The "role" URI for such official functions seems a much cleaner solution
since it's just as ineffective yet doesn't require a protocol change.

> does not offer a complete solution. But at least it will work in a

This seems reasonable if that model were agreed upon.

> > 2.7: MCID1 and MCID-2
> >
> > What are the motivations for this requirement ? What constitutes
> > a 'malicious call' and what does does the AS do when such a
> > call is detected ? I assume that since this seems to be a walled
> > network, relevant information about the call will be logged as
> > admin CDR - if a malicious call were to reach a user, a user
> > could use any offline mechanism to notify the admin of the
> > malicious call and action could be taken. Why does this require
> > event packages and such ?
>

Wouldn't the requirement be equally well-met by the "network" recording all
calls?  All of the SIP B2BUAs I've worked with do that by default.

> So an offline mechanism does not work. Even today the old PSTN
> has mechanisms to provide online indication of malicious calls. So
> we need a mechanism to indicate that a call is considered
> malicious by a user. We are proposing an event package, but we
> are open to hear other suggestions.

The only function available for this in my part of the PSTN is to call a
human at the telco and report it (and they typically tell me to call the
police in the offender's jurisdiction).  Things may be better in your area.

S

Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Jul 2005 15:20:48 -0400

> since it's just as ineffective yet doesn't require a protocol change.

I love it!

If this goes thru I can put on my resume that I was the first one to 
suggest a new mechanism in sip that was "just as ineffective as the 
PSTN". :-)

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 05 Jul 2005 14:43:45 +0300

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.

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.

BR,

       Miguel

---

From: David R Oran <[email-masked]>
Date: Fri, 15 Jul 2005 11:27:43 -0400

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...

>> 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.
>>> And I have also submitted another draft that proposes a P-  
>>> header  to support the Advice of Charge service.
>>>
>>>> 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:
>>>> 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.