Subject: AW: [Sipping] Re: New Draft on TISPAN analysis for SIP solutionsc oncerning the simulation Services

From: "Jesske, R" <[email-masked]>
Date: Thu, 7 Jul 2005 13:07:54 +0200

Jeroen,
We need these features to integrate this within our network in future.
When operators starting migrating their PSTN/ISDN customers to the TISPAN NGN they want to provide new multimedia services and of course the well known services of the PSTN/ISDN.
And the interoperability with existing networks.

Roland

> -----Ursprüngliche Nachricht-----
> Von: Jeroen van Bemmel [mailto:[email-masked]] 
> Gesendet: Mittwoch, 6. Juli 2005 18:08
> An: Arjun Roychowdhury; Miguel Garcia
> Cc: Jesske, Roland; [email-masked]
> Betreff: Re: [Sipping] Re: New Draft on TISPAN analysis for 
> SIP solutionsconcerning the simulation Services
> 
> 
> Arjun wrote:
> >
> >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)
> 
> 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 
> 

_______________________________________________
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: "Jesske, R" <[email-masked]>
Date: Fri, 8 Jul 2005 11:45:18 +0200

The ACR service is a mandatory and regulatory service within Europe, so we have to define it within our TISPAN NGN.
There is already defined the Reason header for additional use to Requests.
And it is also stated that:

   "Initially, the Reason header field defined here appears to be most
   useful for BYE and CANCEL requests, but it can 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 I only try to legalise the last sentence.

ACR is not the only service.

Also the PSTN/ISDN - SIP - PSTN/ISDN Scenario needs information about the release cause.
Because mapping the ISUP Cause Value to a Response code and back to an ISDN/PSTN cause value is not fulfilling our requirements.

E.G. 
The Cause Values 22 and 23 in RFC3398 will be mapped to 410
22 number changed (w/o diagnostic)      410 Gone
23 redirection to new destination       410 Gone

But 410 will only be mapped back to Caus 22
410 Gone                              22 Number changed
                                            (w/o diagnostic)
Therefore Information is lost

Also the ITU-T specification has such examples.

E.G

The ISUP Release Causes : 38, 41, 42, 43, 44, 47, 50, 57, 58, 63, 100 and others are mapped to Response code 500
500 will be mapped back to 127.

So a lot of information is lost.

So this is also behind this draft to allow a seamless traversing (using the SIP network for service cases e.G redirection) of SIP networks without using SIP-T. 

Roland
> Gesendet: Donnerstag, 7. Juli 2005 21:31
> An: Jesske, Roland; [email-masked]; [email-masked]
> Cc: [email-masked]
> > So this is the main behind the requirement. We are 
> proposing to use the 
> > Reason header in responses where I wrote a Draft:
> > 
> http://www.ietf.org/internet-drafts/draft-jesske-sipping-etsi-
ngn-reason-00.txt

What I don't like about this proposal, is that it puts ISDN specific 
requirements on a potentially generic service (assuming for the moment that 
ACR would be a desirable one).  Q.850 codes like #24 are specific to ISDN, 
so I would expect the gateway to make such a mapping based on a more generic 
failure reason. I imagine that such a failure reason would refer to the 
feature that caused the failure, by name or other identifying mechanism, 
rather than some obscure code

I don't have a concrete example right now but suppose there were a second 
type of network that wants to interoperate with these SIP based services. In 
this network, failure due to ACR is #34. I will admit this is somewhat 
hypothetical, but I hope you get the drift

I do believe there is a general need for more detailed reason codes, the 
response code space is small and it would not be desirable (nor feasible) to 
reserve a new code for each new feature that may cause errors. So I would 
expect something like the Reason header proposed could be put to use, albeit 
in a more generic access-independent form

Regards,

jeroen

---

From: "Jesske, R" <[email-masked]>
Date: Fri, 8 Jul 2005 13:15:23 +0200

Dear Arjun,
Of course an emergency call has to have priority.
The ACR overwrite is a feature that not only allows the police to overwrite ACR. This is also thought by situations where the network is guilty when the P-Asserted-Identity is missing. E.G a call coming from an analogue network can not include a number of the caller. So in this cases the call should also bypass the ACR service. That is why we have the "restricted by the network" parameter within the ISUP.

Roland

> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Arjun Roychowdhury
> Gesendet: Donnerstag, 7. Juli 2005 20:21
> An: [email-masked]
> SIP solutionsc oncerning the simulation Services
> 
> 
> Hi,
> I agree. As I mentioned before, I don't think the focus here is the
> ACR. The focus here, is that the call needs to directly reach the
> endpoint irrespective of any policy rules.
> 
> Therefore, P-ACR is very limiting - instead, it should just be a
> general mechanism that is a guideline for the serving AS (or proxy or
> whatever) to know that this call needs to be 'short-circuited' .
> 
> In addition, the draft talks about this interface being required for
> situations when, say, the police calls you. Is just specifying P-ACR
> (or similar) enought ? What about the fact that the called UA may
> already be in a call ? What if resource prioritization is required ?
> Can this not be classified as an 'emergency' call and follow the
> directives laid out by the processing requirements of an 'emergency'
> call ? IEPREP WG published RFC 3487 for emergency requirements though
> I have not yet seen a realization of the requirements - but does it
> make sense to refer to their work instead of creating a new 'emergency
> like' intended header ?
> 
> regds
> arjun
> 
> 
> On 7/7/05, Jeroen van Bemmel <[email-masked]> wrote:
> > 
> > My point was that rather than defining something specific 
> for the ACR
> > service, why not use something a bit more general. I could 
> imagine for
> > example a 'caller restriction' feature that would allow 
> subscribers to
> > specify a white list of identities from whom they wish to 
> receive calls, all
> > others are blocked. Also such a service would need an 
> override mechanism
> > 
> 
> -- 
> Arjun Roychowdhury
>

---

From: "Jesske, R" <[email-masked]>
Date: Fri, 8 Jul 2005 13:33:16 +0200

Comments inline.

Roland

> Von: Stephen Sprunk [mailto:[email-masked]] 
> Gesendet: Donnerstag, 7. Juli 2005 16:38
> An: Miguel Garcia; Arjun Roychowdhury
> Thus spake "Miguel Garcia" <[email-masked]>
> > 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.
> 
> 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).

We will take care of this issue in the next draft to give the reader a clue what's behind simulation services.
> 
> > > 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.
> 
> 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.
> 
> > 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.
> 
> 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 ?
> >
> > 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.
> 
> 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.
Of course this is one possibility, but we want to have also a case by case possibility to catchemaliciouss communications.
A other point is that in some cases PSTN/ISDN networks do not deliver a P-Asserted-Identity/calling party number.
Therefore a request/response mechanism in the PSTN/ISDN is foreseen. So within SIPtherer should besomem equal mechanism to have such interoperability with thePSTNN/ISDN.

> 
> > 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: "Jesske, R" <[email-masked]>
Date: Fri, 8 Jul 2005 14:49:33 +0200

Comments inline

Roland

> [mailto:[email-masked]] Im Auftrag von David C. Robbins
> Gesendet: Freitag, 8. Juli 2005 14:30
> An: Arjun Roychowdhury; [email-masked]
> At 2:21 PM -0400 7/7/05, Arjun Roychowdhury wrote:
> >Hi,
> Rather than thinking of this as "irrespective of any policy rules," 
> wouldn't it be more appropriate to think of this in terms of living 
> within policy rules regarding which INVITEs are accepted?  For 
> example, in one regulatory regime, policy is that *all* anonymous 
> communications are rejected, while in another, certain authorized 
> callers are accepted -- as a matter of policy -- even though they are 
> not identified in the usual manner.  The service is not so much 
> bypassing policy rules as it is modifying policy rules by making 
> certain exceptions to a general rule.
> 
> What about a communication in which the two parties are in different 
> regulatory regimes with different policies?  Whose policy applies? 
> And what if the policies conflict?

ACR is a service bind to the destination so the policy valid is the destination network.
> 
> ACR is just one instance of the general case of policies that 
> determine whether a call is accepted.  (And here, "accepted" means 
> "permitted to alert the user" -- no policy can force the user to 
> actually answer the call.)  So wouldn't we recommend that ACR be 
> realized in terms of some policy framework?  And to support such a 
> policy, w.r.t. the recipient of the call, the caller would have to 
> provide sufficient information that the policy can be applied 
> appropriately.  Which may get back to the idea about the caller being 
> identified by a distinguished URI such as [email-masked].  And for 
> the policy to be truly useful, that identity would need to be 
> authenticated.

We tried to be general by using such a bypass mechanism.
> 
> As to the policy framework itself, a mechanism for specifying and 
> applying policy is probably outside the scope of SIPPING.

It is not only the police it is  also such network based anonymity like the originating user is sitting in a analogue network.
> Here are more factors that may be taken into account by the policy. 
> The more you think about it, the more complex it gets, and the more 
> you see that the simple notion of a header that says "bypass ACR" is 
> of very limited utility.

To use such emergency rules for such a service override I think is dangerous because all communications that bypass because of some network restriction are per definition now a emergency call.
> >>  service, why not use something a bit more general. I 
> could imagine for
> --------------------------------------------------------------
> -----------
> Dave Robbins                                         Verizon 
> Laboratories
> E-mail: [email-masked]    40 Sylvan Rd., Waltham, 
> MA 02451-1128
> 
>

