Subject: [Sipping] Question about Alert-Info

From: "Gerald Yan" <[email-masked]>
Date: Mon, 16 Jul 2007 16:03:00 +0800

Hi:
I found some SIP terminals use the header Alert-Info to implement
distinctive ring service or indicate call waiting tone. But the alerting
files are local ones in the terminals, and the Alert-Info format is like
this: Alert-Info: < http://127.0.0.1/1.wav>. This implantation is so
private.
My question: is there a common way provided for Proxy/Registrar to
retrieve the alert file location and name? 

Best regards
Gerald

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Jul 2007 08:05:10 -0400

AFAIK there has been no effort within the ietf to standardize the use of 
  URLs with Alert-Info. I have not heard of the specific style of usage 
you mention. But I have heard of using <file:foo> to reference "local" 
files.

The reference of local files is of course problematic without some sort 
of agreement about what files will be available locally. The current 
state of the art seems to be localize agreements and/or configuration 
for what sorts of kinds and values of URIs will be accepted.

IMO the right thing to do is to standardize a bunch of URNs that 
represent common tones.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 16 Jul 2007 12:27:23 -0500

On Jul 16, 2007, at 7:05 AM, Paul Kyzivat wrote:

> AFAIK there has been no effort within the ietf to standardize the  
> use of  URLs with Alert-Info. I have not heard of the specific  
> style of usage you mention. But I have heard of using <file:foo> to  
> reference "local" files.
>
> The reference of local files is of course problematic without some  
> sort of agreement about what files will be available locally. The  
> current state of the art seems to be localize agreements and/or  
> configuration for what sorts of kinds and values of URIs will be  
> accepted.
>

I'd be ticked to see a draft advance that establishes and populates a  
registry of URNs for common tones, actually. I believe I saw somebody  
make a start on one a few years back that never went anywhere. This  
would probably make a reasonable master's non-theses project, if  
there's a student out there looking to tackle it. Or a good kickoff  
project for anybody looking to get deeper into IETF work.

--
Dean

---

From: Ted Hardie <[email-masked]>
Date: Mon, 16 Jul 2007 10:37:08 -0700

At 8:05 AM -0400 7/16/07, Paul Kyzivat wrote:
>AFAIK there has been no effort within the ietf to standardize the use of  URLs with Alert-Info. I have not heard of the specific style of usage you mention. But I have heard of using <file:foo> to reference "local" files.
>

The "file" URL scheme was specified in RFC 1738, along with a number
of the other initial URL schemes.  The specification is pretty bare bones,
though, and when the URI community tried to clean up 1738, file
turned out to be pretty hard.  There are many different implementations
that have subtly different (or sometimes, wildly different) interpretations
of some of the more unusual choices.  Trying to decide what to do with
that pretty much ran out of steam before  a very good choice emerged.
Paul Hoffman was the last to attempt it, and he or Larry Masinter would
be good choices if you need to follow-up.
			regards,

					Ted

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Jul 2007 14:06:53 -0400

In this case the problem with file: isn't with the specification of the 
scheme. Rather it is the way it is typically used, assuming that certain 
files and directory structures are present on the UA receiving the 
Alert-Info. (I guess the legal way to reference files on the recipient 
is <file:///foo.bar>, and maybe that is what I actually saw in use - I 
don't recall.)

Absent some standard convention about what kinds of 
alert-containing-files must be present this usage only works when 
certain environmental assumptions are made.

That problem could be eliminated by including a node name in the file: 
url. But that doesn't seem to be what is usually desired. Instead, the 
goal is to reference "well known" tones, without forcing a remote retrieval.

For "well known" tones a urn is a better fit.

	Thanks,
	Paul

---

From: Ted Hardie <[email-masked]>
Date: Mon, 16 Jul 2007 11:45:54 -0700

At 2:06 PM -0400 7/16/07, Paul Kyzivat wrote:
>In this case the problem with file: isn't with the specification of the scheme. Rather it is the way it is typically used, assuming that certain files and directory structures are present on the UA receiving the Alert-Info. (I guess the legal way to reference files on the recipient is <file:///foo.bar>, and maybe that is what I actually saw in use - I don't recall.)

File permits you to have a host; one of the examples in RFC 1738 is

<URL:file://vms.host.edu/disk$user/my/notes/note12345.txt>

localhost or the empty string are also permitted, and they mean
"the machine from which this URL is being interpreted".    The
problems we've run into with file run around that point--is it interpreted
from the point in the filesystem where the URL is being interpreted
or from some "root" of the directory structure?  That is, if I have
an html page with file://localhost/my.txt in it, does that mean
at the root of the file system, or in the local directory?  How about
if I say  file://localhost/./my.txt?  what does file://localhost/../my.txt
end up meaning?  Reading RFC 1738, I personally think the answers
are clear, but the actual implementations differ enough that I think
the results are never certain.

>Absent some standard convention about what kinds of alert-containing-files must be present this usage only works when certain environmental assumptions are made.

To put this a little more clearly, I suppose, I think the URI communities'
experience is that the presence of a standard convention doesn't end
up helping here. 

>That problem could be eliminated by including a node name in the file: url. But that doesn't seem to be what is usually desired. Instead, the goal is to reference "well known" tones, without forcing a remote retrieval.
>

I agree that URN seems like a better fit for a well-known value. 

				regards,
					Ted

---

From: Dean Willis <[email-masked]>
Date: Mon, 16 Jul 2007 17:54:54 -0500

On Jul 16, 2007, at 12:27 PM, Dean Willis wrote:

>> style of usage you mention. But I have heard of using <file:foo>  
>> to reference "local" files.
>>
> I'd be ticked to see a draft advance that establishes and populates  
> a registry of URNs for common tones, actually. I believe I saw  
> somebody make a start on one a few years back that never went  
> anywhere. This would probably make a reasonable master's non-theses  
> project, if there's a student out there looking to tackle it. Or a  
> good kickoff project for anybody looking to get deeper into IETF work.
>

I mean "tickled" (as in "made very happy"), not ticked! (Thanks, all  
the folks who teased me about this . . .)

I wonder what kind of Freudian slip that was? Gotta ask my  
therapist ;-).

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Jul 2007 23:05:27 -0400

Your therapist will be ticked.

	Paul

Dean Willis wrote:
>>> AFAIK there has been no effort within the ietf to standardize the use 
>>> of  URLs with Alert-Info. I have not heard of the specific style of 
>>> usage you mention. But I have heard of using <file:foo> to reference 
>>> "local" files.
>>>
> I mean "tickled" (as in "made very happy"), not ticked! (Thanks, all the 
> folks who teased me about this . . .)
> 
> I wonder what kind of Freudian slip that was? Gotta ask my therapist ;-).
> 
> -- 
> Dean
>