Subject: [Sipping] Comment on request history discussion

From: "Ben Campbell" <[email-masked]>
Date: Mon, 18 Mar 2002 10:34:40 -0600

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

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 18 Mar 2002 20:33:27 -0500

[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