---

From: "Jesske, R" <[email-masked]>
Date: Mon, 11 Jul 2005 18:23:44 +0200

Jeroen,
ACR is a subset of ICB.
With rgard to ICB a specific or Block of URI's shall be blocked.
This service does not need such a bypass, because this service is not based on restrictions. 

Roland

-----Originalnachricht-----
Von: Jeroen van Bemmel
An: Jesske, Roland; [email-masked]; [email-masked]
Cc: [email-masked]
Gesendet: 08.07.05 21:27
Betreff: Re: [Sipping] Re: New Draft on TISPAN analysis for SIP solutionsc oncerning the simulation Services

Roland,

So wouldn't the same requirement (authority bypass) apply to ICB as well

then? There appear to be no requirements for ICB in the draft

Jeroen

----- Original Message ----- 
From: "Jesske, R" <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 08, 2005 12:56 PM
Subject: AW: [Sipping] Re: New Draft on TISPAN analysis for SIP
solutionsc 
oncerning the simulation Services

Jeroen,
ACR is a subset of a service called ICB (Incomming communication
barring). 
Blacklist Service that will be administered in a AS on behalf of the
user.
This restriction of incoming communications is based on the
P-Asserted-ID.
For ACR we are using the privacy header field to restrict
communications.
So for the overwriting of ACR the idea appeared to use a priv value like

"network" (as it is within the PSTN/ISDN) to say that the privacy 
restriction was caused by network purposes (including such police
calls). 
But we saw that this could contradict with the definition of the privacy

header so we came up with this bypass header.

We have also a Service called Outgoing Communication barring that
restricts 
communication to special numbers/URI's for the caller. This is was
defined 
due to the fact to be sure that children do not call high priced
numbers.

So you see we put together several barring services.

Best Regards

> Gesendet: Donnerstag, 7. Juli 2005 19:55
> Roland,
> I was thinking about the trait-based authorization framework
> (see email on
> this list 20-6-2005 :
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-trait-a
> uthz-01.txt)
> to convey 'authority' along with a request. But in an
> operator controlled
> network you may be better of with a trusted entity that
> appends some header
> instead, e.g. P-Authority : police
>
> The ACR service implementation would then have to behave accordingly
>
> My point was that rather than defining something specific for the ACR
> ----- Original Message ----- 
> From: "Jesske, R" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>;
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, July 07, 2005 1:02 PM
> Subject: AW: [Sipping] Re: New Draft on TISPAN analysis for
> SIP solutionsc
> I'm happy about SIP extensions that can be used for our
> services so if you
> have something in mind please guide us.
>
> Thanks
>
> Roland
>
> > [mailto:[email-masked]] Im Auftrag von Drage,
> Keith (Keith)
> > Gesendet: Mittwoch, 6. Juli 2005 14:25
> > An: Jeroen van Bemmel; Miguel Garcia
> > Cc: [email-masked]
> > Betreff: RE: [Sipping] Re: New Draft on TISPAN analysis for
> > In general, we believe we have reused existing headers and so
> > on to meeting requirements either appearing in the
> > requirements draft, or not appearing at all, because we
> > believe that the solution is met by existing SIP.
> >
> > Thus for example there are no requirements relating to the
> > bulk of passing forwarding information around, because that
> > is substantially met by an already approved extension
> > defining the History-Info solution; as a result of no
> > requirements, there is no need to invent a solution.
> >
> > While I agree there is little discussion of alternatives in
> > the solutions draft, much of that is due to existing
> > capabilities quite obviously not meeting the requirements,
> > and therefore there seemed little point in creating
> > documentation to reflect that.
> >
> > However if you believe there are existing SIP solutions to
> > the requirements in the requirements draft, then we will be
> > only too happy to take them into account. You may have some
> > knowledge of the way things are already applied in SIP that
> > meet the requirements.
> >
> > regards
> >
> > Keith
> >
> > Keith Drage
> > Lucent Technologies
> > [email-masked]
> > tel: +44 1793 776249
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On
> > > Behalf Of Jeroen van Bemmel
> > > Sent: 05 July 2005 19:00
> > > To: Miguel Garcia
> > > Cc: [email-masked]
> > > Subject: Re: [Sipping] Re: New Draft on TISPAN analysis for SIP
> > > solutionsconcerning the simulation Services
> > >
> > >
> > > 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
> > >
> > >
> > > > 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-tispa
> > > n-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-tisp
> > > an-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
> > > Sipping mailing list
> https://www1.ietf.org/mailman/listinfo/sipping
> > > Sipping mailing list
> https://www1.ietf.org/mailman/listinfo/sipping