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

[Miguel Garcia <[e-mail]>]

Hi Arjun:

Thanks for your comments, see inline discussion.

Arjun Roychowdhury wrote:

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

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.

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

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.

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


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.

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

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.

> 
> 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 ;-)
> 

Will do.

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

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.

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

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.

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

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
> 
> 
> regds
> arjun
> 
> 
> 
> On 7/1/05, Miguel Garcia <[e-mail]> 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:  [phone]
>>>Fax:      [phone]
>>>email:   [e-mail]
>>>
>>
>>--
>>Miguel A. Garcia           tel:[phone]
>>sip:[e-mail]
>>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 [e-mail] for questions on current sip
>>Use [e-mail] for new developments of core SIP
>>
> 
> 
> 

-- 
Miguel A. Garcia           tel:[phone]
sip:[e-mail]
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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP