Re: [SR-Users] How to thoroughly test a proxy?

Hi Steve, On 08/22/2013 06:25 AM, Steve Davies wrote: The specificity of almost all of these scenarios lies in the user agents that are the endpoints of the call, and not the proxy. So, while they might be useful end-to-end tests of your entire service delivery platform, they are broken down according to a taxonomy that differs from the proxy's state machine and functional orientation. Therefore, in pretty much all these cases, it's just a matter of the proxy a) handling the request and b) routing it the way it would route any request of that type. The proxy has almost no bearing on the functionality from a user experience perspective. It's no different than saying that you'd like to test a Layer 3 IP router with HTTP sessions, FTP sessions, SSH sessions, Skype, World of Warcraft--they should all work correctly if the router is doing its job at a more basic level of abstraction, and there's really no need to test them all. Proxies, basically: 1. Route and/or relay initial requests (for instance, initial INVITEs) one way. 2. Loose-route sequential (part of an established dialog between two endpoints) another way. 3. Handle certain "hop-by-hop" requests, such as CANCELs and ACKs (in response to negative reply codes, not end-to-end ACKs for 2xx responses to INVITE transactions), in particular ways. Of course, Kamailio is not just a proxy--it provides certain UAS (User Agent Server) services as well, such as a registrar, which you might be using. In those cases, the proxy itself is the logical destination of the service request. To return to your list: Hold is accomplished by reinvites which alter the SDP. Reinvites are just an instance of #2 above; they are in-dialog requests and are routed the same as any other in-dialog request. As far as whether hold/unhold actually works, that would of course depend on the endpoints. But the point is that it would not depend on the proxy. Depending on how this is handled, it's just a matter of admitting the right kinds of requests through. "Attended" transfers usually generate reinvites that send the media elsewhere while hairpinning signaling through the original caller. "Blind" transfers may be done via REFER, in which case you have to handle those correctly, but that shouldn't entail anything exotic. As long as you have a normal loose_route() section in your config, that will work. Session timers (RFC 4028) are specifically handled by the endpoints, not by the proxy. This is a media/codec question, and is elaborated upon in the SDP payload, to which the proxy is totally agnostic, except in cases where rtpproxy is involved. Rtpproxy proxies RTP, not UDPTL. So, it won't relay T.38 frames. That depends exactly on who is subscribing to what, but again, is largely a matter of routing and/or authenticating the SUBSCRIBEs and NOTIFYs correctly. -- Alex -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/