Would like to know if Kamilio (in it's sip-proxy role) could be configured to somehow take note of the 'Contact:' header of a 302 response from B-party, to forward the INVITE to C-party (specified by the updated Contact URI) ?
Alternatively, is there a way for the B-party SIP UAS to get the proxy (Kamilio) to forward the INVITE (from A-party) to C-party ? Does Kamilio have to be configured to act in a specific / non-default role ? In doing so, B-party receives no further SIP messages for this particular dialog.
thanks, J
On 03/03/2015 11:56 AM, Jayanth Acharya wrote:
Absolutely. You can catch the 302 redirect in a failure_route, parse it out, set it to be the new Request URI, and t_relay() it back out (thus creating another branch).
-- Alex
Thanks Alex.Wow, that was very fast. I am new to Kamilio (and SIP in general), but a quick research tells that I've to configure Kamilio to run in the transaction stateful mode, which in turn brings down it's performance. Is that correct ?
On Tue, Mar 3, 2015 at 10:29 PM, Alex Balashov abalashov@evaristesys.com wrote:
On 03/03/2015 12:08 PM, Jayanth Acharya wrote:
No, not really. :-) This is true, strictly speaking, in a purely formal, computational sense, because maintaining state does entail more overhead. However, the advice to limit use of transaction-stateful mode for performance reasons really harks back to a different time in the evolution of computing hardware. With modern CPUs this difference is not significant, and Kamailio's internal architecture is still very performance-oriented.
Moreover, I would say 90%+ of useful uses of Kamailio, such as this one, require transaction state. There's not much that can be done just by routing SIP messages ad hoc, based on their content alone. I think the only real use-case for stateless relay these days is a fire-and-forget load balancer.
Opinions on this do vary, but regardless, you should not have any compunctions about using TM. If you look around on the web for example configs to do anything, virtually all of them use TM -- for a reason.
-- Alex
Thanks, that puts my performance worry to rest.
On Tue, Mar 3, 2015 at 10:48 PM, Alex Balashov abalashov@evaristesys.com wrote:
On Tuesday 03 March 2015 17:56:45 Jayanth Acharya wrote:
No problem, if you take a look at the "default" config it will have a failure_route[MANAGE_FAILURE] and a WITH_BLOCK3XX define commented. The failure route will normally block 302:
# block call redirect based on 3xx replies. if (t_check_status("3[0-9][0-9]")) { send_reply("404","Not found BLOCK3XX"); exit; }
If you replace (or insert before) above code something like:
if (t_check_status("302") { $var(contact) = $T_rpl($ct); $var(contact) = $(var(contact){re.subst,/^<(sip:+? [0-9]+@.*)>$/\1/});
$du=$null; $ru=$var(contact);
route(RELAY); exit; }
You have your case solved.
BTW you might want to do additonal checks when billing is concerned.
On 03/03/2015 12:21 PM, Daniel Tryba wrote:
I would recommend, from a best-practical perspective, not doing this substitution, but instead using transformations[1] to extract the URI. The Contact header is a "name-address pair", so you can extract the URI component this way:
$var(contact) = $(T_rpl($ct){nameaddr.uri});
There are many reasons for doing this, but the most significant is that the formal properties of a grammatically correct SIP URI are actually quite complex and certainly go beyond <(sip:+?>[0-9]+@.*)>:
1. The URI scheme doesn't have to be sip:, but can also be sips:.
2. The user part of the RURI doesn't have to be numeric, but can be alphanumeric and also contain quite a lot of symbols (e.g. '+').
3. The @domain portion is optional.
sip:1.2.3.4:5060 is a valid URI.
4. In a name-address header like Contact, the URI is not required to be encapsulated in <>s, although practically, it most often is.
This is a valid Contact header:
Contact: sip:user@1.2.3.4:5060
-- Alex
[1] http://www.kamailio.org/wiki/cookbooks/4.2.x/transformations, specifically:
http://www.kamailio.org/wiki/cookbooks/4.2.x/transformations#nameaddruri
On Tuesday 03 March 2015 18:31:13 Alex Balashov wrote:
[Multiple valid reasons.]
Thanks Alex, I'll take your advice on this.
BTW I don't allow client endpoints to do redirects, I only accept this from my redirecters so I'm not concerned about strange headers not handled by my subst.
On 03/03/2015 12:38 PM, Daniel Tryba wrote:
I understand. But it's still not "formally correct" because it captures only one of the many possible grammatical permutations into which the Contact URI can be structured. That is why Kamailio provides string functions (transformations) that are designed with these possibilities in mind. :-)
Thanks again Alex, pretty clear - I suppose.
BTW, Daniel - one point in your reply to Alex caught my attention "I don't allow client EPs to do redirects"... perhaps this is very simply, but how is this prohibited ?
On Tue, Mar 3, 2015 at 11:08 PM, Daniel Tryba d.tryba@pocos.nl wrote:
On 03/03/2015 12:40 PM, Jayanth Acharya wrote:
This is something that is baked into the logic of your routing, i.e. don't arm[1] the redirect-following failure_route when routing requests to a destination other than your trusted redirect server.
-- Alex
[1] t_on_failure("YOUR_FR_ROUTE");
Will need to read a bit more to understanding it completely, but I think I get the gist. Thanks again.
This is an amazing community.
On Tue, Mar 3, 2015 at 11:12 PM, Alex Balashov abalashov@evaristesys.com wrote:
On 03/03/2015 12:48 PM, Jayanth Acharya wrote:
This is an amazing community.
Thank you, we try.
But in all fairness, you are also the ideal newbie; you're asking very specific, defined questions that have specific, detailed answers, so it's easy to help you.
Sometimes newbies show up and simply post, "It doesn't work, make it work for me!" That's a lot harder. :-)
-- Alex
Thanks Daniel, couldn't have asked for more.
Daniel and Alex, one further question... (theoretical, since I'm yet to try this out) -
Would Kamilio also take care to send out the ACK to end the trasaction with B-party, and continue the relayed transaction with C-party ? Is this, in effect same as serial forking ?
Apologies for questions that are perhaps more to do with SIP, than Kamilio itself.
On Tue, Mar 3, 2015 at 10:51 PM, Daniel Tryba d.tryba@pocos.nl wrote:
On 03/03/2015 12:32 PM, Jayanth Acharya wrote:
Would Kamilio also take care to send out the ACK to end the trasaction with B-party, and continue the relayed transaction with C-party ?
Indeed it will.
Is this, in effect same as serial forking ?
It is not only in effect the same as serial forking, but is, in fact, exactly serial forking. The only way that a proxy can call B and then call C is to create another branch ("fork"). :-)
The different 'branch' IDs you'll see in the Via headers on the outgoing INVITEs from Kamailio will reflect that fact.
Apologies for questions that are perhaps more to do with SIP, than Kamilio itself.
No need to apologise. The two are closely intertwined, because Kamailio's domain-specific route script language is closely aligned with the SIP transactional state machine. Ergo, much of learning to use Kamailio involves learning SIP.
-
Alex Balashov -
Daniel Tryba -
Jayanth Acharya