Subject: RE: [Sipping] Comment on request history discussion

From: "Mark Watson"<[email-masked]>
Date: Tue, 19 Mar 2002 13:48:03 -0000

Eric,

There is nothing PSTN-centric about the proposal.

There is only one 'thing'/'event' which is proposed to be recorded in the
Request History information and that is retargetting of the request (i.e.
changing of the Request-URI), since it is this action which causes
information to be lost (namely the old Request-URI). I think this is a
fairly SIP-centric way of looking at the problem.

'Retargetting' can occur for very many reasons and we do not propose that we
standardise these as a fixed set - indeed this would be against the spirit
of SIP where we standardise capabilities, not end-user services.

We expect that many services can make use of the knowledge of retargeting
which has taken place without necessarily knowing *why* the retargetting
took place.

Of course, there are a number of reasons why retargeting takes place which
are well-defined and common, and I see no harm in standardising indications
for these - and we can draw on the 'Reason' draft for this.

Regards...Mark

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: 19 March 2002 01:33
> To: Sipping
> Cc: Ben Campbell
> Subject: RE: [Sipping] Comment on request history discussion
> 
> 
> [Wow!  Ben & I strongly agree on something...]
> 
> Seconding Ben's issue below, let's consider another 
> meta-issue.  *What* is
> the thing (token, header, object) that gets passed 
> downstream?  By "what", I
> don't mean the mechanics -- I mean the semantics.  The draft 
> and discussion
> envision a set of things (one of tokens, headers, objects) 
> that describe
> events like "I tried this address and it was busy", "I tried 
> this address
> and it rejected me", "I got this call because another proxy 
> tried me", etc.
> That is, a set of things like "addresses attempted", "result
> busy/noanswer/forwarded/dnd", "next step tried".
> 
> The problem is that this set of things is, by definition, 
> fixed.  Worse yet,
> it assumes a PSTN-centric approach to call processing.  Every 
> time someone
> comes up with a new way of doing call processing, we'd need another
> token/header/object.  I have visions of H.450.zzzzzz here!  
> Agents that
> understand "history" would all need to understand that new "thing" for
> meaningful processing.  I don't see a meaningful default action for
> "history".  Worse yet, if the new thing is not a linear call 
> processing
> method, e.g. "I checked the phase of the moon and Zephavra 
> sent an IM that
> inclined the plane that upset the balance that moved me to decide to
> hand-off the call to you", it is not clear how a history 
> mechanism would
> report that.
> 
> -----Original Message-----
> From: [email-masked] 
[mailto:[email-masked]]On Behalf Of
Ben Campbell
Sent: Monday, March 18, 2002 11:35 AM
To: Sipping
Subject: [Sipping] Comment on request history discussion

Apologies for not airing this in the meeting--we ran out of time on the
subject just as I was figuring out how to word my concern.

Robert and Dean (and others) pointed out the distinction between a  core
device telling a downstream device the history of a request and letting it
choose its behavior vs. the core device specifically telling the downstream
device what to do.

In a voice mail example, the core device (I will assume it is a proxy for
the rest of this note) must make the decision to forward the request to the
voice mail server in the first place. That in itself was a choice of
behavior. The history draft makes an implicit assumption that the proxy
knows that all voice mail like behavior goes to the same device, that is,
the history approach forces us into a certain service decomposition.

But what if I want to build a voice mail service where busy conditions and
no-answer conditions result in forwarding to two separate devices?

IMO, the history approach in this particular application is considerably
_more_ limiting than the approach of allowing the proxy to select the
end-point behavior through a well selected URL.

_______________________________________________
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

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 19 Mar 2002 10:26:53 -0500

Since I was the person that stood up in London to say that the "history"
thing was application-specific, I formally eat my humble pie.

The requirements proposed in draft-watson-sipping-req-history-00.txt is
EXACTLY the right thing to do.  I might offer that while the draft is an
infinite improvement on the last attempt at "history", some verbiage on how
it gets used may allay both fears and misunderstandings on what it is about.
An example, such as was offered in the presentation on proxies re-attempting
terminations that were attempted already, would go a long way.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Tuesday, March 19, 2002 8:48 AM
To: [email-masked]'; Sipping
Cc: Ben Campbell
Subject: RE: [Sipping] Comment on request history discussion

Eric,

---

From: Robert Sparks <[email-masked]>
Date: 19 Mar 2002 09:41:35 -0600

I'm curious about the motivation for that particular example
(P2 trying endpoints that P1 already tried). Why is this compelling?
Basically, the only thing I can see coming from it is trading processing
time at P2 for the network traffic of the second request to the
endpoint. That second request is going to be rejected immediately with
a 482 Merged. The UA is not going to alert and unless you have broken
networks, it will not hold up a sequential search at P2 until a timeout.

Am I missing something?

RjS

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 19 Mar 2002 10:55:55 -0500

----- Original Message -----
From: "Robert Sparks" <[email-masked]>

> networks, it will not hold up a sequential search at P2 until a timeout.
If the endpoints were tried serially or the request was not sent to P2 until
all the endpoints P1 contacted had responded. It just lengthens the call
setup time.

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 19 Mar 2002 11:00:49 -0500

Yep: the caller experience.  These messages don't happen in zero time -- the
caller is waiting.

Another example (thanks Dave) is enhanced services.  Let's say you are doing
a voice mail service.  If the caller has a caller prefs stating they would
rather go to voice mail, it would be useful for the voice mail platform to
know that the Reason it got the message was because of caller prefs, and not
because of busy/no answer/dnd.  Again, it's a caller experience thing.  The
voice mail experience can be better as it knows that the call isn't urgent,
you aren't "away from your desk", etc.

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]]
Sent: Tuesday, March 19, 2002 10:42 AM
To: [email-masked]
Cc: Mark Watson; Sipping; Ben Campbell
Subject: Small rathole (was RE: [Sipping] Comment on request
historydiscussion)

Am I missing something?

RjS

---

From: Ben Campbell <[email-masked]>
Date: Tue, 19 Mar 2002 10:05:42 -0600

Hi Eric,

Just couldn't take agreeing with me for long, could you :-)

Can you articulate what made you changed your minde on this?

---

From: Robert Sparks <[email-masked]>
Date: 19 Mar 2002 10:14:05 -0600

> Yep: the caller experience.  These messages don't happen in zero time -- the
This is squeezing out tiny delays. _IF_ P2 was a serial forking device,
it would add ~1RTT for each thing touched more than once. Carrying and
processing the history is not a zero-time operation either, so its
really +1RTT-(compute list intersection (URI comparisons happen here)).
If P2 is a parallel forker, you don't even have those RTT delays added.

Anyhow, my point is improving user experience wrt call-setup time using
this mechanism is fine tuning at best, not a place where you achieve
huge gains.

RjS

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 19 Mar 2002 13:55:57 -0500

What made me change my mind was that the whole mechanism is opaque to the
protocol.  The requirements let me have my cake (history) and eat it too
(absolutely no limits to what service I can devise or limits as to how I can
create a service).

Now the implementation of the requirements, as so far expostulated by the
reason draft, isn't perfect, but that's an e-mail in that thread...

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: Tuesday, March 19, 2002 11:06 AM
To: [email-masked]
Cc: Mark Watson; Sipping
Subject: Re: [Sipping] Comment on request history discussion

Hi Eric,