Hi Kamailians,
Can anyone on the list point me at a list of call flow scenarios I should consider and test to be confident my proxy setup works properly.
I'm not looking at the moment for some sort of SIPit torture test, just a sensible set of scenarios.
This is for my client side "outbound sip/rtp proxy"
I so far have thought about:
Ordinary outbound and inbound calls Holding / unholding "Blind" transfers "Attended" transfers mid-call reINVITEs (session timers?) T.38 Subscriptions
In all cases with calls initially outbound or inbound, and doing the hold/transfer at both ends.
Thanks, Steve
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
Hi Alex,
On 22 August 2013 12:46, Alex Balashov abalashov@evaristesys.com wrote:
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.
I do take your point.
So since I correctly handle initial requests and the replies, and can handle in-dialog requests and replies, and deal with those hop-by-hop requests, I can just relax and be happy?
As you say, my different end-user scenarios boil down to the same "elements", but in practice my tests did find a problem with the way my Enswitch proxy was handling loose-routed NOTIFYs.
Users are very good at finding odd corner-cases, so it seems helpful to consider in advance flows that exercise unusual paths through the proxy config.
Regards, Steve
I do not disagree with any of that, or with testing your flows end-to-end to uncover problems. I just meant that most of your examples were not particularly anchored, conceptually.
The subscribe/notify may be rather more of an exception.
Steve Davies steve@connection-telecom.com wrote:
Hi Alex,
On 22 August 2013 12:46, Alex Balashov abalashov@evaristesys.com wrote:
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.
I do take your point.
So since I correctly handle initial requests and the replies, and can handle in-dialog requests and replies, and deal with those hop-by-hop requests, I can just relax and be happy?
As you say, my different end-user scenarios boil down to the same "elements", but in practice my tests did find a problem with the way my Enswitch proxy was handling loose-routed NOTIFYs.
Users are very good at finding odd corner-cases, so it seems helpful to consider in advance flows that exercise unusual paths through the proxy config.
Regards, Steve
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
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
On 22 August 2013 15:13, Alex Balashov abalashov@evaristesys.com wrote:
I do not disagree with any of that, or with testing your flows end-to-end to uncover problems. I just meant that most of your examples were not particularly anchored, conceptually.
OK - I concede that point. Since it was really just a top-of-the head list I wrote down of "stuff people do with their phones".
Thanks, Steve
A side note to let people know that inside sources of kamailio is a set of shell scripts that do various test scenarios (using sipp) -- they are located inside test/unit/ folder.
While they target now to detect basic issues upon development of kamailio, some of them are a good start to build your own scenarios.
Cheers, Daniel
On 8/22/13 3:24 PM, Steve Davies wrote:
On 22 August 2013 15:13, Alex Balashov <abalashov@evaristesys.com mailto:abalashov@evaristesys.com> wrote:
I do not disagree with any of that, or with testing your flows end-to-end to uncover problems. I just meant that most of your examples were not particularly anchored, conceptually.OK - I concede that point. Since it was really just a top-of-the head list I wrote down of "stuff people do with their phones".
Thanks, Steve
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On Thursday 22 August 2013 12:46:49 Alex Balashov wrote:
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.
I'm pretty sure I have seen working T38 with Kamailio using forced rtpproxying (on Debian/squeeze and kamailio 3.4.x). A quick search suggests this should just work.
On 8/22/13 5:26 PM, Daniel Tryba wrote:
On Thursday 22 August 2013 12:46:49 Alex Balashov wrote:
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.
I'm pretty sure I have seen working T38 with Kamailio using forced rtpproxying (on Debian/squeeze and kamailio 3.4.x). A quick search suggests this should just work.
Yes, definitely works -- rtpproxy forwards t.38/udptl.
Cheers, Daniel
On 08/22/2013 11:56 AM, Daniel-Constantin Mierla wrote:
Yes, definitely works -- rtpproxy forwards t.38/udptl.
It does?! Since when?
On 8/22/13 6:04 PM, Alex Balashov wrote:
On 08/22/2013 11:56 AM, Daniel-Constantin Mierla wrote:
Yes, definitely works -- rtpproxy forwards t.38/udptl.
It does?! Since when?
In my short memory, that would be since ever, like from ser times.
Cheers, Daniel
-
Alex Balashov -
Daniel Tryba -
Daniel-Constantin Mierla -
Steve Davies