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

[Arjun Roychowdhury <[e-mail]>]

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



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
> 


-- 
Arjun Roychowdhury

_______________________________________________
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