Subject: RE: [SIP] Proposal for providing additional error information to UACs

From: Sean Olson <[email-masked]>
Date: Wed, 7 Jun 2000 18:31:39 -0500 (CDT)

> Let's suppose you do get a 3xx-style redirect. If we had a separate header,
> like Scott's proposed "Error-URL:" the UAC could *both* act on the URL,
> *and* retry the invite to the parties listed in the Contact: header.
> 
> For example, let's suppose I'm on vacation, and I set my UAS (or my local
> proxy) to reject the Invite with a 302 Moved Temporarily, with the contact
> field set to, say, my voicemail server, and the new header set a URL which
> points to an audio file that says "Sorry I'm away, you'll have to talk to my
> voicemail". The UAC could then access the message either before retrying, or
> in parallel with retrying to the voicemail.
> 
> Don't know if people find this example useful, but it might stimulate
> further discussion and hopefully consensus.
> 
> Dave.

This is a perfect example why Contact: should not be used. I personally
think a URI in the body is the best solution provided enough implementations
support multipart MIME bodies. The allows you to easily specify additional
details about the nature of the content of the URI such as language. This is
also in line with specifying additional information as a text/html body in 
a 4xx/6xx response. Consider this as analagous to the SDP payload of a 
183 Session Progress response: you are specifying additional information or an
alternate form of that information.

sean
--
Sean Olson <[email-masked]>

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Dave Oran" <[email-masked]>
Date: Thu, 8 Jun 2000 10:52:24 -0400

The body approach does seem themost flexible, but it also is the
heaviest-weight. The way I see this used it's likely to be a proxy which
inserts the information and I don't relish having to write proxy code that
tears apart and re-constructs a MIME multi-part body to add this
information.

We'd probably also need some MIME notation to indicate what the purpose of
the body part was, at least via conventions documented somewhere.

I'm on the fence on this one, like Jonathan. Any suggestions how to reach
closure?

Dave

> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
> Sent: Wednesday, June 07, 2000 7:32 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [SIP] Proposal for providing additional error information
> to UACs
>
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 10 Jun 2000 01:42:24 -0400

> I'm on the fence on this one, like Jonathan. Any suggestions how to reach

Well, one way would be to move the pros/cons from theory to something
concrete. Can anyone come up with an example where using Contact would
cause something to go wrong somewhere?

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Igor Slepchin <[email-masked]>
Date: Mon, 12 Jun 2000 13:23:51 -0400

> cause something to go wrong somewhere?

Yes: Contact already has some well-defined meaning in certain contexts,
e.g., in 300 responses or responses to REGISTER. If we were to reuse it
as a link to accessibility info, this would automatically mean that we
are disabling that info in 300 responses or responses to REGISTER. I see
no reason for this: defining a new header is no harder than overloading
the old one. It even has an added advantage: the new header doesn't have
to be defined in the base spec, which is thick enough as it is.

---
Igor Slepchin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Jun 2000 23:51:54 -0400

> to be defined in the base spec, which is thick enough as it is.

The big question is whether the current usage in 300 responses isn't
what Dave wants anyway. I see no problem in returning an RTSP URL in a
300 redirect. This 300 is forwarded up to the UAC, which can act on the
URL and fetch the streaming media content. No different than if the URL
where an HTTP URL.

One issue is if the UA wants to present the fetched data in some way
which is different because the UA knows that the data is for the
purposes of error reporting. Another issue, perhaps, is if a UA thinks
that redirects are kind of optional, and so it ignores Contact headers
in 300 class responses. These special error messages are probably more
important and should be fetched by the UA.

-Jonathan R.

---

From: "Adam B. Roach" <[email-masked]>
Date: Fri, 16 Jun 2000 03:29:24 -0500 (CDT)

>tears apart and re-constructs a MIME multi-part body to add this

You don't have to, if people implementing multipart do it correctly.
MIME multipart allows nesting (i.e. one of the parts of a MIME
multipart body can be a MIME multipart body). So all your proxy needs
to do is compose a two-part MIME multipart body; the first part is
taken from the original body (regardless of its type), and the 
second part is your URI.

But I agree that the exact purpose of a URI in the body would need
to be specified as a header of some sort.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA