Subject: Re: AW: [Sip] updated acr code draft

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Sep 2006 16:43:18 -0400

This is an old thread but I wanted to comment since we are now in WGLC.

I dont think this specification should address this issue. THis is well 
into service definition. The meaning of the 433 is clear. Whether a UAS 
sends one on a mid-dialog request is a matter of policy. Whether the UAC 
sends a BYE afterwards is a metter of policy. Whether the UAS sends a 
BYE on receipt of the anonymous update is a matter of policy.

Consequently I think the spec needs to say nothing about any of this. I 
view this all as fodder for call flows for MIG.

-Jonathan R.

Jesske, R wrote:

> ACR seen from service perspective on a strict line should forbid any anonymous behaviour also the below described Xfer scenario. How I release the call should be done due to SIP rules either with 433 or a CANCEL or BYE including a Reason header with SIP 433.
> 
> But there could be also some further scenarios that can be deployed as mentioned below. I think this are valid scenarios and the user should decide if he wants to restrict all anonymous calls or if he wants to allow to pass such Xfer calls.
> 
> BR
> 
> Roland Jesske  
> 
> 
>>-----Ursprüngliche Nachricht-----
>>Von: Paul Kyzivat [mailto:[email-masked]] 
>>Gesendet: Donnerstag, 10. August 2006 16:04
>>An: Rajeev Narang (ranarang)
>>Cc: [email-masked]; Jesske, Roland; Sanjay Sinha (sanjsinh); 
>>Mohammad Al-Taraireh (maltarai)
>>Betreff: Re: [Sip] updated acr code draft
>>
>>
>>I think the behaviors you describe are all valid ones that the 
>>respective UAs may choose to do. And there are other 
>>behaviors that are 
>>equally valid that might be chosen. I don't think sip/sipping 
>>can/should 
>>define these, except as example call flows or maybe best 
>>practices. This 
>>is starting to get pretty deep into feature specification.
>>
>>I think any of the participants in the scenario you describe 
>>should be 
>>prepared to deal with a variety of responses. As best I can 
>>tell, each 
>>one can be dealt with on its own without necessarily 
>>understanding the 
>>bigger picture of what is going on. That is a good thing, since in 
>>general none of the players will know the big picture.
>>
>>More inline.
>>
>>	Paul
>>
>>Rajeev Narang (ranarang) wrote:
>>
>>>Hi,
>>>
>>>I think Mohammad still hasn't got the clarification.
>>>
>>>The scenario is:-
>>>
>>>UA1----dialog1-------b2bua------dialog4----UA2
>>>               dialog2|dialog3
>>>                      |
>>>                     UA3
>>>
>>>Say UA1 uses anonymous for its Name/Number.
>>>Say UA2 would reject the anonymous calls.
>>>UA3 is "not" using anonymous for its Name/Number and will 
>>
>>"not" reject anonymous calls.
>>
>>> 
>>>1) UA1 calls UA3 (dialog1 and dialog2 are established)
>>>2) UA3 puts UA1 on hold and does early attended Xfer to UA2 
>>
>>(dialog3 and dialog4 are in early connected state, UA2 is 
>>still ringing).
>>
>>>The dialog3/dialog4 INVITE dialogs will use the Name/Number 
>>
>>of UA3 in the From header. So UA2 will allow it as dialog4 
>>
>>>is not carrying anonymous Name/Id.
>>>3) UA3 presses the Xfer button again to complete the early 
>>
>>attended Xfer.
>>
>>>Now the identity info of UA1 will be communicated on 
>>
>>dialog4 to UA2 in the UPDATE message say using RPID header. 
>>The INVITE dialog4 will not change the Display Name and Id in 
>>the From header as per the UA1's identity, so it will remain 
>>same as original, which is UA3's identity used during 
>>dialog3/dialog4 establishent.
>>
>>>The question is the handling of UA1's anonymity by UA2 in 
>>
>>the UPDATE message and affect to the INVITE dialog4.
>>
>>>1. Should UPDATE be responded with 433.
>>
>>That is a choice to be made. It would be equally valid to 
>>conclude that 
>>one knew the original caller, (and so has someone to *blame*), and 
>>decide to trust the wisdom of the person doing the transfer.
>>
>>For instance, suppose U3 is secretary and U4 is boss. The 
>>boss may never 
>>take anonymous calls, but the secretary does. The secretary 
>>acts as the 
>>screener for anonymous calls to the boss.
>>
>>
>>>How to handle the INVITE dialog4 as 200 OK is still not 
>>
>>sent on dialog4.
>>
>>>Based on 433 for UPDATE, b2bua can send CANCEL (With Reason 
>>
>>Header carrying Q.850 cause=21 Rejected)to UA2 and UA2 can 
>>send 487 on dialog4. 
>>
>>>2. Or UPDATE is responded with 433 and later 433 is sent on 
>>
>>INVITE dialog4 resulting in clearing the dialog4 on UA2 and b2bua.
>>
>>While UA2 *could* do this, it doesn't make a lot of sense to me. Once 
>>the UPDATE is rejected, the dialog continues as it was 
>>before. There is 
>>no question of the identity of the caller (UA3) and so no 
>>reason to fail 
>>the call with a 433. User 3 and user 4 can continue to talk - 
>>with user 
>>4 complaining to user 3 about trying to transfer an anonymous caller.
>>
>>
>>>Probably 433 followed by 180 on INVITE dialog will not look 
>>
>>appropriate.
>>
>>I don't follow. Which dialog? You can't send a 180 to an invite after 
>>having sent a 433 to the same invite. I don't see anything 
>>odd in other 
>>combinations.
>>
>>
>>>The dialog1 is already an established dialog so BYE will be sent.
>>
>>Presumably this will happen if/when the b2bua has nothing else to 
>>connect it to. As long as UA3 is in the call I wouldn't expect that.
>>
>>
>>>The other scenario:-
>>>If it has been attended Xfer then dialog4 would have been 
>>
>>already established. So in the same anonymous config the
>>
>>>UPDATE could be responded with 433
>>
>>Certainly.
>>
>>
>>>and BYE with Reason header carrying SIP Status=433 could be 
>>
>>sent from UA2 to b2bua on dialog4.
>>
>>As I commented above, I don't see why you would want to do this. From 
>>UA2's perspective it still has a call with a known caller. If 
>>the b2bua 
>>can't maintain that (say because UA3 has sent a BYE) then the b2bua 
>>might need to send a BYE - to all the remaining parties.
>>
>>
>>>Could we get clarification on this so that standard 
>>
>>approach can be used.
>>
>>As I said above, I don't think there is, or need be, a broad standard 
>>for this.
>>
>>	Paul
>>
>>
>>>Regards,
>>>Rajeev
>>>
>>>
>>>-----Original Message-----
>>>From: Jesske, R [mailto:[email-masked]] 
>>>Sent: Monday, August 07, 2006 10:26 AM
>>>To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha 
>>
>>(sanjsinh); Jonathan Rosenberg (jdrosen); [email-masked]
>>
>>>Subject: AW: [Sip] updated acr code draft
>>>
>>>The UAC either should include the identity in the From 
>>
>>header instead of anonymous or don't call again if the user 
>>still wants to be anonymous.
>>
>>>The UAS should close the transactions.
>>>
>>>Best Regards
>>>
>>>Roland
>>>
>>>
>>>>-----Ursprüngliche Nachricht-----
>>>>Von: Mohammad Al-Taraireh (maltarai) [mailto:[email-masked]]
>>>>Gesendet: Freitag, 4. August 2006 16:13
>>>>An: Jesske, Roland; Sanjay Sinha (sanjsinh); Jonathan Rosenberg 
>>>>(jdrosen); [email-masked]
>>>>Betreff: RE: [Sip] updated acr code draft
>>>>
>>>>
>>>>
>>>>The identity in the From header in not the correct party after the 
>>>>xfer is complete! I still don't see an answer to what 
>>
>>should the UAC 
>>
>>>>do when it gets the 433 response, or what the UAS should 
>>
>>do after it 
>>
>>>>send the 433, basically how does that response impact the INVITE 
>>>>dialog.
>>>>
>>>>Thanks,
>>>>
>>>>Mo
>>>>
>>>>-----Original Message-----
>>>>From: Jesske, R [mailto:[email-masked]]
>>>>Sent: Friday, August 04, 2006 4:14 AM
>>>>To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha 
>>
>>(sanjsinh); Jonathan 
>>
>>>>Rosenberg (jdrosen); [email-masked]
>>>>Subject: AW: [Sip] updated acr code draft
>>>>
>>>>There is a difference between an unavailable identity and 
>>
>>a anonymous 
>>
>>>>identity so that the endpoint can decide.
>>>>As a wrote before the From header is a mandatory header. 
>>
>>So there must 
>>
>>>>an identity in.
>>>>
>>>>In which scenario this early attended transfer could 
>>
>>appear is this 
>>
>>>>also a interworking case or a pure SIP case?
>>>>
>>>>What is with the identity I'm registering with?
>>>>
>>>>
>>>>BR
>>>>
>>>>Roland
>>>>
>>>>
>>>>>-----Ursprüngliche Nachricht-----
>>>>>Von: Mohammad Al-Taraireh (maltarai) [mailto:[email-masked]]
>>>>>Gesendet: Donnerstag, 3. August 2006 16:22
>>>>>An: Sanjay Sinha (sanjsinh); Jesske, Roland; Jonathan Rosenberg 
>>>>>(jdrosen); [email-masked]
>>>>>Cc: Mohammad Al-Taraireh (maltarai)
>>>>>Betreff: RE: [Sip] updated acr code draft
>>>>>
>>>>>
>>>>>
>>>>>Another case is a early attended transfer. For example 
>>
>>the transfer 
>>
>>>>>target will get an INVITE without caller id blocking and then an 
>>>>>UPDATE after the xfer with caller id blocking to change the
>>>>
>>>>display. 
>>>>
>>>>>If there is a policy on the endpoint to reject anonymous
>>>>
>>>>calls, what
>>>>
>>>>>should the do in this case? which the question below 
>>
>>"what does 433 
>>
>>>>>mean for mid call UPDATE or reINVITE?"
>>>>>
>>>>>Thanks,
>>>>>
>>>>>Mo
>>>>>
>>>>>-----Original Message-----
>>>>>From: Sanjay Sinha (sanjsinh)
>>>>>Sent: Thursday, August 03, 2006 9:57 AM
>>>>>To: Jesske, R; Jonathan Rosenberg (jdrosen); [email-masked]
>>>>>Subject: RE: [Sip] updated acr code draft
>>>>>
>>>>>Scenario is PSTN-SIP interworking. For some cases, display
>>>>
>>>>IE is not
>>>>
>>>>>available in SETUP because some TCAP query is required. 
>>>>
>>>>When the query
>>>>
>>>>>is complete, switch sends display IE in a FACILITY message. From 
>>>>>header is mandatory in INVITE, but calling name and number
>>>>
>>>>is not. So
>>>>
>>>>>Invite is sent without caller-identity which is later
>>>>
>>>>updated with an
>>>>
>>>>>UPDATE/INFO, when the UA gets FACILITY with display information.
>>>>>
>>>>>Thanks
>>>>>Sanjay. 
>>>>>
>>>>>-----Original Message-----
>>>>>From: Jesske, R [mailto:[email-masked]]
>>>>>Sent: Thursday, August 03, 2006 1:52 AM
>>>>>To: Sanjay Sinha (sanjsinh); Jonathan Rosenberg (jdrosen); 
>>>>>[email-masked]
>>>>>Subject: AW: [Sip] updated acr code draft
>>>>>
>>>>>The ACR service itself reacts only on identities that are
>>>>
>>>>put anonymus
>>>>
>>>>>by the user or on behalf on the user.
>>>>>So if the restriction is based on other reasons ACR will
>>>>
>>>>not terminate
>>>>
>>>>>the call.
>>>>>
>>>>>My question to your scenario is in which case an identity is not 
>>>>>available in an INVITE. The From header is an mandatory
>>>>
>>>>header so the
>>>>
>>>>>>From Header has have an user identity. Or not?
>>>>>
>>>>>The P-Asserted-Identity is set by an trusted network 
>>
>>entity that is 
>>
>>>>>aware of the user sending that request.
>>>>>
>>>>>Best Regards
>>>>>
>>>>>Roland
>>>>>
>>>>>
>>>>>>-----Ursprüngliche Nachricht-----
>>>>>>Von: Sanjay Sinha (sanjsinh) [mailto:[email-masked]]
>>>>>>Gesendet: Mittwoch, 2. August 2006 17:32
>>>>>>An: Jonathan Rosenberg (jdrosen); IETF SIP List
>>>>>>Betreff: RE: [Sip] updated acr code draft
>>>>>>
>>>>>>
>>>>>>What about the case in which caller information is not
>>>>
>>>>available at
>>>>
>>>>>>the time INVITE is sent to establish a call, but is
>>>>
>>>>available later
>>>>
>>>>>>and an UPDATE/INFO is sent by UAC to update the caller-id
>>>>>
>>>>>information.
>>>>>
>>>>>>If UAS rejects UPDATE/INFO with 433, what does it mean for
>>>>>
>>>>>the Invite
>>>>>
>>>>>>dialog.
>>>>>>Should that also be terminated as a result of ACR?
>>>>>>
>>>>>>Thanks
>>>>>>Sanjay
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Jonathan Rosenberg (jdrosen)
>>>>>>Sent: Monday, July 31, 2006 4:31 PM
>>>>>>To: IETF SIP List
>>>>>>Subject: [Sip] updated acr code draft
>>>>>>
>>>>>>I've submitted a minor update to the ACR code draft. Until
>>>>>
>>>>>it appears,
>>>>>
>>>>>>you can pick it up at:
>>>>>>
>>>>>>http://www.jdrosen.net/papers/draft-ietf-sip-acr-code-02.txt
>>>>>>
>>>>>>the changes are:
>>>>>>
>>>>>>* replaced P-Asserted-ID with P-Asserted-Identity
>>>>>>
>>>>>>* added to security considerations section, consideration for 
>>>>>>anonymizers in the network. Namely, don't retry request on
>>>>>
>>>>>receipt of
>>>>>
>>>>>>433 unless explicitly configured to do so by user
>>>>>>
>>>>>>
>>>>>>Thanks,
>>>>>>Jonathan R.
>>>>>>-- 
>>>>>>Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>>>>>>Cisco Fellow                                   Parsippany, NJ 
>>>>>>07054-2711
>>>>>>Cisco Systems
>>>>>>[email-masked]                              FAX:   
>>>>
>>>>(973) 952-5050
>>>>
>>>>>>http://www.jdrosen.net                         PHONE: 
>>>>
>>>>(973) 952-5000
>>>>
>>>>>>http://www.cisco.com
>>>>>>
>>>>>>_______________________________________________
>>>>>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>>>>This list is for NEW development of the core SIP Protocol Use 
>>>>>>[email-masked] for questions on 
>>
>>current sip Use 
>>
>>>>>>[email-masked] for new developments on the application of sip
>>>>>>
>>>>>>_______________________________________________
>>>>>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>>>>This list is for NEW development of the core SIP Protocol Use 
>>>>>>[email-masked] for questions on 
>>
>>current sip Use 
>>
>>>>>>[email-masked] for new developments on the application of sip
>>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>>>This list is for NEW development of the core SIP Protocol Use 
>>>>>[email-masked] for questions on current sip Use 
>>>>>[email-masked] for new developments on the application of sip
>>>>>
>>>>>_______________________________________________
>>>>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>>>This list is for NEW development of the core SIP Protocol Use 
>>>>>[email-masked] for questions on current sip Use 
>>>>>[email-masked] for new developments on the application of sip
>>>>>
>>>>
>>>>_______________________________________________
>>>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>>This list is for NEW development of the core SIP Protocol Use 
>>>>[email-masked] for questions on current sip Use 
>>>>[email-masked] for new developments on the application of sip
>>>>
>>>
>>>_______________________________________________
>>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>This list is for NEW development of the core SIP Protocol 
>>
>>Use [email-masked] for questions on current 
>>sip Use [email-masked] for new developments on the 
>>application of sip
>>
>>>_______________________________________________
>>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>This list is for NEW development of the core SIP Protocol
>>>Use [email-masked] for questions on current sip
>>>Use [email-masked] for new developments on the application of sip
>>>
>>
>>_______________________________________________
>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP Protocol
>>Use [email-masked] for questions on current sip
>>Use [email-masked] for new developments on the application of sip
>>
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Sep 2006 16:46:12 -0400

OK, I will change the text to MUST NOT retry.

-Jonathan R.

Henning Schulzrinne wrote:

> Just a quick comment:
> 
>   request without requesting anonymity.  It SHOULD only do so if it
>    obtains confirmation from the user that this is desirable.  Such
>    confirmation could be obtained through the user interface, or by
>    accessing user defined policy.  The UAC SHOULD NOT retry the request
>    if user continues to request anonymity.
> 
> No guidance is given when the UAC might just retry the request without 
> anonymity and without asking. Is "because it feels like it" a good 
> enough reason :-)? Can a vendor just decide that all its products don't 
> really feel that strongly about anonymity or is this something that only 
> users (or administrators) should be able to configure?
> 
> I think the right answer is that the UAC MUST NOT do this automatically 
> unless the user or administrator has configured an automatic 
> non-anonymous retry.
> 
> 
> Jonathan Rosenberg wrote:
> 
>> I've submitted a minor update to the ACR code draft. Until it appears, 
>> you can pick it up at:
>>
>> * added to security considerations section, consideration
>> for anonymizers in the network. Namely, don't retry
>> request on receipt of 433 unless explicitly configured
>> to do so by user
>>
>>
>> Thanks,
>> Jonathan R.
> 
>