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. Ranga > _______________________________________________ > 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/ > -- M. Ranganathan _______________________________________________ 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/
