Re: [Sipping] draft-watson-sipping-req-history-01

[Dean Willis <dean.willis@softarmor.com>]

On Thursday 27 June 2002 06:51 am, frank.derks@philips.com 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.

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

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

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

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 sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP