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). Gateway CallerID feature might help, but, it only kicks in if there is no CallerId in the original call. If gateway CallerId feature could overwrite unconditionally the CallerId, then sipXbridge could know which gateway (ITSP SIP account) should be used this time around. Thanks, Mark. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
