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

From: [email-masked]
Date: Thu, 27 Jun 2002 17:13:05 +0200

Having read this read this draft, I was wondering why the authors have not
produced a new version. Because, as indicated in the draft, SIP currently 
does not have certain potentially useful"notification mechanisms" (and I 
am not referring to SIP NOTIFY). 

Notifications that help the participants involved in session establishment 

to take action based on "why" a request arrived and "from where" it 
arrived,
could greatly enhance the services offered.

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 way to inform Carol about the party that was originally called and the
  party that is diverting the call
- preventing this information from being presented
- etc.

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. 

Any other views?

Regards,

Frank

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 27 Jun 2002 10:45:11 -0700

On Thursday, June 27, 2002, at 08:13 AM, [email-masked] wrote:
> Having read this draft, I was wondering why the authors have not
> produced a new version.

Hi,

In general it is best to wait until after the draft cutoff deadline to 
assume that someone isn't going to rev a draft.

thanks,
-rohan

---

From: Dean Willis <[email-masked]>
Date: Thu, 27 Jun 2002 13:28:30 -0500

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

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.

> 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP