Subject: [Sipping] draft-stucker-sipping-early-media-coping

From: Cullen Jennings <[email-masked]>
Date: Fri, 3 Nov 2006 18:24:20 -0800

I have to admit there were many parts of this that left me somewhat  
lost on what the problem was or how it was solved. There were also  
some things that left me really surprised if many people use them ....

For example - you very correctly point out that the Alert-Info header  
can only be used where the source of the header is trusted - however,  
I can't imagine any case where this was true and the Alter-Info  
header was useful and suspect that mostly it was not used - or that  
at least where it was used there was huge security holes.

You talk about proxy sdp stripping being a "a very common mechanism"  
- this surprised me so I might just be misunderstanding what you are  
saying. If this is done, I don't see how early media works and if  
early media does not work I don't see how phoning things that need it  
work. I thought that every non trivial deployment did early media.

Anyways ... I don't think I would take any of these comments too  
seriously other than the meta point that I probably don't understand  
the draft and that it probably needs mmuisc and avt review more than  
sip. Also, have you looked at the application interaction framework  
stuff for doing things like inserting media announcements at the  
beginning of a call.

_______________________________________________
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: Fri, 03 Nov 2006 22:18:52 -0500

Cullen Jennings wrote:

> can only be used where the source of the header is trusted - however, I 
> can't imagine any case where this was true and the Alter-Info header was 
> useful and suspect that mostly it was not used - or that at least where 
> it was used there was huge security holes.

I have been party to discussions of a use that seems to be safe and useful:

The Alert-Info only goes between the UA and a proxy that acts on its 
behalf. The proxy strips any Alert-Info headers coming to it in the 
direction of the UA. Then the proxy may insert an Alert-Info header. The 
decision of what to insert may be based on black lists, white lists, or 
any sort of feature logic the proxy may choose to carry out.

An advantage of this is that all the data and logic for making the 
decisions can be centralized for multiple UAs. The UAs themselves only 
need to know how to handle Alert-Info.

This requires that messages only reach the UA via the proxy, but we know 
of many environments where that is the case.

	Paul

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 3 Nov 2006 23:21:31 -0600

IMHO, Alert-Info is big incentive for SPAMMERS. White listing does
suffer from the big problem of introduction. 

3261 underspecifies the Alert-Info, If it comes to Proxy responsible for
UAS in the INVITE, what it will do ? I may be missing something.

Thx
Samir
 
>-----Original Message-----
>From: Paul Kyzivat [mailto:[email-masked]] 
>Sent: Friday, November 03, 2006 7:19 PM
>To: Cullen Jennings
>Cc: sipping
>Subject: Utility of Alert-Info (was: Re: [Sipping] 
>draft-stucker-sipping-early-media-coping)
>
>
>
>Cullen Jennings wrote:
>
>> I can't imagine any case where this was true and the 
>Alter-Info header 
>> was useful and suspect that mostly it was not used - or that 
>at least 
>> where it was used there was huge security holes.
>
>The Alert-Info only goes between the UA and a proxy that acts 
>on its behalf. The proxy strips any Alert-Info headers coming 
>to it in the direction of the UA. Then the proxy may insert an 
>Alert-Info header. The decision of what to insert may be based 
>on black lists, white lists, or any sort of feature logic the 
>proxy may choose to carry out.
>
>An advantage of this is that all the data and logic for making 
>the decisions can be centralized for multiple UAs. The UAs 
>themselves only need to know how to handle Alert-Info.
>
>This requires that messages only reach the UA via the proxy, 
>but we know of many environments where that is the case.
>
>	Paul
>
>This list is for NEW development of the application of SIP Use 
>[email-masked] for questions on current sip

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 04 Nov 2006 15:31:32 -0500

> suffer from the big problem of introduction. 

Alert-Info indeed could easily be abused if its use is not carefully 
controlled. If the UAS renders anything that is included by the UAC then 
almost anything could happen.

OTOH, if the UAS knows that the usage of the Alert-Info will be policed 
by a proxy on its behalf then it can be more trusting in honoring an 
Alert-Info that reaches it.

(Another way to achieve safety would be for the UAS to only honor a 
fixed set of URIs in the Alert-Info header. Then the only thing a caller 
could do would be to choose among alternatives. This would at least be 
"safe". But of course it would be problematic for the caller to know 
what set of values are acceptable.)

