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

["GARCIN Sebastien RD-CORE-ISS" <[e-mail]>]

Hi, 

Yes, the call indeed does need to stay anonymous for the SIP end point. 

Also I think we shouldn' make too many assumption of which entity will be involved (proxy UAS, UAC...). This requirement is for one SIP entity to notify another SIP entity of that the call is anonymous and has an "ACR override" property.

The solution that Miguel described (adding a parameter to P-A-ID) is fine with me. 

Regards,
sebastien   

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de Miguel Garcia
Envoyé : lundi 29 août 2005 08:50
À : Michael Hammer (mhammer)
Cc : [e-mail]; Alexeitsev, D
Objet : 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

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