RE: AW: AW: AW: [Sipping-tispan] TISPAN requirements, first requiements

["Michael Hammer \(mhammer\)" <[e-mail]>]

Miguel,

Does it matter that an "anonymous" call is showing up at the phone?  How
long do you think before the recipient figures out that only an
"authority" could force such calls to him despite anonymous call
blocking?

That lead me to wonder whether the call had to assert a bogus calling
party number?  And if so, wouldn't it be better to assert an identity
controlled from the original domain of the call?  And if so, why even
bother follow-on networks with additional work to do to manipulate
headers for override, when the originating network could construct a
perfectly "non-anonymous" call?  Seems like this could be simpler.

Perhaps, I didn't understand the fundamental purpose here.

Mike

> -----Original Message-----
> From: Miguel Garcia [mailto:[e-mail]] 
> Sent: Monday, August 29, 2005 2:50 AM
> To: Michael Hammer (mhammer)
> Cc: Jesske, R; [e-mail]; Alexeitsev, D
> Subject: Re: AW: AW: AW: [Sipping-tispan] TISPAN 
> requirements, first requiements
> 
> But this solution of adding a parameter to the 
> P-Asserted-Identity works. IMS supports from day one RFC 
> 3325, so there are procedures to add/delete the 
> P-Asserted-Identity when traversing a trust domain.
> 
> Now, if you add a parameter to that header field, proxies 
> that do not support the extension will not act upon it, so 
> they will forward it if present and if the 
> P-Asserted-Identity header fiedl has to be forwarded. 
> If the header field is stripped, it will include the 
> parameter, which is, in my opinion, the correct behaviour.
> 
> /Miguel
> 
> Michael Hammer (mhammer) wrote:
> 
> > My concern over what gets put into the message, is that those 
> > indicators could potentially be leaked to the UAS because some 
> > intermediate node was not updated with the latest RFC, and 
> according 
> > to SIP merely passed on what it did not understand.
> > 
> > Mike
> >  
> > 
> > 
> >>-----Original Message-----
> >>From: [e-mail] 
> >>[mailto:[e-mail]] On Behalf Of Miguel Garcia
> >>Sent: Friday, August 26, 2005 7:44 AM
> >>To: Jesske, R
> >>Cc: [e-mail]; Alexeitsev, D
> >>Subject: Re: AW: AW: AW: [Sipping-tispan] TISPAN 
> requirements, first 
> >>requiements
> >>
> >>Hi Roland:
> >>
> >>If you don't have a P-Asserted-Identity in the signalling, 
> is because 
> >>the trust relationship has been broken at some point, in 
> which case, 
> >>you shouldn't trust also the role parameter independently of the 
> >>header where you put it.
> >>
> >>The nice property of adding a role parameter to the 
> >>P-Asserted-Identity header is that you get the trust for 
> free, which 
> >>is the expected behaviour for this service.
> >>
> >>/Miguel
> >>
> >>Jesske, R wrote:
> >>
> >>
> >>>>>I think it might be worth considering adding role parameters to 
> >>>>>P-Asserted-ID.
> >>>>
> >>>>That is OK with me and solves most of the problems.
> >>>>
> >>>
> >>>
> >>>
> >>>Paul,
> >>>I have to revice my proposal. 
> >>>I thought that is the solution to bind it to the
> >>
> >>P-Asserted-Id. But in the case were we have a anonymous 
> communication 
> >>restricted by the network. We usually have no Calling Party number. 
> >>And therefore also no P-Asserted-Identity.
> >>
> >>>So we cannot bind this to the P-Asserted-Identity.
> >>>
> >>>Perhaps we can bind it to the privacy header?
> >>>
> >>>Or any other?
> >>>
> >>>Best Regards.
> >>>
> >>>Roalnd
> >>>
> >>>_______________________________________________
> >>>Sipping-tispan mailing list
> >>>[e-mail]
> >>>https://www1.ietf.org/mailman/listinfo/sipping-tispan
> >>
> >>-- 
> >>Miguel A. Garcia           tel:[phone]
> >>sip:[e-mail]
> >>Nokia Research Center      Helsinki, Finland
> >>
> >>
> >>_______________________________________________
> >>Sipping-tispan mailing list
> >>[e-mail]
> >>https://www1.ietf.org/mailman/listinfo/sipping-tispan
> > 
> > 
> 
> -- 
> Miguel A. Garcia           tel:[phone]
> sip:[e-mail]
> Nokia Research Center      Helsinki, Finland
> 

_______________________________________________
Sipping-tispan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-tispan