On Mon, 2008-09-22 at 14:39 -0400, Gertsvolf, Mark (CAR:9D30) wrote: > Scott Lawrence wrote: > > > > If we can't rely on the ITSP to reject the call correctly in > > this case (which will surprise no one), then why not just > > have sipXbridge track as you describe and then return a > > proper 5xx code when the limit is reached? The proxy then > > does exactly the right thing already and no other > > functionality is needed anywhere. > > This is still not enough as sipXbridge does not have the intelligence to > choose the proper gateway (ITSP SIP account). When a call is routed to > sipXbridge it looks at R-URI to determine which ITSP to use and also at > CallerId to determine which ITSP SIP account to use. > If sipXbridge does internal call counting and rejects the call with > proper error code, the call comes back via dialplan fallback, but it > looks no different then the original call and there is no history > maintained to say that this is a fallback to the next gateway (ITSP SIP > account).
Not necessarily - the proxy caller-id rewriting is tied to the gateway, so each gateway can have a different caller-id for the same user. (I don't know if the UI exposes this capability, but it's there in the proxy) _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
