> On Thu, Feb 18, 2010 at 2:21 PM, Robert Joly <[email protected]> wrote: > > Jason wrote: > > > >> Hi > >> > >> Just had discussion this morning with Scott and Ranga > regarding the > >> fix for XX-4785 - sipXProxy not applying caller-id correctly for > >> wildcard > >> (non-user-specific) caller-id setting. > >> > >> I had a fix which Scott and Ranga think based on > Wrong-designed data > >> model of gateway-itsp which has been there for a long > time, we should > >> not proceed with the fix but to get the model corrected > and then fix > >> it based on the new model. > >> > >> Here is what we found about CURRENT data model of > gateway-itsp which > >> is thought to be wrong. > >> > >> Currently for each gateway created in sipXconfig, an ITSP > account is > >> required to be provisioned. > >> > >> The corresponding gateway record is stored in DB table > "gateway" and > >> it associated ITSP account is stored in DB (in table > settings-value) > >> , and the gateway record is associated with the ITSP > account info via > >> some kind of magic ID > >> (storage-id) in the table (like a foreign key). > >> > >> The problem is now if multiple gateways are created which > appears to > >> refer to the same account (This is legitimate scenario, why users > >> want to do that, please see xx-4785) , the same account > info needs to > >> be typed multiple times and then duplicated and stored in > the DB as > >> they are irrelevant. > >> > >> Same scenario happens to sipxbridge.xml (a duplication file of all > >> ITSP accounts), the same account is duplicated in sipXbridge.xml > >> multiple times, basically the component who generates the > >> sipXbridge.xml in sipXconfig loops through all the > gateways and put > >> its associated ITSP account into sipXbridge.xml and it > does care if > >> it's same or not. > >> > >> Below is an example of sipxbridge.xml (for simplicity, only itsp > >> account part is shown) , two gateways are created in sipXconfig. > >> > >> The same ITSP account is generated into sipXbridge.xml twice. > >> > >> <itsp-account> > >> <itsp-proxy-domain>scstrial.ca</itsp-proxy-domain> > >> <user-name>2260</user-name> > >> <password>xxxxxx</password> > >> <register-on-initialization>true</register-on-initialization> > >> <itsp-proxy-address>scstrial.ca</itsp-proxy-address> > >> <itsp-proxy-listening-port>0</itsp-proxy-listening-port> > >> <itsp-transport>UDP</itsp-transport> > >> <use-global-addressing>true</use-global-addressing> > >> <strip-private-headers>false</strip-private-headers> > >> <default-asserted-identity>true</default-asserted-identity> > >> <is-user-phone>true</is-user-phone> > >> <loose-route-invite>true</loose-route-invite> > >> <registration-interval>600</registration-interval> > >> > >> <sip-session-timer-interval-seconds>1800</sip-session-timer-in > > terval-sec > >> onds> > >> <sip-keepalive-method>NONE</sip-keepalive-method> > >> <rtp-keepalive-method>NONE</rtp-keepalive-method> > >> </itsp-account> > >> > >> <itsp-account> > >> <itsp-proxy-domain>scstrial.ca</itsp-proxy-domain> > >> <user-name>2260</user-name> > >> <password>xxxxx</password> > >> <register-on-initialization>true</register-on-initialization> > >> <itsp-proxy-address>scstrial.ca</itsp-proxy-address> > >> <itsp-proxy-listening-port>0</itsp-proxy-listening-port> > >> <itsp-transport>UDP</itsp-transport> > >> <use-global-addressing>true</use-global-addressing> > >> <strip-private-headers>false</strip-private-headers> > >> <default-asserted-identity>true</default-asserted-identity> > >> <is-user-phone>true</is-user-phone> > >> <loose-route-invite>true</loose-route-invite> > >> <registration-interval>600</registration-interval> > >> > >> <sip-session-timer-interval-seconds>1800</sip-session-timer-in > > terval-sec > >> onds> > >> <sip-keepalive-method>NONE</sip-keepalive-method> > >> <rtp-keepalive-method>NONE</rtp-keepalive-method> > >> </itsp-account> > >> > >> > >> The problems with this model/the way it 's been done right now > >> > >> 1) Information duplication (Same account stored many times) > >> 2) also some gateway related info is dumped into sipxbridge.xml > >> 3) Scott and Ranga can add more disadvantages here ... > >> > >> The right model should be > >> > >> >From UI > >> - Do not create ITSP account for each gateway, An ITSP > account object > >> should be created independently. > >> - And a gateway can refer to (from UI to choose) ITSP account > >> >From DB > >> - There should be explicitly data model (table) to > describe the ITSP > >> account > >> - gateway record is associated with ITSP object via > foreign key or > >> whatever it is. > >> > >> >From SipXbridge, > >> When sipXbridge.xml is generated, for each ITSP account, > there should > >> be > >> > >> - a field for each gateway who refer to this account > (corresponding > >> gaway id is store there). > >> > >> For example, > >> > >> <itsp-account> > >> <itsp-proxy-domain>scstrial.ca</itsp-proxy-domain> > >> <user-name>2260</user-name> > >> <password>xxxxxx</password> > >> <gateway>a<gateway> > >> <gateway>b<gateway> > >> .... > >> <gateway>n<gateway> > >> <register-on-initialization>true</register-on-initialization> > >> <itsp-proxy-address>scstrial.ca</itsp-proxy-address> > >> <itsp-proxy-listening-port>0</itsp-proxy-listening-port> > >> <itsp-transport>UDP</itsp-transport> > >> <use-global-addressing>true</use-global-addressing> > >> <strip-private-headers>false</strip-private-headers> > >> <default-asserted-identity>true</default-asserted-identity> > >> <is-user-phone>true</is-user-phone> > >> <loose-route-invite>true</loose-route-invite> > >> <registration-interval>600</registration-interval> > >> > >> <sip-session-timer-interval-seconds>1800</sip-session-timer-in > > terval-sec > >> onds> > >> <sip-keepalive-method>NONE</sip-keepalive-method> > >> <rtp-keepalive-method>NONE</rtp-keepalive-method> > >> </itsp-account> > >> > >> > >> Comments? > > > > Can you elaborate on how this solves the caller-id issue > which is what > > XX-4785 is about? > > > > Well, the actual problem was that ITSP accounts could not be > disambiguated based upon Request URI domain alone and after > some discussion the issue morphed into assigning a line ID > per gateway to be associated with the ITSP account. > > The issue title should probably be changed.
...and change the description and comments too because what I read has much to do with caller-ids. Let me ask my question another way. Would the new proposal as described above address the caller-id "portion" of the tracker? _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
