Subject: AW: [Sipping-tispan] Requirements 02e

From: "Jesske, R" <[email-masked]>
Date: Wed, 21 Sep 2005 12:58:20 +0200

Rocky,
REQ-TIP1: It should be the identity which the connected user want to sent back to the originating user.

REQ-TIP2: For this identity the same security mechanism as for the from header field shall apply.

Roland  

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Rocky Wang
> Gesendet: Mittwoch, 21. September 2005 09:29
> An: 'Miguel Garcia'
> Cc: [email-masked]
> Betreff: RE: [Sipping-tispan] Requirements 02e
> 
> 
> Hi, Miguel,
> 
>    For REQ-TIP-1, I agree with you and it is the same of ours. But
> previously I misunderstand it that the direct communication means it
> should reach to the same terminal.
> 
>    But for REQ-TIP-3, maybe there are still some security problem.
> Suppose user B set and his terminal returns a subscriber C's 
> URI back to
> the calling party A, then what will happen? It will be 
> possible that the
> user A will be misleaded to make a call to C but he wants to 
> make one to
> user B actually.
> 
> Best Regards,
> Rocky Wang
> 
> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]] 
> Sent: 2005?9?21? 14:37
> To: Rocky Wang
> Cc: [email-masked]
> Subject: Re: [Sipping-tispan] Requirements 02e
> 
> 
> Hi Rocky:
> 
> inline discussion.
> 
> Rocky Wang wrote:
> 
> >    But I have some more doubts on TIP:
> >    REQ-TIP-1: In addition to any network asserted identity, 
> it must be
> >               possible for the callee to indicate in a SIP 
> response an
> >               additional identity where he is reachable for future
> >               direct communications.
> >    Does it mean the back identifier must be something like 
> gruu? The 
> > one who answers the call from one endpoint does not always mean the 
> > caller should make a call to this endpoint directly later.
> 
> As far as I understand, there is not a requirement for this to be a 
> GRUU. This is just another URI that would lead to the same 
> person, but 
> not necessarily to the same terminal.
> 
> > 
> >    REQ-TIP-3: The identity mentioned in REQ-TIP-1 is 
> considered an end
> >               user supplied information that is not asserted by the
> >               network.
> >    Does it mean the network equipments just transfer the called 
> > party's identifier provided by the called party endpoint? 
> It must be 
> > also asserted, I think. Or, it will cause some security problem.
> 
> It means that the network does not verify the validity of 
> this URI. It 
> is up to the user to put something meaningful there. This is the 
> requirement.
> 
> BR,
> 
>         Miguel
> 
> > 
> > Regards,
> > Rocky Wang
> >    
> > 
> > -----Original Message-----
> > From: Miguel Garcia [mailto:[email-masked]]
> > Sent: 2005?9?20? 14:46
> > To: Rocky Wang
> > Cc: [email-masked]
> > Subject: Re: [Sipping-tispan] Requirements 02e
> > 
> > 
> > Hi Rocky:
> > 
> > Yes, I think we agreed that this is a missing requirement, 
> but we want
> > to write it down when we have finished the other 
> requirements, because
> 
> > it may happen that the calling part categories requirements 
> help us in
> 
> > creating a proper dependency.
> > 
> > So this is not forgotten, it will be added at a later time.
> > 
> > BR,
> > 
> >       Miguel
> > 
> > Rocky Wang wrote:
> > 
> > 
> >>Hi, Migues,
> >>As I considered, the requirement of overrding ACR service must be
> >>there as a formal requirement. Maybe there are some ways that the 
> >>called AS to get enough information to determine that it 
> can or cannot
> > 
> > 
> >>override the ACR, but there are some cases the simulation 
> service must
> > 
> > 
> >>be overrided, including the case you listed in the 02a 
> version. It can
> > 
> > 
> >>be like this: 1. The originating network shall be able to 
> take enough
> >>calling party's information to the terminating network to help to 
> >>override the callee's ACR service. 2. The terminating 
> network shall be
> > 
> > 
> >>able to override the callee's ACR simulation service if the 
> caller is
> >>authorized to do this based on the caller's information.
> >>
> >>Rocky Wang
> >>
> >>
> >>
> >>-----Original Message-----
> >>From: [email-masked]
> >>[mailto:[email-masked]] On Behalf Of Miguel Garcia
> >>Sent: 2005?9?9? 20:57
> >>To: [email-masked]'
> >>Subject: [Sipping-tispan] Requirements 02e
> >>
> >>
> >>Hi:
> >>
> >>I have another working copy of the TISPAN requirements, now version
> >>02e:
> >>
> >>http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipp
ing-tispan
>>-r
>>equirements-02e.html
>>
> 
> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan
> -r
> 
>>equirements-02e.txt
>>
>>And a diff version with respect 02d:
>>http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan
>>-r
>>equirements-02d-to-e.html
>>
>>The main changes this time are:
>>
>>- Rewording of the CCBS/CCNR requirements as per our discussion. I
>>have
>>added a few definitions and try to reorder them sequentially, so that 
>>they are a bit easier to understand.
>>- Clarification that the TIP requirements are for an additional (to
> 
> the
> 
>>asserted) identity.
>>- Addition of the Communication Waiting requirements
>>
>>Please feel free to comment, but bear in mind that due to the TISPAN 
>>meeting next week most of the TISPANers will have limited time to 
>>discuss.
>>
>>/Miguel
>>
> 
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

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

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

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 21 Sep 2005 12:58:19 +0200

