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

[Alex Balashov]

Hi Steve,

On 08/22/2013 06:25 AM, Steve Davies wrote:

> Ordinary outbound and inbound calls
> Holding / unholding
> "Blind" transfers
> "Attended" transfers
> mid-call reINVITEs (session timers?)
> T.38
> Subscriptions

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:

 > Holding / unholding

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.

 > "Blind" transfers
 > "Attended" transfers

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.

 > mid-call reINVITEs (session timers?)

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.

 > T.38

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.

 > Subscriptions

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/