SIP Expiry Events, the MOC, RCC and vanishing static routes RRS feed

  • Question

  • We specified a static route on a particular port (in our case to a RCC SIP gateway). This has successfully allowed us to implement and integrate RCC functionality to our PBX system


    We have, however, over time noticed a small and annoying problem. Every eight (8) hours each MOC (2007) issues a BYE, which is duly routed via the static route to our RCC SIP gateway. The RCC SIP gateway acknowledges the BYE, where upon the static route is torn down, isolating the RCC SIP gateway until another message targeted for the static route to the RCC SIP gateway arrives (either a MAKECALL or an INVITE), where upon the static route is restored. Now, the static route does not service just one MOC, it services (at least) several hundred (the entire user community). So when the static route is torn down all telephony events that the RCC SIP gateway wants to send to a particular MOC fail (there typically are many PBX initiated events (DELIVEREDEVENTS, etc.).


    From the client side it appears that RCC periodically fails and then re-establishes itself (it can also be re-established by explicitly signing out and signing in. As it is a transient error it is not easy to spot unless you know what you are looking for, this is problematic from a support perspective, so a solution is desirable.


    I have found some references to an 8 hour expiry time and in particular a reference to a SIP Stack Error Code 1004 which reads: "Expired route set signature. Server signs route header so that the client cannot alter routing path for any message inside of the dialog.  The signature is valid for a limited time (8 hours).  After 8 hours the dialog must be re-established); usually associated with a 481 error." This error (sort of) describes what is happening.


    The particular problem, as I see it, is that a static route that services connections other than the expired connection should probably not be torn down (or have I misunderstood the term "static"?).


    The only solution I can see at this time is to not acknowledge the BYE (thereby avoiding the tear down of the static route) and since I do not know a good BYE from a bad BYE I cannot acknowledge any BYE (apologies for the proliferation of BYE). This means that the RCC SIP gateway will register or re-register users via the INVITE but never de-register them. At this stage I can live with that.


    Has anyone observed this behavior? Is this behavior by design (can someone point me to the appropriate documentation)? Can this affect other SIP based gateway services on the end of a static route? Is my strategy a reasonable solution strategy? Is there a more robust solution strategy?

    Tuesday, August 26, 2008 1:11 AM