Dear Rocky,
We discussed ACR override very long and extensively. We realised that ACR override is not longer a requirement.
Thanks

Roland

> Gesendet: Montag, 19. September 2005 05:37
> An: 'Miguel Garcia'; [email-masked]
> As I considered, the requirement of overrding ACR service 
> must be there
> as a formal requirement. Maybe there are some ways that the 
> called AS to
> get enough information to determine that it can or cannot override the
> ACR, but there are some cases the simulation service must be 
> overrided,
> including the case you listed in the 02a version. It can be like this:
> 1. The originating network shall be able to take enough 
> calling party's
> information to the terminating network to help to override 
> the callee's
> ACR service.
> 2. The terminating network shall be able to override the callee's ACR
> simulation service if the caller is authorized to do this based on the
> caller's information.
> 
> Rocky Wang
> 
> 
> 
> I have another working copy of the TISPAN requirements, now 
> version 02e:
> 
> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sippin
g-tispan-r
equirements-02e.html
http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-r
equirements-02e.txt

And a diff version with respect 02d:
http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-r
equirements-02d-to-e.html

- Rewording of the CCBS/CCNR requirements as per our discussion. I have 
added a few definitions and try to reorder them sequentially, so that 
they are a bit easier to understand.
- Clarification that the TIP requirements are for an additional (to the 
asserted) identity.
- Addition of the Communication Waiting requirements

/Miguel

---

From: "Bemmel, Jeroen van (Jeroen)" <[email-masked]>
Date: Fri, 23 Sep 2005 12:33:32 +0200

> So we want the have the same within SIP. In forward direction 
> we have the From header and the P-Asserted-Identity. But in 
> Backward direction the equivalent to the From header is missing.
> 
> So we need such an identity header for the backward direction 
> setup from the callee.
> 
> Roland

What if the callee would simply add a parameter to the To header? Something like
To: <sip:[email-masked]>;tag=25425741;identity=[email-masked]

Jeroen

---

From: "Bemmel, Jeroen van (Jeroen)" <[email-masked]>
Date: Fri, 23 Sep 2005 13:12:17 +0200

Roland,

In case of diverted communication, the To header retains its original value. 

In any case, (in my mind at least) a callee accepting a call would add this information (header or parameter) to the 2xx response (e.g. to INVITE), so the caller would get information provided by the UA that is answering, not always the one that he originally called. 

If this was not intended, then perhaps this is something to clarify in the requirements. But whether a header or a parameter would be used, I don't think there's a difference w.r.t. the issue you mention

Regards,

Jeroen

> From: Jesske, R [mailto:[email-masked]]
> Sent: Friday, September 23, 2005 12:50 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: AW: [Sipping-tispan] Requirements 02e
> 
> 
> In principle I have nothing against such an approach.
> But what is in the case of diverting the communication.
> So that the to header is different from the 
> P-Asserted-Identity and the identity in the to header belongs 
> not to the user where the communication was sent to originally?
> 
> Roland
> 
> > Von: Bemmel, Jeroen van (Jeroen) [mailto:[email-masked]] 
> > Gesendet: Freitag, 23. September 2005 12:34
> > An: Jesske, Roland; [email-masked]; [email-masked]
> > To: 
> > <sip:[email-masked]>;tag=25425741;identity=[email-masked]
> > 
> > Jeroen
> > 
>

---

From: "Bemmel, Jeroen van (Jeroen)" <[email-masked]>
Date: Fri, 23 Sep 2005 13:17:27 +0200

A similar issue: What happens in case of call transfer? Would the other end receive updated additional identity information?

JvB

> From: Bemmel, Jeroen van (Jeroen) 
> Sent: Friday, September 23, 2005 1:12 PM
> To: 'Jesske, R'; Bemmel, Jeroen van (Jeroen); [email-masked];
> [email-masked]
> Subject: RE: [Sipping-tispan] Requirements 02e
> 
> 
> Roland,
> 
> In any case, (in my mind at least) a callee accepting a call 
> would add this information (header or parameter) to the 2xx 
> response (e.g. to INVITE), so the caller would get 
> information provided by the UA that is answering, not always 
> the one that he originally called. 
> 
> If this was not intended, then perhaps this is something to 
> clarify in the requirements. But whether a header or a 
> parameter would be used, I don't think there's a difference 
> w.r.t. the issue you mention
> 
> Regards,
> 
> Jeroen
> 
>

---

From: "Jesske, R" <[email-masked]>
Date: Fri, 23 Sep 2005 13:43:27 +0200

Jeroen,
Now with the words of Miguel referring to RFC3261 I think this is not possible.
Good try.

Roland
> Gesendet: Freitag, 23. September 2005 13:12
> An: Jesske, Roland; Bemmel, Jeroen van (Jeroen); 
> [email-masked]; [email-masked]

---

From: "Jesske, R" <[email-masked]>
Date: Fri, 23 Sep 2005 13:50:53 +0200

Jeroen,
The Connected Number here P-Asserted-Identity in the Response of the connected UA and the additional connected identity must be from the user that is reached. And not that what was dialled. That was why this feature was defined within the PSTN/ISDN.

Roland 

> Gesendet: Freitag, 23. September 2005 13:17
> An: Jesske, Roland; [email-masked]'; [email-masked]'
> Cc: [email-masked]'
> A similar issue: What happens in case of call transfer? Would 
> the other end receive updated additional identity information?
> 
> JvB
>