Change default call_id_var and app_id_var

goodboy commented 6 years ago

Issue by tgoodlet Wednesday Mar 16, 2016 at 03:49 GMT Originally opened as https://github.com/sangoma/switchy/issues/31

When stress testing external VoIP software, switchy attempts to track calls through an association of sessions (SIP legs) corresponding to each full media path. Having access to all sessions composing a call allows test apps to implement various higher level control logic. By default we have been appending X-headers using the outbound originate command (and thus SIP invite) which can be referenced on subsequent SIP legs/sessions known to FreeSWITCH. In other words, if the device under test (DUT) forwards custom headers then call tracking is supported by default. However, call tracking can be accomplished by using other SIP headers as is the case with stress testing our Vega product line.

Currently by default we:

track calls using a sip_h_X-switchy_originating_session header which should contain a unique id within the context of the test session / outbound calls set
activate switchy apps through a sip_h_X-switchy_app header which normally contains whatever name (str) the app was registered with

I propose instead to:

track calls by inserting a unique id into the FROM header's display name

This is a good alternative to the current solution since it has nearly the same semantics (using a caller's "id"-ish header to identify unique calls).
activate switchy apps using the request-uri user part

This falls inline with traditional notions of DIDs and extensions (i.e. routing semantics) when switchy is utilized as a call routing / dialplan alternative

I'm looking for any criticisms or foresight as to whether to go ahead with this @moises-silva, @ncorbic, @joegen.

goodboy commented 6 years ago

Comment by moises-silva Wednesday Mar 16, 2016 at 16:00 GMT

@tgoodlet One problem I can see if a test case requires a specific display name. I think in the past we suggested as well using R-URI or From URI parameters, which seem like a better fit IMO.

goodboy commented 6 years ago

Comment by tgoodlet Monday Apr 25, 2016 at 21:03 GMT

@moises-silva ran into needing this again when testing asterisk since it doesn't forward the custom headers by default (afaict anyway). So your suggestion is to use the R-RUI userpart (variable_sip_req_user) for the destination app and params (variable_sip_req_params) for the call tracking id?

goodboy commented 6 years ago

Comment by moises-silva Tuesday Apr 26, 2016 at 05:23 GMT

@tgoodlet Yeah that's what I was suggesting. Mind you, for Asterisk should be easy enough to forward the headers using the SIP_HEADER() Dialplan Function and then SIPAddHeader()

Any kind of R-URI or From: parameters most likely will require dialplan tweaking as well anyways, as the only thing that goes thru 'by default' is the destination number, usually the user part of the R-URI, but not even that I think is universal across PBXs/SoftSwitches (Asterisk, FreeSWITCH, etc) and also typically depends on other config parameters and/or version of the software in question.

goodboy commented 6 years ago

Comment by tgoodlet Tuesday May 03, 2016 at 02:53 GMT

@moises-silva So my hope is to minimize custom config on DUTs as much as possible. With asterisk I was able to use the same config as I do for vega where the dest number is in the R-URI user part and the switchy app is in the From: / CID. As in my original suggestion I think the reverse of this is most intuitive (app name in the dest number and calls tracking number in the CID). You mentioned that this restricts the case where we need to test something with the contents of the From: altered. Would this not be a better test for SIPp or something similar? The main goal here is sensible defaults such that testing and switchy based call control is useful out-of-the-box.

goodboy commented 6 years ago

Comment by moises-silva Tuesday May 03, 2016 at 10:31 GMT

@tgoodlet Go for it. My concern was entirely hypothetical, and if you're seeing benefits already of using your approach in the field and it's simpler, stick to it. We can always revisit if the need ever comes to use switchy to use different From headers. Mind you, iirc if you look at high end load testing equipment like IxLoad from Ixia they're able to simulate 'real traffic' by spoofing mac address and using different from From/To numbers. We may not need that much though, but just so you know where my reasoning was coming from. As I said, do whatever works better for now, we can always revisit or extend it for advanced scenarios like that to use some other parameter/field in the SIP packet for leg correlation.

joegen commented 6 years ago

You can use the Subject header. It is standard and will not affect call semantics.

goodboy commented 6 years ago

Thanks @joegen. Any idea the FS channel variable off-hand?

friends-of-freeswitch / switchio

Change default call_id_var and app_id_var #20