Mark Gertsvolf wrote: > > If the gateway CallerId feature overwrites the original > CallerId, why do we think we need any changes of the current > behavior? Does it matter which error code sipXbridge returns > in failure case in order for the call to use a fallback gateway? > It seems to me that fallback should work without further > modifications. >
Hi Scott, I just saw your other post from this morning talking about the "ring-twice problem". Indeed there are cases where it makes no sense to fall back to the next gateway and such cases are difficult to properly classify. With that my understanding is the gateway fallback is implemented in sipXproxy using standard SIP serial forking mechanism with q-value and the treatment is at the stack level. Since this logic has no application specific conditions (such as check which error code I returned and only sometime fallback to the next gateway) it does not make a lot of difference which error code gateway such as sipXbridge or ITSP return. As long as it is a non-2xx response sipXproxy will go to the next contact in the list. So, I am now thinking that Chris's scenario should work with no special changes in sipXbridge as long as gateway specific CallerId can be applied to the fallback route. 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
