Hi Paul,

This would require some changes in the sipxconfig to allow define ITSP
independently and a gateway could refer to them by selection.

Could you have a look and comment on it?

Thanks
Jason

> -----Original Message-----
> From: [email protected] [mailto:sipx-dev-
> [email protected]] On Behalf Of Chu, Xingjun AVAYA
(CAR:9D70)
> Sent: Thursday, February 18, 2010 2:00 PM
> To: [email protected]
> Cc: Pingtel Engineering
> Subject: [sipX-dev] A proposal regarding model of gateway <->ITSP
> account insipX
> 
> 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-interval-
> 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-interval-
> 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-interval-
> sec
> onds>
>     <sip-keepalive-method>NONE</sip-keepalive-method>
>     <rtp-keepalive-method>NONE</rtp-keepalive-method>
>   </itsp-account>
> 
> 
> Comments?
> 
> Thanks
> Jason
> 
> 
> _______________________________________________
> 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/
_______________________________________________
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/

Reply via email to