> UAS in the INVITE, what it will do ? I may be missing something.

AFAIK there are no rules for this. It would be a feature/service 
provided by a proxy in the domain of the UAS to police the use of 
Alert-Info. It could do this any way that is satisfactory to the user of 
the UAS. My thought is that a good way is for it to remove any 
Alert-Info inbound from the UAC - assuming it to be untrustworthy. Then 
the proxy could generate an Alert-Info going forward to the UAS, in 
order to provide the UAS with its recommendation of a suitable alerting 
mode for this caller and call.

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 6 Nov 2006 10:37:12 -0600

Cullen.. Please see comments below, thanks for reviewing the draft.

Regards,
Brian 

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: Friday, November 03, 2006 8:24 PM
> To: sipping
> Subject: [Sipping] draft-stucker-sipping-early-media-coping
> 
> 
> I have to admit there were many parts of this that left me 
> somewhat lost on what the problem was or how it was solved. 
> There were also some things that left me really surprised if 
> many people use them ....

The draft is trying to show the ways early media is broken, the ways
that people have gotten creative to try to manage the mess, the problems
those approaches cause, and the beginnings of some discussion on how to
fix it.

The intent of the draft is to try to gather together all of the
information I could find about the issues with early media so we can
start working on ways of either fixing it or explaining why it can never
be fixed (along with recommendations to implementors as to how they
should handle the situation).

One of the worst problems with early media isn't early media. It's the
divergent ways in which various designs have tried to take advantage of
it for a particular application, or manage the chaos that is what is
most concerning to me. People "in the know" know that there are issues
with early media, but there are still people out there working on
implementations and developing standards that aren't aware of all the
implications of their decisions. Clarification alone seems useful.

> 
> For example - you very correctly point out that the 
> Alert-Info header can only be used where the source of the 
> header is trusted - however, I can't imagine any case where 
> this was true and the Alter-Info header was useful and 
> suspect that mostly it was not used - or that at least where 

It's used, and proxies aren't required to strip it, so how do endpoints
know where it came from? It just arrives. Bad news. We probably need to
put some nerf around this header to allow endpoints to figure out when
it's coming to them from a trusted source and when it comes from outer
space somewhere. If nobody was using it, then we could just deprecate it
(but I know people are using it).

> - this surprised me so I might just be misunderstanding what 
> you are saying. If this is done, I don't see how early media 
> works and if early media does not work I don't see how 
> phoning things that need it work. I thought that every non 
> trivial deployment did early media.

I've seen it done on a number of different deployed devices. You can
also think of it as the proxy "delaying" the SDP to the 200 OK rather
than letting it go through on a 18x message. For early media endpoints
that the proxy is controlling or trusts, it allows the 18x with SDP to
flow back to the originator. Further, it may let SDP answers from
terminating endpoints flow back on 18x messages to the originator if the
proxy knows that some early media it is controlling (perhaps a ringback
generator) is no longer necessary to the call. 

> 
> Anyways ... I don't think I would take any of these comments 
> too seriously other than the meta point that I probably don't 
> understand the draft and that it probably needs mmuisc and 
> avt review more than sip. Also, have you looked at the 
> application interaction framework stuff for doing things like 
> inserting media announcements at the beginning of a call.
> 

I have not looked at the application interaction framework stuff for a
number of moons. I'll have a look at it before the next revision of the
draft to see if there's more problems that it may introduce or fix to
the problem space.

> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 6 Nov 2006 10:37:14 -0600

Regards,
Brian 

