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

From: "Sean Olson (EUS)" <[email-masked]>
Date: Wed, 17 Oct 2001 11:38:28 -0500

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
>