Thanks for the cfg, it could be useful
I'm still having my original problem though, unless i'm really
mis-understanding what subst(///) does (Substitute..)
Looking at the messages as they hit the wire shows that my subst rules
(even Klaus' copied verbatim) only end up prepending the string that its
supposed to be substituting.
I just compiled SER from the latest CVS to make sure and the problem
still occurs (i havn't tested this on any of the stable releases)
Have you come across this Klaus?
Klaus Darilion wrote:
Hi Tavis!
I did similar things when a patched ser to work as outbound proxy
(e.g. like a jasomi peer point). It's a bad hack but it works fine
with me. The regexps are attached (to avoid line breaks in the email).
These regexp works following:
user@domain ==> user_domain@proxyIPaddress
in the reply_route, it works the other way round
user_domain@proxyIPaddress ==> user@domain
To use it as outbound proxy, I also had to modify the save() function
to use user_domain@proxyIPaddress as AOR instead of the real AOR.
regards,
klaus
reticent wrote:
I've got a situation where i need to
replicate registrations to an
outside proxy, a simple replicate wont work because i need the
registration on the outside proxy to reference the SER proxy and not
the client directly.
The one requirement is that i know (in a scripting context) what the
username of the registration is so i can construct a Contact that
contains it.
The only function i've found that could do this is the subst(///)
function in the textops.so module, however its acting very strangely.
Ex.
subst('/^Contact:.*sip:([0-9]+)@.*$/Contact:
<sip:\1@!OUTSIDE_PROXY!>/');
Seems to match properly, but inspecting the packet as its routed out
(using ngrep) shows the following contact field
"<sip:200010001000@!OUTSIDE_PROXY!>sip:200010001000@!ORIGINAL_IP!:5070."
My understanding is that "sip:200010001000@!ORIGINAL_IP!:5070" should
have been replaced with <sip:200010001000@!OUTSIDE_PROXY!> instead of
being prepended.
Perhaps there is a module that provides a function that would allow
me to manipulate the contact more easily (i'm aware that the regex in
the subst in inadequate and would not match the full range of RFC3261
valid Contact strings, i'm just testing right now)
Would anyone be able to offer any advice?
tavis
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
------------------------------------------------------------------------
route[3]
{
log(1, "Entering route[3]...");
fix_nated_register();
save_noreply("location");
#save("location");
# snom 200: Contact:
<sip:klaus@192.168.2.22:5060;transport=udp;line=50b9439q>;q=1.0
# \1 \2 \3 \4 \5
if (
subst('/^Contact:(.*)<sip:([^@]+)@([^;]*);(.*)>(.*)$/Contact:\1<sip:\2_\3@83.136.32.80;\4>\5/ig')
) {
log(1, "Contact in REGISTER rewritten - SNOM style\n");
}
# \1 \2 \3 \4
if (
subst('/^Contact:(.*)<sip:([^@]+)@([^;]*)>(.*)$/Contact:\1<sip:\2_\3@83.136.32.80>\4/ig')
) {
log(1, "Contact in REGISTER rewritten - SIPURA style\n");
}
#Contact: <sip:84.20.178.249:10247>;methods="INVITE, MESSAGE, INFO,
OPTIONS, BYE, CANCEL, ACK, REFER"
# \1 \2 \3
if (
subst('/^Contact:(.*)<sip:([^@]+)>(.*)$/Contact:\1<sip:_\2@83.136.32.80>\3/ig')
) { #Messenger style contact without username
log(1, "Contact in REGISTER rewritten - RTC API style\n");
}
t_on_reply("3");
t_relay();
log(1, "... leaving route[3]");
break;
}
onreply_route[3]
{
log(1, "Entering onreply_route[3]...\n");
# \1 \2 \3 \4
if (
subst('/^Contact:(.*)<sip:_(.*?)@(.*)>(.*)$/Contact:\1<sip:\2>\4/ig')
) { #Messenger style contact without username
log(1, "Contact in REGISTER response rewritten - RTC API
style\n");
}
# \1 \2 \3 \4 \5 \6
if (
subst('/^Contact:(.*)<sip:([^@]+)_(.*?)@([^;]*);(.*)>(.*)$/Contact:\1<sip:\2@\3;\5>\6/ig')
) {
log(1, "Contact in REGISTER respone rewritten - SNOM style\n");
};
# \1 \2 \3 \4 \5
if (
subst('/^Contact:(.*)<sip:([^@]+)_(.*?)@([^;]*)>(.*)$/Contact:\1<sip:\2@\3>\5/ig')
) {
log(1, "Contact in REGISTER respone rewritten - SIPURA
style\n");
};
log(1, "leaving onreply_route(3)\n");
}