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

From: "Mary Barnes"<[email-masked]>
Date: Tue, 19 Mar 2002 00:27:16 -0600

Eric and Ben,

I've embedded some comments below [MB] in response to this email thread in
an effort to extract specific concrete feedback from this thread.  

Regards,
Mary H. Barnes
[email-masked]
ESN 444-5432
Wireless 817-703-4806

-----Original Message-----
From: Eric Burger [mailto:[email-masked]]
Sent: Monday, March 18, 2002 7:33 PM
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. 
[MB] I would think that the above set of things is only "fixed" or limited
by what can happen to the call in a SIP enabled network.

Worse yet,it assumes a PSTN-centric approach to call processing. 
[MB] I don't understand why this approach is viewed to be PSTN-centric.
Indeed, our goal is to NOT to embed application/service specific knowledge
or control (other than what's required to fill in the information we'd like
to track) in the network. 

Every time someone
comes up with a new way of doing call processing, we'd need another
token/header/object.  
[MB] I don't agree with this and I don't think you can make that statement
until you see the potential solutions that are proposed.  Indeed, our
objective is to provide a generic capability that would enabled a broad
range of applications. 

I have visions of H.450.zzzzzz here!  Agents that
understand "history" would all need to understand that new "thing" for
meaningful processing.  
[MB] I don't believe we talking about adding any additional information or
"things" that don't already exist in SIP.  We just believe that there is a
need for a mechanism to carry some of these "existing" things somewhere else
so that an application can use these to provide an enhanced service. 

I don't see a meaningful default action for
"history".  
[MB] I don't know that we're envisioning a meaningful default action for
"history".  Are you referring to a minimum subset that might be useful or a
minimal behavior that is necessary to make this information useful?  I'm not
sure that this can be answered until we explore the solution options further
and apply potential solutions to some of the scenarios. 

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.
[MB] We're not talking about keeping the history of non SIP instantiated
history.  The objective is to base the history on information that SIP
already has, thus since you can't check the phase of the moon with SIP, we
don't plan on trying to support that.  As well, handoff should be fairly
transparent to the SIP layer in general.  

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

[MB] Then, you MIGHT not need the history at those specific separate
devices. It would be the point at which it's known that they're going to
whatever flavor of voicemail server you're talking about that would parse
this information and send it to the appropriate voicemail server. Here,
you're talking about putting explicit knowledge about how your voicemail
devices work in the core device.  Our objective was to limit the knowledge
in the core device as to how the voicemail server works, but rather to send
the pieces of information that are useful to the server and allow it to
parse and attach meaning to the information. 

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.

[MB] It's a design decision, certainly.  But managing and selecting the
appropriate well selected URL requires the core device and the voicemail
server to agree on the meanings of these URLs.  

[MB] As I said during the presentation, specific examples may very well be
solved by other approaches, however, our view was that they still fit into
the fundamental problem could also be solved by this more generic request
history capability.  

_______________________________________________
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: Ben Campbell <[email-masked]>
Date: Tue, 19 Mar 2002 10:02:29 -0600

Mary Barnes wrote:
> whatever flavor of voicemail server you're talking about that would 
> parse this information and send it to the appropriate voicemail server. 
> Here, you're talking about putting explicit knowledge about how your 
> voicemail devices work in the core device.  Our objective was to limit 
> the knowledge in the core device as to how the voicemail server works, 
> but rather to send the pieces of information that are useful to the 
> server and allow it to parse and attach meaning to the information.

But the history approach requires the voice mail system to know how the 
network works. Now, in reality, both of those potitions are a bit 
extreme. The RFC 3087 approach does _not_ require the network to 
understand how voice mail works. All it does is require the network to 
forward requests to predetermined URIs that are exposed by the voice 
mail system.

I certainly hope that if I bye SIP routing services from a service 
provider, they give me the ability to bye voice mail from a separate 
provider. I also hope they do not give me a single place to enter the 
address of my voice mail server, but rather ask me "What should we do 
with a busy condition? What about a no answer condition." They don't 
even _know_ its a voice mail system--it could be an announcement server 
that says "Ben is busy, call back later."

> server to agree on the meanings of these URLs. 

Not really, it doesn't. See above.

> 
> [MB] As I said during the presentation, specific examples may very well 
> be solved by other approaches, however, our view was that they still fit 
> into the fundamental problem could also be solved by this more generic 
> request history capability. 

It seems to me that the history capability is less, rather than more 
generic, at least compared to RFC 3087. Can you show a specific example 
that cannot be solved without history? (My apologies if you have already 
done this in an old draft or email. I seem to recall a specific example 
in the past but I can't seem to find it.)