Subject: AW: [Sipping-tispan] requirements -02f

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

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Paul Kyzivat
> Gesendet: Freitag, 23. September 2005 05:00
> An: Miguel Garcia
> Cc: [email-masked]'; Alexeitsev, Denis
> Betreff: Re: [Sipping-tispan] requirements -02f
> 
> 
> 
> 
> Miguel Garcia wrote:
> > Hi:
> > 
> > I have added one more requirement, CDIV, to our draft.
> 
> >    REQ-CDIV-1: It must be possible that the caller is 
> informed that a
> >                communication is being diverted.
> 
> I can't understand what this is requiring. The fact that it must be 
> possible to inform the caller does not say that the caller 
> will in fact 
> be informed. Is the decision about whether the caller is 
> informed to be 
> made by the caller or the callee, or somebody else?

[RJ] "he "must" of the requirement is due to the fact that we need a mechanism in SIP for that. If the caller or callee gets this information is due to network/operator/Service provider policy

> 
> >    REQ-CDIV-2: It must be possible for the diverting user 
> to express his
> >                privacy requirements with respect his identity.
> 
> Again, just because the user expressed requirements does not 
> endure they 
> will be honored. What is the real requirement?
> 
> >    REQ-CDIV-3: The reason of the redirection must be 
> available to both
> >                the caller and callee.
> 
> Is there a clear distinction between a redirection and a simple 
> forwarding? Is there a list of the possible reasons? What if 
> none of the 
> possible reasons is applicable? What if the reason for 
> forwarding is not 
> known?

[JE] There is a draft draft-elwell-sipping-redirection-reason-02 describing this reasons and also there are discussions between a interested group of people preparing a draft regarding redirection/retargeting/diversion/forwarding ... The following reasons are discussed at the moment.

+------------------------------------------------------------------+
| Retargeting reason value               | ISUP/Q.931 redirect     |
|                                        | reason codes            |
|----------------------------------------+-------------------------|
| no-contacts - service retargeting      | Unknown / not available |
| because there are no registered        |                         |
| contacts for the URI;                  |                         |
|----------------------------------------+-------------------------|
| busy - service retargeting because     | User busy               |
| contacts for the URI are busy;         |                         |
|----------------------------------------+-------------------------|
| no-reply - service retargeting         | No reply                |
| because the request was not answered   |                         |
| during the alerting period;            |                         |
|----------------------------------------+-------------------------|
| unconditional - service retargeting    | Unconditional           |
| because the user has arranged for      |                         |
| requests to be retargeted irrespective |                         |
| of the state of registered contacts;   |                         |
|----------------------------------------+-------------------------|
| declined - service retargeting because | Deflection during       |
| the user declined the request during   | alerting                |
| alerting;                              |                         |
|----------------------------------------+-------------------------|
| distribution - service retargeting     | Deflection immediate    |
| because the user has arranged for      | response                |
| requests to be distributed among a     |                         |
| number of targets;                     |                         |
|----------------------------------------+-------------------------|
| network - service retargeting because  | Network congestion      |
| of network conditions.                 |                         |
+----------------------------------------+-------------------------+
> 
> >    REQ-CDIV-4: The history of the communication must be available to
> >                both the caller and callee.
> 
> Are you talking about History-Info? "history of the 
> communication" could 
> mean many things, including a complete log of all the media that were 
> exchanged.

[JE] Yes it is the History-Info. But I think we should express it in an other way, because  not each service provider will show the history of the call to the end-user. So I think we should change the text. 
Proposal:
It must be possible that caller and callee will be informed about the identity of the caller, diverting parties and the Callee if available.

I tried to exclude the word history. Because the History info can also have information not relating to diversion information.

Roland

> 
> 	Paul
> 
> P.S. It is getting increasingly frustrating to figure out why we must 
> include a buggy whip holder in the design for our new car, 
> and what the 
> car must do when whipped in various ways.
> 
> _______________________________________________
> 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: Fri, 23 Sep 2005 09:23:43 +0200

With privacy is meant what RFC3323 can be used for.
So it is meant that the user can express his privacy status and that a URI marked as "anonymous" will not be shown to the regarding parties.

Roland