It's used, and proxies aren't required to strip it, so how do endpoints
know where it came from? It just arrives. Bad [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

That's one use... Here's another:

I've seen Alert-Info used for distinctive ringing where the URL in the
Alert-Info specifies a resource local to the terminator that is known to
the server and the end client.

That probably sounds a bit crazy, so here's an example:

Let's say the terminator has previously specified that they wish to hear
ring pattern A when someone inside an enterprise calls them, and ring
pattern B when someone outside the enterprise is calling. As a result,
you might get implementations that do the following in order to prevent
managing dial-plan information on the terminator's end-device:

If the call is from within the enterprise:

Alert-Info: http://127.0.0.1/ringpattern-a.wav

If the call is from outside the enterprise:

Alert-Info: http://127.0.0.1/ringpattern-b.wav

In either case, these are sent to the terminator. Luckily, this doesn't
have an early media impact. However, in the case of colorful ringback,
where you hear something other than "ring-ring" when making a call, the
same logic above could be used in the reverse direction towards the
originator. When does the originator do what if it gets this back, plus
some early media from a gateway somewhere?

The header is in 3261. It clearly has some issues around it's operation
and interaction with other forms of early media. We should nerf it,
deprecate it, or explain under what conditions it should be used so
there's a decent chance of someone using it getting what they expected.

Regards,
Brian

> Sent: Friday, November 03, 2006 9:19 PM
> To: Cullen Jennings
> Cc: sipping
> Alert-Info header 
> > was useful and suspect that mostly it was not used - or 
> that at least 
> to it in the direction of the UA. Then the proxy may insert 
> an Alert-Info header. The decision of what to insert may be 
> based on black lists, white lists, or any sort of feature 
> logic the proxy may choose to carry out.
> 
> An advantage of this is that all the data and logic for 
> making the decisions can be centralized for multiple UAs. The 
> UAs themselves only need to know how to handle Alert-Info.
> 

Use [email-masked] for new developments of core. We probably need to

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 6 Nov 2006 10:37:14 -0600

[email-masked]
X-Mailman-Version: 2.1.5
Precedence: list

Regards,
Brian

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 06 Nov 2006 13:27:43 -0500

I think it would be far better to define a URN namespace for ringtones 
and use local configuration to map those to specific files. What you are 
proposing will only work in the most closed and homogeneous environments.

-Jonahtan R.

Brian Stucker wrote:

>>>can only be used where the source of the header is trusted 
>>
>>- however, 
>>

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Nov 2006 13:48:30 -0500

Brian,

The case you specify is almost the same case I am talking about, but 
make more specific.

I didn't say anything about what values the specific URIs should be. I 
think there are three interesting categories:
1) a URL of a remote resource that the UAS may actually retrieve
    and render

2) a URL of a resource local to the UAS.

3) a URN, that simply specifies a name of a particular alerting style.
    The UAS must know what to do for one of these to use it, or have its
    own way of discovering that given the URN.

I have seen (2) used, but usually as an alternative for (3) in that it 
isn't really expected that the UAS will necessarily have something 
stored in exactly this way. I find (2) to be unreasonable in most 
deployments, and (3) to be a much more reasonable approach, that has 
equivalent functionality.

This is all orthogonal to how trustworthiness of Alert-Info headers is 
managed. I find it difficult to imagine any cases when the UAS would 
want to honor a value sent by the UAC.

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 6 Nov 2006 17:39:03 -0600

I'm not proposing using it. 

I'm giving it as an example of how it's already being used.

Regards,

Brian 

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Monday, November 06, 2006 10:28 AM
> To: Stucker, Brian (RICH1:AR00)
> Cc: Paul Kyzivat; Cullen Jennings; sipping
> Subject: Re: Utility of Alert-Info (was: Re: [Sipping] 
> I think it would be far better to define a URN namespace for 
> ringtones and use local configuration to map those to 
> specific files. What you are proposing will only work in the 
> most closed and homogeneous environments.
> 
> -Jonahtan R.
> 
> Brian Stucker wrote:
> 
> > Alert-Info specifies a resource local to the terminator 
> that is known 
> > to the server and the end client.
> > 
> > Let's say the terminator has previously specified that they wish to 
> > hear ring pattern A when someone inside an enterprise calls 
> them, and 
> > ring pattern B when someone outside the enterprise is calling. As a 
> > result, you might get implementations that do the following 
> in order 
> > to prevent managing dial-plan information on the 
> terminator's end-device:
> > 
> > In either case, these are sent to the terminator. Luckily, this 
> > doesn't have an early media impact. However, in the case of 
> colorful 
> > ringback, where you hear something other than "ring-ring" 
> when making 
> > a call, the same logic above could be used in the reverse direction 
> > towards the originator. When does the originator do what if it gets 
> > this back, plus some early media from a gateway somewhere?
> > 
> > The header is in 3261. It clearly has some issues around it's 
> > operation and interaction with other forms of early media. 
> We should 
> > nerf it, deprecate it, or explain under what conditions it 
> should be 
> > used so there's a decent chance of someone using it getting 
> what they expected.
> > 
> > Regards,
> > Brian
> > 
> > 
> > 
> >>direction of the UA. Then the proxy may insert an 
> Alert-Info header. 
> >>The decision of what to insert may be based on black lists, white 
> >>lists, or any sort of feature logic the proxy may choose to 
> carry out.
> >>
> >>This requires that messages only reach the UA via the proxy, but we 
> >>know of many environments where that is the case.
> >>
> >>	Paul
> >>
> >>[email-masked] for questions on current sip Use 
> >>[email-masked] for new developments of core SIP
> >>
> > 
> > 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> > 
> 
> --

---

From: "Darshan Bildikar" <[email-masked]>
Date: Thu, 9 Nov 2006 17:27:50 +0530

Section 4.1 

"Any SDP answers in provisional responses are stripped before being
forwarded upstream.  The SDP answer may be added into a 200 response
upstream from last provisional SDP answer received if SDP is not already
present in the message to ensure that the offer/answer exchange is
completed.  This effectively turns off early media"

I am not sure whether such an approach would turn off early media. 3264
clearly says that the terminating UA can start sending RTP immediately after
the receipt of the offer. Hence even if you don't send the answer SDP to the
upstream entity there is a good chance media will still be rendered even if
SDP is stripped away. (In fact, we have actually faced this problem). The
solution is to INVITE the callee always with a HOLD / NO SDP and renegotiate
always after answer.

---

From: Dean Willis <[email-masked]>
Date: Thu, 9 Nov 2006 12:11:12 -0600

On Nov 6, 2006, at 12:27 PM, Jonathan Rosenberg wrote:

> ringtones and use local configuration to map those to specific  
> files. What you are proposing will only work in the most closed and  
> homogeneous environments.
>

Absolutely. I think this is a GREAT idea.

--
Dean

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 9 Nov 2006 13:29:46 -0600

I would also agree.

I wasn't proposing anything earlier, just stating an observed behavior
(ala SIPit reports). I can make a recommendation in the early media
draft though around this area.

Regards,
Brian 

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Thursday, November 09, 2006 10:11 AM
> To: Jonathan Rosenberg
> Cc: Stucker, Brian (RICH1:AR00); Cullen Jennings; Paul 
> Kyzivat; sipping
> > and use local configuration to map those to specific files. 
> What you 
> > are proposing will only work in the most closed and homogeneous 
> > environments.
> >
>

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 9 Nov 2006 13:32:08 -0600

True, that's another problem though. Some devices won't render early
media without an SDP answer though (they simply ignore everything until
they get something on the signaling path).

I don't think you want to pull the HOLD on INVITE trick though, because
it aggravates the general clipping problem.

Regards,
Brian

> From: Darshan Bildikar [mailto:[email-masked]] 
> Sent: Thursday, November 09, 2006 3:58 AM
> To: 'sipping'
> Subject: [Sipping] A comment on 
> draft-stucker-sipping-early-media-coping
> 
> Section 4.1 
> 
> "Any SDP answers in provisional responses are stripped before 
> being forwarded upstream.  The SDP answer may be added into a 
> 200 response upstream from last provisional SDP answer 
> received if SDP is not already present in the message to 
> ensure that the offer/answer exchange is completed.  This 
> effectively turns off early media"
> 
> I am not sure whether such an approach would turn off early 
> media. 3264 clearly says that the terminating UA can start 
> sending RTP immediately after the receipt of the offer. Hence 
> even if you don't send the answer SDP to the upstream entity 
> there is a good chance media will still be rendered even if 
> SDP is stripped away. (In fact, we have actually faced this 
> problem). The solution is to INVITE the callee always with a 
> HOLD / NO SDP and renegotiate always after answer. 
> 
> 
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 9 Nov 2006 13:18:01 -0800

I'm unclear how this could work, unless we define some global  
registry of ring tones, which seems utterly impractical.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Nov 2006 17:51:29 -0500

There could be a registry of ring tones, reflected in a URN. Or several 
different ones.

Of course this is only useful if there is knowledge by the entity 
inserting the Alert-Info of the URNs supported by the UAS. In general it 
is probably impractical to expect that callers will know which ones 
their callee will accept.

As as have said a few times now, I find this much more practical if it 
is used between a server acting for the UAS and the UAS. In such an 
environment, it becomes practical for the server to be informed of the 
URNs that the UAS will support. So this allows the server to apply all 
sorts of interesting algorithms to incoming requests to decide what sort 
of ring tone would be appropriate, and then insert an Alert-Info for the 
UAS. In that way you can have a ring tone algorithm that works 
consistently across all your phones without having to configure each one 
to do it.

	Paul

Henning Schulzrinne wrote:
> I'm unclear how this could work, unless we define some global registry 
> of ring tones, which seems utterly impractical.
>

---

From: Dean Willis <[email-masked]>
Date: Thu, 9 Nov 2006 17:52:04 -0600

> registry of ring tones, which seems utterly impractical.

I would think a global registry of national-standard ring tones would  
be reasonably practical. I generally wouldn't care all that much is  
somebody wanted me to hear a French ring-back when I call them. What  
I don't really want is to go download (esp. at time of use) the  
latest Britney Spears MP3 just so I can hear it play while I'm  
waiting on my niece to answer the phone.

--
Dean

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 9 Nov 2006 17:53:50 -0600

AMEN. 

> Sent: Thursday, November 09, 2006 3:52 PM
> To: Henning Schulzrinne
> Cc: Stucker, Brian (RICH1:AR00); sipping

---

From: [email-masked]
Date: Thu, 9 Nov 2006 20:08:33 -0500

> homogeneous environments.

I don't think a URN namespace would be particularly useful because the
only use case is vanity customizations -- there is no set of
conceptual ringtones that has meaning over a broad swathe of users.
So Alert-Info URIs are going to be either URLs that are only locally
significant (http://127.0.0.1/spears1.wav) or nearly arbitrary URNs
that are only locally significant (urn:oid:1.3.6.1.4.1.14490.4.1).

Dale

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 9 Nov 2006 19:34:55 -0800

If you want a list of the tones - you might check out the draft I did  
a long time ago ...

http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-bryan-sipping- 
midi.html

If you think that it would be a good idea that when I phone country  
X, I get a tone that I can recognize as busy or ringing , well I  
agree with you but all research of what users wants and what  
companies want to build seems to disagree with you.

On Nov 9, 2006, at 10:11 AM, Dean Willis wrote:

>> files. What you are proposing will only work in the most closed  
>> and homogeneous environments.
>>
>

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Fri, 10 Nov 2006 07:35:40 +0100

If this discussion will lead to an enhanced definition of alerting, please
then remember to include not only that the tone characteristics should be
configurable, but also the mode of alerting.

-Audible  - Ring tones etc according to current discussion.
-Visual   - Flashing lights, flashing screen.
-Tactile  - Pocket vibration, watch vibration, handset vibration.

In many cases the selection can be made from preferences in a user profile,
while in other cases it is the environment that influences what mode to use.
( e.g. flashing light in very noisy industry area )

Gunnar

---

From: "Steve Langstaff" <[email-masked]>
Date: Fri, 10 Nov 2006 07:59:25 -0800

> Sent: 09 November 2006 23:52
> To: Henning Schulzrinne
> Cc: sipping; Brian Stucker
> Subject: Re: Utility of Alert-Info (was:Re: [Sipping] 

Sorry if this is a silly question, but is the discussion here about the
Alert-Info header in an INVITE or elsewhere (i.e. is it the called party
or calling party that gets to hear Britney Spears being rendered)?

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 9 Nov 2006 16:15:29 -0600

I think we're getting off-track here.

Let me reboot this thread...

There was a comment made on the list about nobody using Alert-Info. Paul
K. brought up a use and I brought up a use that we've both seen as a
counter-point to show that people do actually use Alert-Info.

In the usage that I have seen the problem that the Alert-Info was being
used to solve was to denote a network/client coordinated alerting
pattern. The network knew about what the client supported, and had
previously coordinated a set of values to tell the terminating client to
use alert pattern X versus alert pattern Y.

The recommendation proposed is that in these cases the Alert-Info use a
separate namespace in cases where the proxy inserting the Alert-Info is
colluding with the UAS that will receive it in order to render an alert
tone that is stored on the UAS.

Regards,
Brian

> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Thursday, November 09, 2006 1:18 PM

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Nov 2006 12:55:41 -0500

There are two usages of Alert-Info that are being conflated in comments 
here:
- in a request, where it influences the alerting / ring tones
- in a response, where it influences the ringback.

Most of the discussions apply to both, but lets keep in mind that they 
are different. Certainly the use cases are different. (When I call 
France I might expect to hear a French ringback, but the callee probably 
doesn't expect to get an American ring tone.)

A key thing about Alert-Info is that it is advisory. There is no 
obligation for the recipient to honor it.

So one possible usage would be for UASs to include an Alert-Info in 
responses to suggest a ringback. By default it could be either omitted, 
or set to a country-specific ringback URN. Potentially the UAS could be 
customized to include some arbitrary URI, such as a reference to the 
latest Britney song. When it gets to the UAC, it can play it or not. One 
possibility is to play it if it is a URN that is known to the UAC and 
otherwise ignore. That would solve Dean's problem.

An alternative policy is for the a proxy in the network to do call 
screening for the UA. It can remove all incoming Alert-Info values, or 
it might allow them from some sources, or it might allow certain values 
and refuse others. It also might insert Alert-Info values itself based 
on some policy. In this case the UA could be configured to attempt to 
honor any incoming Alert-Info that arrives via the screening proxy.

	Paul

Cullen Jennings wrote:
> 
> If you want a list of the tones - you might check out the draft I did a 
> long time ago ...
> 
> http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-bryan-sipping-midi.html 
> 
> 
> If you think that it would be a good idea that when I phone country X, I 
> get a tone that I can recognize as busy or ringing , well I agree with 
> you but all research of what users wants and what companies want to 
> build seems to disagree with you.
> 
> 
>>> ringtones and use local configuration to map those to specific files. 
>>> What you are proposing will only work in the most closed and

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Nov 2006 13:39:59 -0500

The thing referenced by an Alert-Info can have any kind of alerting 
behavior. For instance, it ultimately could be a multipart mime body 
with audio, video, and other kinds of material. Then the UA can choose 
which of these to render.

If URNs are used, then each UA can have its own mapping from the URN to 
the actual alerting mechanism. That provides a mechanism to have a 
generic set of alerts that are expected to be distinguishable from one 
another, while still accommodating the environmental, etc. needs of 
individual users.

	Paul

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 11 Nov 2006 14:34:32 -0600

Thus spake "Paul Kyzivat" <[email-masked]>
> which of these to render.

That's clever...

> If URNs are used, then each UA can have its own mapping from the
> URN to the actual alerting mechanism. That provides a mechanism to
> have a generic set of alerts that are expected to be distinguishable
> from one another, while still accommodating the environmental, etc.
> needs of individual users.

This is already done to an extent today, though not with URNs.  There 
are a number of vendors that send us something like:

Alert-Info: http://127.0.0.1/Bellcore-dr2

Exactly what we do with that is up to the receiver; in our case, the 
user is allowed to decide what "Distinctive Ring #2" sounds/looks like.

In fact, this has been the standard mechanism we've been seeing for 
several years.  It's only recently that some folks have started sending 
us real URIs (SP-controlled custom ringtones); the problem with that is 
being sure the UA is capable of playing the media format referenced. 
What if you send a URI for an WMA file to a UA that's only capable of 
playing MP3 or WAV files?  Multipart might help solve that as well.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 11 Nov 2006 14:58:50 -0600

Thus spake "Dean Willis" <[email-masked]>
> somebody wanted me to hear a French ring-back when I call them.

URNs for standard national ringback/ringtone would be nice, and it'd get 
rid of the need for a lot of early media streams, since that what most 
of them are today.

> What I don't really want is to go download (esp. at time of use) the 

Unfortunately, there appear to be a large number of consumers willing to 
pay to force you to listen to Britney when you call them.  It's "cool", 
and a big source of revenue for the SP.  More recently, I'm running into 
businesses that have their ringback set to play Muzak or advertisements. 
Grrr.

Yes, you could try to block that by ignoring Alert-Info headers, but for 
now those CRBTs are coming in via early media, not Alert-Info.  To stop 
them, you'd have to ignore all early media, which is not viable since 
there are a large number of 1-800 IVR systems that require acceptance of 
early media to function correctly -- users won't consider not being able 
to call their bank or airline to be a viable trade-off for blocking 
annoying-but-harmless CRBTs.

S

---

From: "Darshan Bildikar" <[email-masked]>
Date: Mon, 13 Nov 2006 11:01:26 +0530

My understanding was that RBT's are always generated by downstream entities
(in case of PSTN interop by the terminating gateways) and busy tones are
generated by local proxies. (Like in PSTN where the terminating switch
generates the RBT and the local switch generates the busy tone)

If we were to generate local RBT based on a URN namespace what would happen
if an RBT is also getting generated from the remote end? Are we supposed to
ignore it? If yes, then it would go against RFC 3264 that states that the UA
must be prepared to start receiving RTP immediately after sending an offer.
There is then the likelihood of two RBT's being played to the caller
simultaneously. 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Saturday, November 11, 2006 12:10 AM
To: Gunnar Hellstrom
Cc: Cullen Jennings; Brian Stucker; sipping; Dean Willis
Subject: Re: SV: Utility of Alert-Info(was:Re: [Sipping]

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Nov 2006 11:45:19 -0500

> Alert-Info: http://127.0.0.1/Bellcore-dr2

This is "poor man's URN", without any real standardization of meaning.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Nov 2006 11:48:29 -0500

> There is then the likelihood of two RBT's being played to the caller

IMO, the Alert-Info merely overrides the default alerting / ringback 
mechanism used by the device. In the case of ringback, that will 
typically only be used when there has been a 180 response *and* there is 
no in-band ringback. Just as in-band ringback preempts the default local 
ringback, it should probably also preempt the locally generated ringback 
based on Alert-Info.

YMMV.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Nov 2006 21:51:18 -0500

inline.

> want to honor a value sent by the UAC.

Well, here is where URN helps. Since the UA that has to render the URN 
has to know what it means, you can authorize it or not based on that 
understanding.

As others have pointed out, the URN is not going to help cases where 
people want Britney Spears songs as ringback, but it can help with 
country-specific ringbacks, where we could easily create a registry.

I've become convinced that custom ringtones are best done the way they 
are done today. The ringtone is stored on the called party device, and 
logic on the phone itself selects which one to use based on the identity 
of the caller. Having the caller select content that gets rendered at 
the called party, without asking the called party for authorization 
(which is the case for ringtones), is a recipe for absolute disaster. 
I'm not worried about tasteless music - I'm worried about some malicious 
user that decides to record some highly offensive content and then start 
calling random numbers to cause the content to get played out 
automatically. Big mistake.

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Nov 2006 13:47:47 -0500

I mostly agree with Jonathan. One slight difference inline.

	Paul

Jonathan Rosenberg wrote:
> of the caller.

I think the above is a perfectly reasonable mechanism, well suited to 
reasonably smart devices with UIs and capabilities for the necessary 
configuration, and when it makes sense to manage each device independently.

I also see value in a case where some of this logic is offloaded from 
the device to a server acting on its behalf. The server makes a decision 
about which alert as appropriate for each call, while the device does 
the rendering of that alert. This is potentially useful for devices that 
are limited in their capabilities in general and their UI in particular. 
  It also could be helpful when there are multiple devices and the same 
alert selection logic is desired for them all.

> Having the caller select content that gets rendered at 

Yes, I agree. At most, I can see a UA (or a proxy acting on behalf of 
the UA) accepting a small selection of Alert-Info values that it 
considers benign. Other values should be ignored.

If a UA knows it has a proxy acting on its behalf in screen Alert-Info, 
and perhaps inserting values based on policy carried out by the proxy, 
then the UA may be willing to trust any value it receives via that 
proxy, and render any Alert-Info value it is capable of rendering.

	Paul

---

From: David Robbins <[email-masked]>
Date: Thu, 16 Nov 2006 17:27:10 -0500

Several items in this thread have touched on the idea of defining URNs 
to represent a "well known" set of alerting patterns (e.g., national 
standard sets such as the "Bellcore" patterns in the US). While that is 
useful only in limited contexts and circumstances, as noted by many in 
this discussion, it is sufficiently useful that it would, in my 
opinion, be worth doing. In work I'm currently involved in, we are 
encountering two different sets of URLs that (as Paul noted) are used 
as a "poor man's URN," and may see more variations in the future. An 
actual URN namespace with identifiers defined for each of the standard 
alerting patterns would be preferable, to simplify interoperability.

Are we at a point where we can propose such a URN namespace? Pick a 
namespace ID (perhaps "alert" or "std-alert"). The NSS wouldn't have to 
be anything more complicated than a name, though it could have two 
components, the first indicating the jurisdiction within which the 
standard pattern is defined (e.g., a country, or administration) and 
the second indicating the specific pattern. Wouldn't want to make it 
more complex than necessary, but sufficiently flexible to be used not 
just in North America.

On Nov 16, 2006, at 1:47 PM, Paul Kyzivat wrote:

>>> I didn't say anything about what values the specific URIs should be. 
>>> I think there are three interesting categories:
>>> I have seen (2) used, but usually as an alternative for (3) in that 
>>> it isn't really expected that the UAS will necessarily have 
>>> something stored in exactly this way. I find (2) to be unreasonable 
>>> in most deployments, and (3) to be a much more reasonable approach, 
>>> that has equivalent functionality.
>>>
>>> This is all orthogonal to how trustworthiness of Alert-Info headers 
>>> is managed. I find it difficult to imagine any cases when the UAS 
>>> would want to honor a value sent by the UAC.
>> Well, here is where URN helps. Since the UA that has to render the 
>> URN has to know what it means, you can authorize it or not based on 
>> that understanding.
>> I've become convinced that custom ringtones are best done the way 
>> they are done today. The ringtone is stored on the called party 
>> device, and logic on the phone itself selects which one to use based 
>> on the identity of the caller.
>
> the device to a server acting on its behalf. The server makes a 
> decision about which alert as appropriate for each call, while the 
> device does the rendering of that alert. This is potentially useful 
> for devices that are limited in their capabilities in general and 
> their UI in particular.  It also could be helpful when there are 
> multiple devices and the same alert selection logic is desired for 
> them all.
>
>> Having the caller select content that gets rendered at the called 
>> party, without asking the called party for authorization (which is 
>> the case for ringtones), is a recipe for absolute disaster. I'm not 
>> worried about tasteless music - I'm worried about some malicious user 
>> that decides to record some highly offensive content and then start 
> If a UA knows it has a proxy acting on its behalf in screen 
> Alert-Info, and perhaps inserting values based on policy carried out 
> by the proxy, then the UA may be willing to trust any value it 
> receives via that proxy, and render any Alert-Info value it is capable 
> of rendering.
>
> 	Paul
>
>> -Jonathan R.
>

Dave Robbins
Verizon Laboratories
40 Sylvan Rd.
Waltham, MA 02451-1128

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Nov 2006 18:44:42 -0500

David Robbins wrote:
> this discussion, it is sufficiently useful that it would, in my opinion, 
> be worth doing. In work I'm currently involved in, we are encountering 
> two different sets of URLs that (as Paul noted) are used as a "poor 
> man's URN," and may see more variations in the future. An actual URN 
> namespace with identifiers defined for each of the standard alerting 
> patterns would be preferable, to simplify interoperability.
> 
> standard pattern is defined (e.g., a country, or administration) and the 
> second indicating the specific pattern. Wouldn't want to make it more 
> complex than necessary, but sufficiently flexible to be used not just in 
> North America.

It seems that there are still multiple opinions about the value in this, 
but it may be time to propose something.

A part of the job as yet untouched is nailing down precisely what one of 
these URNs names. If it is always a sound, then it might be better to 
establish a URN specifically for sounds, songs, music clips, and the 
like. (urn:sounds:Beethovens-fifth-intro, 
urn:sounds:who-let-the-dogs-out, urn:sounds:bellcore-dr1)

Alternatively these URNs might just denote a logical alerting concept 
that could be rendered in various ways - sound, visual, tactile, some 
combination of these, etc. (urn:alerts:called-party-alerting, 
urn:alerts:normal-call, urn:alerts:alt-line-call, 
urn:alerts:known-caller, urn:alerts:unknown-caller)

There could be different URN types for each kind, or the different kinds 
could be accommodated in a single URN based on what registration info is 
provided for a name.

	Paul

---

From: [email-masked]
Date: Thu, 16 Nov 2006 21:37:35 -0500

From: David Robbins <[email-masked]>

   Are we at a point where we can propose such a URN namespace? Pick a 
   namespace ID (perhaps "alert" or "std-alert"). 

"sip"

Dale