[Asterisk-Dev] Distinctive ringing

[John Todd]

>On Fri, 2003-06-20 at 14:20, John Todd wrote:
>>  >On Fri, 2003-06-20 at 11:15, Jayson Vantuyl wrote:
>>  >>  On Tue, Jun 17, 2003 at 12:03:49PM -0700, John Todd wrote:
>>  >>  > There is a pending patch that Mark has been given (by "km-", whose
>>  >>  > real name I don't recall) that will add this "distinctive ring"
>>  >>  > feature to Asterisk, by setting a variable before sending a call to a
>>  >>  > SIP outbound channel via Dial.
>>  >>  Is there a similar way to signal a distinictive ring with Zaptel?
>>  >
>>  >I've off and on thought about this, and the comments about how no known
>>  >phone right now is RFC compliant. The comments have said that there are
>>  >a couple of different ways of signaling the different rings.
>>  >
>>  >This brings me to the idea that could potentially bring the dial command
>>  >back to something usable just like the zapata way. Could you not make
>>  >ring definitions on a per sip user basis and reference them with a
>>  >number just like the way we do with zapata? Maybe in a homogeneous SIP
>>  >device environment you could define the distinctive rings in the general
>>  >section, but in a heterogeneous environment the ability to set the rings
>>  >local to the user/phone would eliminate the problem of the RFC says to
>>  >provide a URL, but cisco says an integer is enough.
>>  >
>>  >I'll admit I don't have enough knowledge of how SIP works to do any more
>>  >than suggest this to those who may make the changes.
>>  >--
>>  >Steven Critchfield  <critch at basesys.com>
>>
>>  [prior responses to this have already addressed the basic question of
>>  how to get Zaptel devices to use distinctive ringing]
>>
>>  Steve -
>>     Using a numeric is still not compliant to the spirit of the
>>  Alert-Info: header information.  The problem is that SIP phones may
>>  not be sitting on your LAN, using your ringers, or even owned by you,
>>  and it's more likely that remote SIP phones aren't even "known" by
>>  Asterisk until the moment they are dialed - this rules out a prior
>>  mapping of a numeric to a particular ringtype.  Including a
>>  fully-qualified URL in the Alert-Info: header is the only way to
>>  ensure that the soundfile that you specify will be possibly be
>>  accessed by the remote phone.
>
>Don't expect many vendors to implement a url to a wav file as a ring
>tone without some form of distinct limitations available. I can just see
>the new form of spamming porn by doing a port scan for SIP phones then
>making the ring tone some advertisement for a 1900 number or website.
>Hell for that matter unless you are doing some other form of call
>filtering, your telemarketers would just move the spiel to the ring
>tone.
>I would only expect a ring tone url to accepted from a proxy your trust
>and had some say in configuration. Also I doubt the idea was for a
>caller to determine the ring tone.

That authentication is outside the RFC, and will probably exist in a 
phone-specific config of some type.  "Trusted-Networks" or some 
similar method would be used to allow or disallow certain hosts from 
requesting alternate ringers, or simply allowing or disallowing 
certain hosts to be accessed for the ringers (the web server, that 
is.)  I leave this as an exercise to the phone vendors.

>  >    Of course, there is no "MUST" in the usage for Alert-Info: so it
>  > starts to become dependent on each vendor as to how they implement
>  > distinctive ringing.  Using a numeric might suffice and be compatible
>>  with the Zap channel syntax, but I would suspect that this will not
>>  be a viable solution when vendors start to implement the ringtypes.
>>
>>  Side note: Remember when all cellphones had one ringer?  As the
>>  technology of cellphone call delivery became "commonplace", the focus
>>  of vendors moved away from basic functionality into the shiny, stupid
>>  features like playing "1812 Overture" with the ring alert.  SIP isn't
>>  to the point where the basic functionality is completely nailed down,
>>  but within the next year expect to see the "bells and whistles"
>  > features start to become more developed as vendors shift their dev
>>  teams away from core functionality (which will be completed.)
>>  Putting the feature hooks in correctly _now_ will save a lot of
>>  headache if we can guide the vendors into building features to match
>>  the hooks in a scaleable way.
>
>This is why I say to define them in your sip.conf file with a reference
>number, then reference them in the dial string.
>
>kind of like this
>-------sip.conf-----
>[ciscouser]
>ringtone1 => 1
>ringtone2 => 2
>ringtone3 => 3
>defaultringtone => 1
>
>[rfccompliant]
>ringtone1 => http://www.ringtones-r-us.com/train.wav
>ringtone2 => http://www.ringtones-r-us.com/race-engine.wav
>ringtone3 => http://www.pornsite.com/cum-meet-me.wav
>defaultringtone => 1
>
>
>------extension.conf---------
>exten => 1,1,dial(Sip/ciscouser)
>exten => 2,1,dial(Sip/ciscouser|r2)
>exten => 3,1,dial(Sip/rfccompliant|r3)
>
>--
>Steven Critchfield  <critch at basesys.com>

Sure, that would work as a stopgap.

To counter that, however, I also like the previously described trick 
where the phone ringer could dynamically be used as a pager feature. 
Hopefully the future will find RFC-compliant SIP extensions for 
paging and intercom (if they don't exist already) but using the 
ringer as a pager might almost work in some instances.  Statically 
defining ringtones in a config file prevents that from being done 
cleanly.

Not everything can conform to a Zap channel syntax, so I don't think 
it's wise to try to shoehorn everything to that model.  Some channels 
have more features than Zap, and in different ways, so it's going to 
be more complex in the future when dealing with channel-specific 
tricks.  This is a perfect example: in the desire to make things look 
more like a Zap channel, your example hides features from the 
dialplan programmer.  This may be a minor issue for this feature, but 
it's a mindset that is dangerous to develop.

I just don't think using enumerated lists to represent flexible 
variables is a good idea when it forces the dialplan author to use 
the enumerated values and _prevents_ them from representing the value 
as a dynamic string.  Locking functionality away from the 
administrator is never a good idea if it's just as easy to let them 
have it.  See my often-posted gripes on error code handling within 
Asterisk for a description of why I dislike "features" like 
auto-jump-on-busy which prevent me from correctly handling calls 
because of "man behind the curtain" functions.

JT