AW: [Sipping-tispan] requirements -02f

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

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