[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] updated acr code draft
Hi Paul,
Please see response inline...[RAJEEV]
-----Original Message-----
From: Paul Kyzivat (pkyzivat)
Sent: Thursday, August 10, 2006 7:34 PM
To: Rajeev Narang (ranarang)
Cc: Jonathan Rosenberg (jdrosen); sip at ietf.org; Jesske, R; Sanjay Sinha (sanjsinh); Mohammad Al-Taraireh (maltarai)
Subject: 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.
[RAJEEV: This is a good example/explanation.
]
> 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.
[RAJEEV:-
In early attended Xfer case, user3 and user2 will not get chance to talk as the Xfer will take place after 180 Ringing from UA2 to b2bua (on dialog4) and b2bua to UA3 (on dialog3) and before 200 OK i.e user2 (UA2) is still "not" offhook.
Actually the point is if b2bua/ua2 wants to implement a policy to not allow such transfers from anonymous user to user restricting anonymous calls, then can UPDATE/433 be handled by sending a CANCEL from b2bua on dialog4 to UA2. I think there is no clear specification on that, so we wanted to get a clarification on this if that is good to do from b2bua.
Also if UA2 wants to clear the call based on its local policy for not allowing such Xfer then what should be sent on INVITE dialog4, which is in early connected state.
]
> 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.
[RAJEEV:-
This is dialog4 from b2bua to UA2. For early attended Xfer, the UA2 would have sent 100/180 on receiving INVITE. While 180 is received by UA3 on dialog3, the Xfer button press again will do the Xfer.
Next b2bua will send an UPDATE on dialog4 to UA2 (with Name/Id privacy info about UA1), for which 433 could be sent from UA2. So 433 on INVITE dialog could be sent, but that may be odd.
]
> 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.
[RAJEEV:-
It could be based on the policy for the b2bua whether to allow such Xfer or not. I agree if the policy is to allow such Xfer then BYE shouldn't 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
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.
[RAJEEV:-
For Attended Xfer i.e dialog4 got established and UA2 user talked with UA3 user, if UA2 independently wants to take the decision that it will not allow the Xfer from anonymous users based on the local policy then probably it may send BYE after UPDATE/433 handling.
But a policy could be relaxed by UA2 in this case because UA3 user already talked with UA2 user and got the permission verbally, so UA2 may continue with the Invite dialog by sending 200 OK.
Thanks,
Rajeev
]
> 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:R.Jesske at t-com.net]
> Sent: Monday, August 07, 2006 10:26 AM
> To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha (sanjsinh); Jonathan
> Rosenberg (jdrosen); sip at ietf.org
> 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:maltarai at cisco.com]
>> Gesendet: Freitag, 4. August 2006 16:13
>> An: Jesske, Roland; Sanjay Sinha (sanjsinh); Jonathan Rosenberg
>> (jdrosen); sip at ietf.org
>> 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:R.Jesske at t-com.net]
>> Sent: Friday, August 04, 2006 4:14 AM
>> To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha (sanjsinh);
>> Jonathan Rosenberg (jdrosen); sip at ietf.org
>> 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:maltarai at cisco.com]
>>> Gesendet: Donnerstag, 3. August 2006 16:22
>>> An: Sanjay Sinha (sanjsinh); Jesske, Roland; Jonathan Rosenberg
>>> (jdrosen); sip at ietf.org
>>> 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); sip at ietf.org
>>> 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:R.Jesske at t-com.net]
>>> Sent: Thursday, August 03, 2006 1:52 AM
>>> To: Sanjay Sinha (sanjsinh); Jonathan Rosenberg (jdrosen);
>>> sip at ietf.org
>>> 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:sanjsinh at cisco.com]
>>>> 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
>>>> jdrosen at cisco.com 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
>>>> sip-implementors at cs.columbia.edu for questions on current sip Use
>>>> sipping at ietf.org 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
>>>> sip-implementors at cs.columbia.edu for questions on current sip Use
>>>> sipping at ietf.org 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
>>> sip-implementors at cs.columbia.edu for questions on current sip Use
>>> sipping at ietf.org 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
>>> sip-implementors at cs.columbia.edu for questions on current sip Use
>>> sipping at ietf.org 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
>> sip-implementors at cs.columbia.edu for questions on current sip Use
>> sipping at ietf.org 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
> sip-implementors at cs.columbia.edu for questions on current sip Use
> sipping at ietf.org 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
> sip-implementors at cs.columbia.edu for questions on current sip Use
> sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip