3 Mar
2015
3 Mar
'15
6:56 p.m.
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
3 Mar
3 Mar
6:59 p.m.
On 03/03/2015 11:56 AM, Jayanth Acharya wrote:
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) ?
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
--
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/
7:08 p.m.
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(a)evaristesys.com>
wrote:
On 03/03/2015 11:56 AM, Jayanth Acharya wrote:
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) ?
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
--
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/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:18 p.m.
On 03/03/2015 12:08 PM, Jayanth Acharya wrote:
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 ?
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
--
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/
7:29 p.m.
Thanks, that puts my performance worry to rest.
On Tue, Mar 3, 2015 at 10:48 PM, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
On 03/03/2015 12:08 PM, Jayanth Acharya wrote:
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 ?
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
--
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/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:21 p.m.
On Tuesday 03 March 2015 17:56:45 Jayanth Acharya wrote:
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) ?
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.
--
Telefoon: 088 0100 700
Sales: sales(a)pocos.nl | Service: servicedesk(a)pocos.nl
http://www.pocos.nl/ | Croy 9c, 5653 LC Eindhoven | Kamer van Koophandel
17097024
7:31 p.m.
On 03/03/2015 12:21 PM, Daniel Tryba wrote:
$var(contact) = $T_rpl($ct);
$var(contact) = $(var(contact){re.subst,/^<(sip:\+?
[0-9]+@.*)>$/\1/});
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
--
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/
7:38 p.m.
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.
--
Telefoon: 088 0100 700
Sales: sales(a)pocos.nl | Service: servicedesk(a)pocos.nl
http://www.pocos.nl/ | Croy 9c, 5653 LC Eindhoven | Kamer van Koophandel
17097024
$var(contact) = $(var(contact){re.subst,/^<(sip:\+?
[0-9]+@.*)>$/\1/});
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});
7:39 p.m.
On 03/03/2015 12:38 PM, Daniel Tryba wrote:
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.
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. :-)
--
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/
7:40 p.m.
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(a)pocos.nl> wrote:
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.
--
Telefoon: 088 0100 700
Sales: sales(a)pocos.nl | Service: servicedesk(a)pocos.nl
http://www.pocos.nl/ | Croy 9c, 5653 LC Eindhoven | Kamer van Koophandel
17097024
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
$var(contact) = $(var(contact){re.subst,/^<(sip:\+?
[0-9]+@.*)>$/\1/});
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});
7:42 p.m.
On 03/03/2015 12:40 PM, Jayanth Acharya wrote:
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 ?
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");
--
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/
7:48 p.m.
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(a)evaristesys.com>
wrote:
On 03/03/2015 12:40 PM, Jayanth Acharya wrote:
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 ?
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");
--
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/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:50 p.m.
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
--
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/
7:32 p.m.
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(a)pocos.nl> wrote:
On Tuesday 03 March 2015 17:56:45 Jayanth Acharya
wrote:
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) ?
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.
--
Telefoon: 088 0100 700
Sales: sales(a)pocos.nl | Service: servicedesk(a)pocos.nl
http://www.pocos.nl/ | Croy 9c, 5653 LC Eindhoven | Kamer van Koophandel
17097024
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:35 p.m.
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 - 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/
3552
days inactive
3552
days old
14 comments
3 participants
participants (3)
-
Alex Balashov -
Daniel Tryba -
Jayanth Acharya