> [mailto:[email-masked]] Im Auftrag von Tessa Silvia
> Gesendet: Donnerstag, 22. September 2005 21:32
> An: Miguel Garcia; [email-masked]
> Cc: Alexeitsev, Denis
> Betreff: [Sipping-tispan] [CDIV]requirements -02f
> 
> 
> Hi,
> REQ-CDIV-2 is not totally clear to me, it states:
>   It must be possible for the diverting user to express his
> What do we mean by expressing his privacy ? Does he need an 
> option to anonymse all the redirection history of all users 
> involved or does he need to anonymise his position only or both ?
> 
> Thanks
> Silvia
> 
> > -----Messaggio originale-----
> > Da: [email-masked] [mailto:sipping-tispan-
> > [email-masked]] Per conto di Miguel Garcia
> > Inviato: giovedì 22 settembre 2005 12.48
> > A: [email-masked]'
> > Cc: Alexeitsev, D
> > Oggetto: [Sipping-tispan] requirements -02f
> > 
> > Hi:
> > 
> > Version 02f is available at:
> > 
> > 
> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sippin
> g-tispan-
> > requirements-02f.html
> > 
> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sippin
> g-tispan-
> > requirements-02f.txt
> > 
> > and diff version with respect -02e:
> > 
> > 
> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sippin
g-tispan-
> requirements-02e-to-f.html
> 
> Besides CDIV, after some discussions during the last TISPAN meeting, we
> brought back a CCBS/CCNR requirement to know the status of the caller
> (now REQ-CCBS/CCNR-4). This is required to be able to resume a suspended
> CCBS/CCNR request.
> 
> I INVITE you to send comments.
> 
> BR,
> 
>        Miguel
> 
> --
> Miguel A. Garcia           tel:+358-50-4804586
> sip:[email-masked]
> Nokia Research Center      Helsinki, Finland
> 
> 

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================

---

From: [email-masked]
Date: Fri, 23 Sep 2005 10:41:07 -0400

Roland,

These requirements seem to contradict each other.  One says A and C must know what B did.  Other says B can ask that A and C not know that he diverted.  Is there also a precedence to these requirements?

Also, it may also be useful to distinguish between:
1) retargeting from one terminal to another terminal of the same person,
2) diversion by a person to another person's terminal (or set of terminals).

Are the requirements intended to cover both cases, with or without any distinction?

Mike

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jesske, R
> Sent: Friday, September 23, 2005 3:24 AM
> To: Paul Kyzivat [[email-masked]]; [email-masked]
> Cc: [email-masked]; Alexeitsev, D
> Subject: AW: [Sipping-tispan] requirements -02f
> 
> 
> 
> > possible to inform the caller does not say that the caller will in 
> > fact be informed. Is the decision about whether the caller 
> is informed 
> > to be made by the caller or the callee, or somebody else?
> 
> 
> [RJ] "he "must" of the requirement is due to the fact that we 
> need a mechanism in SIP for that. If the caller or callee 
> gets this information is due to network/operator/Service 
> provider policy
> 
> 
> 
> > 
> > Again, just because the user expressed requirements does not endure 
> > they will be honored. What is the real requirement?
> > 
> > forwarding? Is there a list of the possible reasons? What 
> if none of 
> > the possible reasons is applicable? What if the reason for 
> forwarding 
> > is not known?
> 
> [JE] There is a draft 
> draft-elwell-sipping-redirection-reason-02 describing this 
> reasons and also there are discussions between a interested 
> group of people preparing a draft regarding 
> redirection/retargeting/diversion/forwarding ... The 
> following reasons are discussed at the moment.
> 
> 
> > Are you talking about History-Info? "history of the communication" 
> > could mean many things, including a complete log of all the 
> media that 
> > were exchanged.
> 
> [JE] Yes it is the History-Info. But I think we should 
> express it in an other way, because  not each service 
> provider will show the history of the call to the end-user. 
> So I think we should change the text. 
> Proposal:
> It must be possible that caller and callee will be informed 
> about the identity of the caller, diverting parties and the 
> Callee if available.
> 
> I tried to exclude the word history. Because the History info 
> can also have information not relating to diversion information.
> 
> Roland
> 
> > 
> > 	Paul
> > 
> > include a buggy whip holder in the design for our new car, and what 
> > the car must do when whipped in various ways.
> >

---

From: "Jesske, R" <[email-masked]>
Date: Thu, 29 Sep 2005 06:18:53 +0200

Mike,
There shall be the possibility that A and B is informed that the communication is diverted.
The rest is network option if this possibility will be used.

Roland

> Von: [email-masked] [mailto:[email-masked]] 
> Gesendet: Freitag, 23. September 2005 16:41
> An: Jesske, Roland; [email-masked]; [email-masked]
> Cc: [email-masked]; Alexeitsev, Denis
> Betreff: RE: [Sipping-tispan] requirements -02f
> 
> 
> Roland,
> 
> These requirements seem to contradict each other.  One says A 
> and C must know what B did.  Other says B can ask that A and 
> C not know that he diverted.  Is there also a precedence to 
> these requirements?
> 
> communication"