Subject: RE: [Sipping] draft-watson-sipping-req-history-01

From: "Elwell, John" <[email-masked]>
Date: Fri, 28 Jun 2002 12:31:01 +0100

Dean,

I look forward with interest to the new draft from Mary, but I would like to
comment on one or two of your points. See comments in-line.

--------------------------------------------------------------
John Elwell ([email-masked])
Siemens Communications Limited,
Technology Drive, Beeston,
Nottingham NG9 1LA, UK
Tel: +44 115 943 4989   Fax: +44 115 943 4969
--------------------------------------------------------------
	Internet communications are not secure and therefore Siemens
Communications Limited does not accept legal responsibility for the
contents of this message. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Siemens
Communications Limited unless otherwise specifically stated.

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: 27 June 2002 19:29
> To: [email-masked]; [email-masked]
> Subject: Re: [Sipping] draft-watson-sipping-req-history-01
> 
> 
> 
> On Thursday 27 June 2002 06:51 am, [email-masked] wrote:
> 
> > Take the following example. When Alice calls Bob and is diverted to
> > Carol, it might be useful (depending on what you want to 
> do) to have:
> >
> > - a way to inform Alice and Carol about what't going on. I.e. that
> > the call
> >   is being diverted and why it is being diverted.
> 
> A 302 Redirect returned to Alice lets her know that the call is being 
> diverted. Even better it gives her the opportunity to decline being 
> diverted.

[JRE] The problem is that a 302 does not necessarily reach Alice's UA, since
a proxy may intercept it and route to the contact.

> 
> > - a way to inform Carol about the party that was originally called
> 
> Carol knows who was originally called by looking at the value of the 
> To: header field in the INVITE she receives.
> 
> > and the party that is diverting the call
> 
> an interesting concept that relates to the transitive 
> identity question 
> in use of REFER to effecta call transfer. Given that there 
> are a number 
> of different diversion mechanisms, there may be a number of different 
> approaches here.
> 
> In the simple proxy scenario, the divertor is identified by a Via 
> header field in the INVITE.

[JRE] The Via header identifies the proxy that carried out re-targeting. But
that is not really what the final callee needs. The callee might be
interested in the identity of the party or parties that were previously
addressed but because of re-targeting did not end up as the final
destination. Also, if re-targeting is carried out by a redirect, then this
will not be revealed by a Via header.

> 
> > - preventing this information from being presented
> 
> One must assume that any information handed to a client may be 
> presented to the user, so PSTN "Here's some info but don't show it to 
> anybody" doesn't work very well.
> 
> So how to hide it?
> 
> Bob's system proxies that call to Carol, thereby NOT sending 
> a redirect 
> to Alice (or telling her she's been diverted). If it really wants to 
> hide the transference from Carol too, then it uses B2BUA mode. If it 
> REALLY wants Carol to think the call is from Bob, it also does media 
> relay.

[JRE] Suppose Bob has arranged for his proxy to re-target his calls to
Carol. Alice tries to call Bob and gets re-targeted to Carol. Bob is happy
for Carol to know that this call was originally intended for him and is
happy to indicate a reason (e.g., busy, do not disturb, not currently
registered) to Carol. However, Bob may have reasons for not providing to
Alice any hint about the diversion of the call or the final destination. If
Carol's UA or proxy normally supplies Carol's identity towards the calling
user (e.g., asserted identity or cryptographic alternative), there needs to
be some means of suppressing it in this case.

> 
> > There are many more possibilities. These issues surfaced 
> when we were
> > trying to look at some interworking scenarios between QSIG
> > supplementary services and SIP. The lack of this sort of
> > functionality would reduce the QSIG functionality in an interworking
> > scenarion
> >
> > Not surprising, this type of notifications, is also useful in a
> > "pure" SIP environment. Which sort of brings me back to my original
> > question.
> >
> > I support that the SIPPING and SIP groups should probably make this
> > into an item to be addressed.
> 
> It's been hotly debated, and some variation on request history may be 
> reasonable. The reason that it IS hotly debated is that people with a 
> background in phone systems look at SIP and say "Hey, if we had this 
> history thing, we could replicate all these existing services 
> and make 
> them work exactly the same way with SIP."  They generally do this 
> without understanding how the Internet people building SIP 
> intended it 
> to work, how it could work without exactly replicating the phone 
> system, or WHY it should work any differently from the phone system.
> 
> It's hard to say this without sounding tacky, but "request 
> history" is 
> often proclaimed as a requirement by new-to-SIP people arriving from 
> the PSTN camp. Attempts to fend off inappropriate uses of 
> history have 
> probably obfuscated the effort of finding the real and 
> reasonable core 
> of value that I think is hiding in there somewhere.

[JRE] Diversion and other capabilities provided in QSIG came from a
consideration of user requirements. Many of those requirements are still
equally valid in an Internet environment - perhaps even more valid with
intelligent clients that can handle additional information such as call
history in meaningful ways, e.g., based on rules.

> 
> There also tend to be really hideous interactions between request 
> history mechanisms and privacy/security mechanisms, which further 
> complicates things.
> 
> --
> Dean
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP