Subject: AW: [Sip] updated acr code draft

From: "Jesske, R" <[email-masked]>
Date: Tue, 1 Aug 2006 07:25:09 +0200

In this Draft is described that:
The request contained a Privacy header field whose value was 'id'
      [3] or 'user'.  This explicitly excludes the 'header' and
      'session' privacy services, since those do not directly convey the
      identity of the requestor.

Why the value 'header ' is exluded? 

In RFC3323 is described that header:
      header: The user requests that a privacy service obscure those
      headers which cannot be completely expunged of identifying
      information without the assistance of intermediaries (such as Via
      and Contact).  Also, no unnecessary headers should be added by the
      service that might reveal personal information about the
      originator of the request.

So from my understanding 'id' is a subset of 'header' because the P-Asserted-Identity can only be deleted by untermediarities.

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Jonathan Rosenberg [mailto:[email-masked]] 
Gesendet: Montag, 31. Juli 2006 22:31
An: IETF SIP List
Betreff: [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

---

From: "Sanjay Sinha \(sanjsinh\)" <[email-masked]>
Date: Wed, 2 Aug 2006 11:32:21 -0400

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

the changes are:

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

_______________________________________________
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: "Jesske, R" <[email-masked]>
Date: Thu, 3 Aug 2006 07:52:13 +0200

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

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

---

From: "Sanjay Sinha \(sanjsinh\)" <[email-masked]>
Date: Thu, 3 Aug 2006 09:56:43 -0400

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

Best Regards

Roland

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

---

From: "Mohammad Al-Taraireh \(maltarai\)" <[email-masked]>
Date: Thu, 3 Aug 2006 10:22:16 -0400

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

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

Best Regards

Roland

_______________________________________________
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: "Jesske, R" <[email-masked]>
Date: Fri, 4 Aug 2006 10:05:51 +0200

If you are looking on the Interworking specifications Q.1912.5 (ISUP-SIP) from ITU-T or also the TISPAN Spec ETSI ES 283 027/3GPP TS29.163 a IAM with no Calling Party number will be interworked to an >From header with the content 'unavailable@hostportion'. So the INVITE is marked not anonymus and the call will be sucessfull in the ACR case.

Best Regards

Roland

> Gesendet: Donnerstag, 3. August 2006 15:57
> An: Jesske, Roland; Jonathan Rosenberg (jdrosen); [email-masked]
> 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. 
> 
> The ACR service itself reacts only on identities that are put 
> anonymus by the user or on behalf on the user.
> 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
>

---

From: "Jesske, R" <[email-masked]>
Date: Fri, 4 Aug 2006 10:14:05 +0200

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

> 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)
> 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 
> [email-masked] for questions on current sip

---

From: "Mohammad Al-Taraireh \(maltarai\)" <[email-masked]>
Date: Fri, 4 Aug 2006 10:13:21 -0400

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

BR

Roland

> An: Sanjay Sinha (sanjsinh); Jesske, Roland; Jonathan Rosenberg 
> (jdrosen); [email-masked]
> 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
> 
> 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. 
> 
> 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?
>

---

From: "Jesske, R" <[email-masked]>
Date: Mon, 7 Aug 2006 06:56:27 +0200

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

> Gesendet: Freitag, 4. August 2006 16:13
> An: Jesske, Roland; Sanjay Sinha (sanjsinh); Jonathan 
> 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 
> 
> To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha (sanjsinh); 
> Jonathan Rosenberg (jdrosen); [email-masked]
> There is a difference between an unavailable identity and a 
> anonymous identity so that the endpoint can decide.
> In which scenario this early attended transfer could appear 
> is this also a interworking case or a pure SIP case?
> 
> > 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.
> >

---

From: "Mohammad Al-Taraireh \(maltarai\)" <[email-masked]>
Date: Thu, 10 Aug 2006 10:01:16 -0400

In the B2BUA case we probably need more than just the acr code draft to address this issue. The B2BUA needs something in the backward direction to let UA1 know that the "Anonymous" id is not allowed after it gets the 433 response from UA2, to give UA1 the opportunity to reveal its id if it wishes or to keep it as "Anonymous". Since we don't have that yet, the B2BUA should probably just CANCEL the early dialog after it gets the 433 response to the UPDATE. This is not the best user experience but it will enforce the configured policy on UA2.

Thanks,

Mo

-----Original Message-----
From: Rajeev Narang (ranarang) 
Sent: Thursday, August 10, 2006 9:18 AM
To: Jonathan Rosenberg (jdrosen); [email-masked]
Cc: Jesske, R; Mohammad Al-Taraireh (maltarai); Sanjay Sinha (sanjsinh)
Subject: RE: [Sip] updated acr code draft

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

Best Regards

Roland

> An: Jesske, Roland; Sanjay Sinha (sanjsinh); Jonathan Rosenberg 
> (jdrosen); [email-masked]
> 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
> 
> There is a difference between an unavailable identity and a anonymous 
> identity so that the endpoint can decide.
> In which scenario this early attended transfer could appear is this 
> also a interworking case or a pure SIP case?
>

---

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

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); [email-masked]; 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:
> 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.
> 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.
> 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

---

From: "Jesske, R" <[email-masked]>
Date: Mon, 14 Aug 2006 07:37:19 +0200

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  

> 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
> 
> > 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.
> > 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.
> > 
> 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.
> 
> > 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 
> 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.
> 
> 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.
> 
> 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.
> 
> > To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha 
> (sanjsinh); Jonathan Rosenberg (jdrosen); [email-masked]
> > 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.
> > 
> >> To: Mohammad Al-Taraireh (maltarai); Sanjay Sinha 
> (sanjsinh); Jonathan 
> >> As a wrote before the From header is a mandatory header. 
> So there must 
> >> an identity in.
> >>
> >>> The P-Asserted-Identity is set by an trusted network 
> entity that is 
> >>> aware of the user sending that request.
> >>>
> >>> Best Regards
> >>>
> >>> Roland
> >>>
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
> >

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 16 Aug 2006 07:24:04 +0200

I'm sorry to treat you, but there is still no clarification on this issue.

Best Regards

Roland Jesske
> Von: Jesske, Roland 
> Gesendet: Dienstag, 1. August 2006 07:25
> An: 'Jonathan Rosenberg'; IETF SIP List
> Betreff: AW: [Sip] updated acr code draft
> 
> 
> So from my understanding 'id' is a subset of 'header' because 
> the P-Asserted-Identity can only be deleted by untermediarities.
> 
> Best Regards
> 
> Roland
>