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

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

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
>
>-----Original Message-----
>From: Sean Olson (EUS) [mailto:[email-masked]]
>Sent: 17 October 2001 15:52
>To: 'James Undery'; [email-masked]
>Subject: RE: [Sip] Call-Info: header
>
>
>
>
>>Hi,
>>
>>I for one would oppose this for use with REGISTER as it is bad enough
>>without using it to upload scripts, a separate method like PUBLISH
>>proposed by Steve Donovan is better.
>I agree entirely. I am not trying to solve the PUBLISH problem (as
>I understand it). I would expect this header really only to be
>used in the INVITE and 200 OK. (Possibly the ACK as well, but that
>would be a stretch). This is really meant to be used in the context
>of distributed application components where you are trying to
>convey a URL for a script that a component needs to perform its job.
>Make sense?
>>
>>As for the matter of sending URLs in other methods I'd prefer a
>>different syntax purely to escape the REGISTER heritage.
>A different syntax than a URL? Or a different syntax than the
>Call-Info:
>header?
>>James
>/sean
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On Behalf Of Sean
>>Olson (EUS)
>>Sent: 16 October 2001 19:18
>>To: [email-masked]'
>>Subject: [Sip] Call-Info: header
>>
>>
>>Hi,
>>I'm sure this has been discussed before. I don't
>>want to re-open a discussion if a conclusion has
>>been made. In draft-lennox-sip-reg-payload-01.txt,
>>it was proposed to extend the list of disposition-types for
>>the Content-Disposition: header to include "script".
>>I would like to make a similar proposal to extend
>>the list of "purpose" tokens for Call-Info: to include
>>script. The Call-Info: header could then contain a
>>URL to something like a vxml script which could be
>>optionally processed by the receiving party.
>>Because the current syntax allows a token for this
>>parameter, there isn't technically a need to standardize
>>this, but I was wondering if there were strong opinions
>>either way about including this in the bis draft?
>>Regards,
>>Sean Olson
>>Ericsson Inc.
>>
>

---

From: "James Undery" <[email-masked]>
Date: Wed, 17 Oct 2001 17:01:15 +0100

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

Hello,
>different header I can't see what I was worried about.

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip