RE: SV: Utility of Alert-Info(was:Re:[Sipping]draft-stucker-sipping-early-media-coping)

["Darshan Bildikar" <[e-mail]>]

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:[e-mail]] 
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]
draft-stucker-sipping-early-media-coping)

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

Gunnar Hellstrom wrote:
> 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
> 
> -----Ursprungligt meddelande-----
> Fran: Cullen Jennings [mailto:[e-mail]]
> Skickat: den 10 november 2006 04:35
> Till: Dean Willis
> Kopia: Paul Kyzivat; sipping; Brian Stucker
> Amne: Re: Utility of Alert-Info (was:Re: [Sipping]
> draft-stucker-sipping-early-media-coping)
> 
> 
> 
> 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:
> 
>> On Nov 6, 2006, at 12:27 PM, Jonathan Rosenberg wrote:
>>
>>> 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.
>>>
>> Absolutely. I think this is a GREAT idea.
>>
>> --
>> Dean
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP