[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> -----Ursprüngliche Nachricht-----
> Von: Jeroen van Bemmel [mailto:jbemmel at zonnet.nl]
> Gesendet: Donnerstag, 7. Juli 2005 19:55
> An: Jesske, Roland; drage at lucent.com; Miguel.An.Garcia at nokia.com
> Cc: sipping at ietf.org
> Betreff: Re: [Sipping] Re: New Draft on TISPAN analysis for
> SIP solutionsc oncerning the simulation Services
>
>
> 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
> 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
>
> Regards,
>
> Jeroen
>
> ----- Original Message -----
> From: "Jesske, R" <R.Jesske at t-com.net>
> To: <drage at lucent.com>; <jbemmel at zonnet.nl>;
> <Miguel.An.Garcia at nokia.com>
> Cc: <sipping at ietf.org>
> Sent: Thursday, July 07, 2005 1:02 PM
> Subject: AW: [Sipping] Re: New Draft on TISPAN analysis for
> SIP solutionsc
> oncerning the simulation Services
>
>
> Jeroen,
> 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
>
> > -----Ursprüngliche Nachricht-----
> > Von: sipping-bounces at ietf.org
> > [mailto:sipping-bounces at ietf.org] Im Auftrag von Drage,
> Keith (Keith)
> > Gesendet: Mittwoch, 6. Juli 2005 14:25
> > An: Jeroen van Bemmel; Miguel Garcia
> > Cc: sipping at ietf.org
> > Betreff: RE: [Sipping] Re: New Draft on TISPAN analysis for
> > SIP solutionsc oncerning the simulation Services
> >
> >
> > 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
> > drage at lucent.com
> > tel: +44 1793 776249
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org]On
> > > Behalf Of Jeroen van Bemmel
> > > Sent: 05 July 2005 19:00
> > > To: Miguel Garcia
> > > Cc: sipping at ietf.org
> > > 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: r.jesske at t-com.net
> > > > >
> > > >
> > > > --
> > > > Miguel A. Garcia tel:+358-50-4804586
> > > > sip:miguel.an.garcia at 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 at cs.columbia.edu for questions on
> current sip
> > > > Use sip at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
> > > Use sip at 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 at cs.columbia.edu for questions on current sip
> > > Use sip at 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 at cs.columbia.edu for questions on current sip
> > Use sip at 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP