On Wed, 2009-04-29 at 12:56 -0400, Paul Mossman wrote: > Hi all, > > Alert-Info headers are used by both the Page and Intercom features to > trigger certain phone types to auto-answer INVITEs. In the case of > Polycoms, the phone must be pre-configured with the an Alert-Info string > for the feature. > > It seems there may be a good reason to keep this string secret, since it > can be used to cause phones to auto-answer a call. You don't want > hackers to be able to do this. Though, hopefully sipXproxy rejects (or > amends) unauthorized INVITEs that contain an Alert-Info header... > > I ask because the Page and Intercom Alert-Info strings are treated > inconsistently in this respect. > > The Page Alert-Info string is hard-coded to "sipXpage". Also, the > Polycom profile generation is hard-coded with configuration to > auto-answer at this Alert-Info string. It's always there, regardless of > whether any page groups are defined or not. > > The Intercom Alert-Info string on the other hand is a randomly generated > string, such as "A0mJkSQI". Furthermore it is only put into generated > profiles when the Polycom is a member of a phone group for which > Intercom is enabled. If you enable the Intercom feature, then you need > to push the Polycom profiles for it to take effect. (sipXconfig tells > you about the services that need to be restarted, but not about the > phone profiles that need to be re-generated.) > > It seems like if there's no need to keep the strings secret, then > Intercom should use a hard-coded one so that phone configuration doesn't > need to be updated. But if the strings should be kept secret then I > don't see the point in hiding one but not the other. > > Is there a reason for the Page and Intercom Alert-Info strings to be > handled so differently? Thanks.
No, but there's also no point in attempting to keep 'secret' anything that's sent over the wire in cleartext. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
