From: "McFarland, Keith A." <[EMAIL PROTECTED]> This 3rd Party server does not sit in the middle of the SIP call flow (as does a proxy or 3pcc) but sits off to the side and other proxies (MSC or PSTN switches, in this case they act as SIP gateways) would call out to this 3rd party SIP server to get direction on voice call treatment. This call treatment could include just simple authorization to proceed, denial, redirection with or without special treatment etc. What I am trying to find is a best practices to cover this scenario.
SIP allows a great many ways to process calls; I don't believe that there are many "best practices" because SIP is very flexible, and as long as system components follow the SIP rules, they can be truly mix-and-matched. One architecture you may want to consider is the one that the sipX open-source proxy uses (see http://www.sipfoundry.org): A call to sip:[EMAIL PROTECTED] is routed (via RFC 3263 mechanisms) to a "forking proxy". The forking proxy, through a small number of configured rules, sends the call to the "redirector" (which also functions as the registrar for the domain). The redirector decides how the call should be processed, and effects that decision by sending a 302 redirection response back to the forking proxy. The forking proxy acts on the 302 to send the call to the various allowed destinations. The redirector is modularized, and produces responses which incorporate registered telephones for the URI, call forwarding, call park and pick-up, voice mail fallback, etc. The forking proxy is just a forking engine, and need have no understanding of the policy or routing logic, it just obeys the 302 that it is given. In sipX, all outgoing requests from the forking proxy are then sent to the "authorization proxy", which applies authorization rules, and then sends the requests to their destinations. This allows a separation of function: forking proxy - the forking logic redirector - routing decisions authorization proxy - authorization decisions The authorization proxy could be combined with the redirector without complicating the structure much. Only the authorization proxy participates in a call after it is set up (the redirector is not involved because it has given a 302 response and the forking proxy has sent the call elsewhere, the forking proxy does not Record-Route itself). Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
