Subject: RE: [Sip] updated acr code draft

From: "Rajeev Narang \(ranarang\)" <[email-masked]>
Date: Thu, 10 Aug 2006 18:47:47 +0530

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. 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. Probably 433 followed by 180 on INVITE dialog will not look appropriate.

The dialog1 is already an established dialog so BYE will be sent.

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 and BYE with Reason header carrying SIP Status=433 could be sent from UA2 to b2bua on dialog4.

Could we get clarification on this so that standard approach can be used.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Aug 2006 10:03:47 -0400

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:
> 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.
> 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.

> 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