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

From: "Jesske, R" <[email-masked]>
Date: Thu, 7 Jul 2005 12:41:16 +0200

Thank you for this discussion.
I will take this back to TISPAN and we will discuss it next week.
Important is that we can fulfil several requirements.
1. to include a general header in the P-Asserted-Identity that says something like override
2. to include a header saying that this P-Asserted-Identity was provided by the network or is anonymous due to an interworking appeared.

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Miguel Garcia [mailto:[email-masked]] 
> Gesendet: Donnerstag, 7. Juli 2005 07:59
> An: Paul Kyzivat
> Cc: Arjun Roychowdhury; Jesske, Roland; [email-masked]
> Betreff: Re: [Sipping] Re: New Draft on TISPAN analysis for 
> SIP solutions concerning the simulation Services
> 
> 
> Paul Kyzivat wrote:
> > 
> > 
> > Miguel Garcia wrote:
> > 
> >>> 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.
> > 
> > 
> > I think this "feature" sucks.
> 
> Well, unfortunately the "feature" itself is beyond my 
> control, it seems 
> that it is a regulatory requirement.
> 
> > 
> > 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.
> 
> > 
> > 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].
> 
> 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
> 
> > 
> >     Paul
> 
> -- 
> 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