Subject: [Sipping] RE: [Sip] Call-Info: header

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 21 Oct 2001 18:33:31 -0400

Moved to sipping.

Well, I have already proposed that the Request-URI indicate the vxml script
to execute, since, as always, the r-uri indicates the user or service that
is being addressed. See draft-rosenberg-sip-vxml-00.txt.

THe issue of addressing an invitation to a service, passing parameters to
that service, and collecting information about how that service was
executed, is a fairly big one that requires much more discussion in any
case.

I don't see this problem as related at all to publication. Here, I am trying
to initiate a session, but the thing I am trying to communicate with is not
a person, but an automata whose behavior is parameterized in some way, and
whose parameters of operation might come from several different places
(including the caller). That seems much different than uploading some kind
of configuration data that is associated with a subscriber.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
  
-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Wednesday, October 17, 2001 12:38 PM
To: 'James Undery'; [email-masked]
Subject: RE: [Sip] Call-Info: header

How about: 
Service-Info = "Service-Info" ":" 
               (1# (addr-spec) 
               *(";" service-params)) 
service-params = "q" "=" qvalue 
               | "onerror" "=" "continue" | "halt" 
               | generic-param 
Use the q-value to order 1 or more scripts. 
Use a "Require: inline-service" to mandate support 
if needed. 
The "onerror" parameter specified what to do in the event 
of an error in processing the script. 
Thinking about this a little more, this is exactly 
the problem of PUBLISHing a CPL script, so perhaps 
it is best to wait for those requirements to firm up 
before suggesting a mechanism. 
I would like to propose the requirement that we 
be able to specify this service related information 
on a per-INVITE (or actually per-request) basis. 
An adjunct requirement would be to allow specification 
of service related information on a call leg basis. 
/sean 
>-----Original Message----- 
>From: James Undery [mailto:[email-masked]] 
>Sent: Wednesday, October 17, 2001 11:01 AM 
>To: Sean Olson (EUS); [email-masked] 
>Subject: RE: [Sip] Call-Info: header 
> 
> 
>Hi, 
> 
>My gut feeling is that it is different from SIP-CGI etc, where a 5xx 
>is appropriate. The reasons for this are, firstly Call-Info is more of 
>a hint and secondly it just feels more like 4xx rather than a server 
>failure. On reflection I'd be happier with a new header specifying the 
>script's URL and a level of importance, combined with a Require header 
>if the script is cruicial. The level of importance could indicate if 
>the request should fail if the script does or just continue 
>regardless. 
> 
>James 
> 
> 
>-----Original Message----- 
>From: Sean Olson (EUS) [mailto:[email-masked]] 
> 
>Hello, 
>The problem you mention comes from a lack of a 
>response code in SIP to express what you want. 
>In general, what has happened is that a server 
>is attempting to execute some service logic and 
>that logic is "broken". How should the server 
>respond to the request? This same problem could 
>occur for SIP-CGI, SIP servlets, SIN, etc. 
>How about a new "514 Service Failure" response code? 
>I would also be happy returning a generic 500 response 
>code in this situation. 
>Thoughts? 
>/sean 
>>-----Original Message----- 
>>From: James Undery [mailto:[email-masked]] 
>>Sent: Wednesday, October 17, 2001 10:22 AM 
>>To: Sean Olson (EUS); [email-masked] 
>>Subject: RE: [Sip] Call-Info: header 
>> 
>> 
>>Hi, 
>> 
>>The problem here is related though, the awkwardness is for the case 
>>when the Request partially succeeded, i.e. The INVITE is fine, but I 
>>didn't like the script. Do you 4xx the request and how do you 
>indicate 
>>the cause in a consistent manner (Warning headers are more aimed at 
>>presentation of errors to a user). If you just ignore failed scripts 
>I 
>>don't think you'll have the effect you desire. Unfortunately I can't 
>>think of a constructive suggestion to implement the functionality 
>>you're after in a way that'd make me happy. 
>> 
>>I meant the Call-Info parameter, but on reflection, as it's a 
>>different header I can't see what I was worried about. 
>> 
>>James 
> 

_______________________________________________
Sipping mailing list  http://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: "Sean Olson (EUS)" <[email-masked]>
Date: Mon, 22 Oct 2001 09:58:59 -0500

>is being addressed. See draft-rosenberg-sip-vxml-00.txt.

I see nothing wrong with this approach either. 

The point of using the Call-Info: header was to 
   1) Make it explicit
   2) Allow it to be optional
   3) Not require the party inserting the Call-Info: to
      understand anything more complicated than the URL
      which points to the script it wishes to be executed.
      In other words, I would not have to understand how
      the receiving party wishes to have the URL encoded
      in the Request-URI

>executed, is a fairly big one that requires much more discussion in any

Absolutely. This is not a complete solution, but a step in the
right direction (in my mind). 

>I don't see this problem as related at all to publication.

I didn't at first either. I changed my mind when I started
reading Stevens draft. The fact that the requirements are
addressing CPL upload made me equate this with generic script
uploading. VxML is just one example.

>Here, I am trying

I agree from that perspective. Do you consider CPL "configuration data"?
It encapsulates both service logic and service data. What about the
case where you are calling a person but expect an intermediate proxy
to take advantage of the script that the caller is providing?

/sean