AW: [Sipping-tispan] requirements -02f

["Jesske, R" <[e-mail]>]

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

> -----Ursprüngliche Nachricht-----
> Von: [e-mail] [mailto:[e-mail]] 
> Gesendet: Freitag, 23. September 2005 16:41
> An: Jesske, Roland; [e-mail]; [e-mail]
> Cc: [e-mail]; 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?
> 
> 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