RE: [Sipping-tispan] requirements -02f

[[e-mail]]

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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Jesske, R
> Sent: Friday, September 23, 2005 3:24 AM
> To: Paul Kyzivat [[e-mail]]; [e-mail]
> Cc: [e-mail]; Alexeitsev, D
> Subject: AW: [Sipping-tispan] requirements -02f
> 
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: [e-mail]
> > [mailto:[e-mail]] Im Auftrag von Paul Kyzivat
> > Gesendet: Freitag, 23. September 2005 05:00
> > An: Miguel Garcia
> > Cc: '[e-mail]'.org'; 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/sipping-tispan
> > 
> 
> _______________________________________________
> Sipping-tispan mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 

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