[SR-Users] Enforcing add_contact_alias()
Hey Guys, For those of you familiar with internal mechanism of add_contact_alias, I got a question/issue: I have noticed that if add_contact_alias is called without any parameters it will not work (eg: not add the alias parameter in contact) in case of ip/port/transport of the received messages are matching what the contact declares. On the other hand if I use add_contact_alias($si, $sp, $proto), the contact alias will be always enforced. Due to way routing works in my case I would need always the alias to be added. Am I forced to pass the parameters, eg the desired behaviour is to only add contact alias on need and not enforce? Ta for any kind of tip! DanB ___ 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
Re: [SR-Users] Enforcing add_contact_alias()
Hey Juha, Thanks for your promt answer! All clear now. I just wanted to make sure I optimize my config to maximum (sparing characters inthere ;)). Maybe someone can update the documentation since using/not using the params can influence the behaviour. Cheers, DanB if you want to be sure that contact alias is added even if it would not add any value, you need to use it with parameters. -- juha ___ 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
Re: [SR-Users] UDP-TCP bridging in-dialog SUBSCRIBE
Hey Paul,
Thanks for your feedback!
In this case the call will come in via UDP (so it has 2 record route
headers). I can still play tricks like reading the record-route headers
but, I was in some way hoping that is the responsibility of
loose_route() function to properly use the right protocol out of route
headers since we are a proxy.
Cheers,
DanB
On 14.11.2014 12:00, sr-users-requ...@lists.sip-router.org wrote:
Message: 3
Date: Thu, 13 Nov 2014 16:55:18 +0530
From: Varghese Paulvarghesepau...@gmail.com
To: Kamailio (SER) - Users Mailing List
sr-users@lists.sip-router.org
Subject: Re: [SR-Users] UDP-TCP bridging in-dialog SUBSCRIBE
Message-ID:
CAM33Ch4furD1FM-ZNKfbQ0nXNQd88BmzW73gjjb=cVyuC0K=8...@mail.gmail.com
Content-Type: text/plain; charset=utf-8
Hi Dan,
You can check the transport value in the RURI and relay the SIP message as
tcp.
if ($*rP* == tcp){
t_relay_to_tcp()
}
Regards
Varghese Paul
___
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
Re: [SR-Users] UDP-TCP bridging in-dialog SUBSCRIBE
Thanks Alex for your confirmation. In some way I was afraid about this ;). Have a good one! DanB ___ 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
[SR-Users] UDP-TCP bridging in-dialog SUBSCRIBE
Hey Guys, I have the following scenario: UA1 (UDP) - Kamailio Proxy - (TCP) UA2 As per the signaling sample, I would expect that in-dialog SUBSCRIBEs are bridged between UDP and TCP network but for some reason this does not happen (the subscribe comes in over UDP and leaves still over UDP although tcp is present in the route headers). Are we somehow forced to mangle contact header and add transport parameter to it or the record-route headers should serve for this purpose? Any tip would be highly appreciated. Ta, DanB Bellow the traces for initial SUBSCRIBEs as well as in-dialog ones (info mangled to protect privacy). # Normally routed request (non-dialog one, correctly bridged) # # U 2014/11/12 19:04:51.293887 pub_ip_ua:54705 - pub_ip_ep:5060 SUBSCRIBE sip:us...@fakedomain.com:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.243.82:5062;branch=z9hG4bK1114302228. From: user2 sip:us...@fakedomain.com;tag=1003326118. To: sip:us...@fakedomain.com. Call-ID: 1273081718. CSeq: 2 SUBSCRIBE. Contact: sip:user2@192.168.243.82:5062. Accept: application/dialog-info+xml. Max-Forwards: 70. User-Agent: Tiptel IP 284 6.70.13.18 0015651b574f. Expires: 60. Event: dialog. Content-Length: 0. . # T 2014/11/12 19:04:51.295706 pub_ip_ep:34052 - 192.168.51.168:5060 [AP] SUBSCRIBE sip:user1@192.168.51.168:5060;transport=tcp SIP/2.0. Record-Route: sip:pub_ip_ep;transport=tcp;r2=on;lr;nat=yes. Record-Route: sip:pub_ip_ep;r2=on;lr;nat=yes. Via: SIP/2.0/TCP pub_ip_ep;branch=z9hG4bKe26f.3dce66bd1976447b88f6096e926ce68c.0. Via: SIP/2.0/UDP 192.168.243.82:5062;rport=54705;received=pub_ip_ua;branch=z9hG4bK1114302228. From: user2 sip:us...@fakedomain.com;tag=1003326118. To: sip:us...@fakedomain.com. Call-ID: 1273081718. CSeq: 2 SUBSCRIBE. Contact: sip:user2@192.168.243.82:5062;alias=pub_ip_ua~54705~1. Accept: application/dialog-info+xml. Max-Forwards: 65. User-Agent: Tiptel IP 284 6.70.13.18 0015651b574f. Expires: 60. Event: dialog. Content-Length: 0. . # T 2014/11/12 19:04:51.300350 192.168.51.168:5060 - pub_ip_ep:34052 [AP] SIP/2.0 202 Accepted. Via: SIP/2.0/TCP pub_ip_ep;branch=z9hG4bKe26f.3dce66bd1976447b88f6096e926ce68c.0;rport=34052. Via: SIP/2.0/UDP 192.168.243.82:5062;rport=54705;received=pub_ip_ua;branch=z9hG4bK1114302228. Record-Route: sip:pub_ip_ep;transport=tcp;r2=on;lr;nat=yes. Record-Route: sip:pub_ip_ep;r2=on;lr;nat=yes. From: user2 sip:us...@fakedomain.com;tag=1003326118. To: sip:us...@fakedomain.com;tag=PFxfnedC0jP7. Call-ID: 1273081718. CSeq: 2 SUBSCRIBE. Contact: sip:user1@192.168.51.168:5060. Expires: 60. User-Agent: Sipean-AS 1.2.10. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, path, replaces. Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Subscription-State: active;expires=60. Content-Length: 0. . ## U 2014/11/12 19:04:51.300745 pub_ip_ep:5060 - pub_ip_ua:54705 SIP/2.0 202 Accepted. Via: SIP/2.0/UDP 192.168.243.82:5062;rport=54705;received=pub_ip_ua;branch=z9hG4bK1114302228. Record-Route: sip:pub_ip_ep;transport=tcp;r2=on;lr;nat=yes. Record-Route: sip:pub_ip_ep;r2=on;lr;nat=yes. From: user2 sip:us...@fakedomain.com;tag=1003326118. To: sip:us...@fakedomain.com;tag=PFxfnedC0jP7. Call-ID: 1273081718. CSeq: 2 SUBSCRIBE. Contact: sip:user1@192.168.51.168:5060. Expires: 60. User-Agent: Sipean-AS 1.2.10. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, path, replaces. Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Subscription-State: active;expires=60. Content-Length: 0. ## NOT BRIDGED, IN-DIALOG requests: ## # U 2014/11/12 19:46:18.448550 pub_ip_ua:54705 - pub_ip_ep:5060 SUBSCRIBE sip:user1@192.168.51.168:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.243.82:5062;branch=z9hG4bK459444805. Route: sip:pub_ip_ep;r2=on;lr;nat=yes. Route: sip:pub_ip_ep;transport=tcp;r2=on;lr;nat=yes. From: user2 sip:us...@fakedomain.com;tag=1902678123. To: sip:us...@fakedomain.com;tag=2518urgZJFet. Call-ID: 2104228355. CSeq: 3 SUBSCRIBE. Contact: sip:user2@192.168.243.82:5062. Accept: application/dialog-info+xml. Max-Forwards: 70. User-Agent: Tiptel IP 284 6.70.13.18 0015651b574f. Expires: 60. Event: dialog. Content-Length: 0. . # U 2014/11/12 19:46:18.449161 pub_ip_ep:5060 - 192.168.51.168:5060 SUBSCRIBE sip:user1@192.168.51.168:5060 SIP/2.0. Via: SIP/2.0/UDP pub_ip_ep;branch=z9hG4bK7de2.a9aed4070706f93b25b4d2d3d7963a19.0. Via: SIP/2.0/UDP 192.168.243.82:5062;rport=54705;received=pub_ip_ua;branch=z9hG4bK459444805. From: user2 sip:us...@fakedomain.com;tag=1902678123. To:
[SR-Users] Redirection buffer length exceed
Hey Guys,
We are facing quite often this error:
/usr/sbin/kamailio[16985]: ERROR:
core [dset.c:435]: print_dset(): ERROR: redirection buffeROR:
redirection buffer length exceed
When the error is generated, there will be a missing contact in the
redirects (not to mention that Kamailio will crash in uac_redirect for
versions before 4.2.0).
Can anyone explain the nature of this buffer and whether is affected by
a single contact or all the contacts together building the final
redirect? How can we control what's in that buffer from the script?
This is our script part building the redirects, out of location data:
if(!reg_fetch_contacts(location, $ru, called)) {
send_reply(404, Not Found);
exit;
}
if $(ulc(called=count)) == 0 { # No contacts for this user online
sl_send_reply(404, Not found);
exit;
}
$var(i) = 0;
while($var(i) $(ulc(called=count))) {
$var(pathUri) =
$(ulc(called=path)[$var(i)]{s.strip,1}{s.striptail,1}); #Strip so we
can apply real uri transformations
$var(newRURI) = $(ulc(called=addr)[$var(i)]) +
;ipbxep= + $(var(pathUri){uri.host});
if $var(i) == 0 {
$ru = $var(newRURI);
} else {
append_branch($var(newRURI));
}
$var(i) = $var(i) + 1;
}
Thanks in advance for any kind of tip!
DanB
___
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
Re: [SR-Users] Redirection buffer length exceed
Hey Daniel, Thanks for your fast feedback! Not sure what is the best approach on this. We reach the 512 limit sometimes even with just 2 contacts in one AOR (since we cannot pass the path in redirect, we use a uri parameter to add it and process that later in other components, so I guess that is our sin). I guess we can work with 1024 as well, but on the other hand, how can I control what goes into that buffer? Will counting in the script of the RURIs length in all of the branches before calling 302 be sufficient to keep the buffer under it's limits? Would it be not possible for the core to check on each contact if adding it will not create the buffer overflow instead of dropping all data in the buffer (returning no contact) when that happens? The issue is that it is hard for me as admin to know what will go into the contact data since that content comes directly from UAs. Cheers, DanB looks like the overall buffer for contacts in redirect is 512 in size, perhaps same value from early beginnings. MAX_REDIRECTION_LEN in config.h needs to be changed to larger value -- should 1024 be enough? Cheers, Daniel ___ 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
Re: [SR-Users] Redirection buffer length exceed
Hey Daniel, OK, in that case if not too much trouble, please increase the buffer size to 1024 and I will try to manage it also in the script. Thanks again! DanB ___ 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
Re: [SR-Users] RPC uac.reg_info hangs second time
Hey Daniel, For the sake of the records, I confirm that the issue with uac.reg_info hanging when executed second time is gone in nightly packages. Thanks again! Cheers, DanB ___ 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
[SR-Users] RPC uac.reg_info returns empty when filter contains large number of characters
Guys,
I have found that uac.reg_info does not properly filter the records in
case of l_uuid being too large (works fine with small number of characters).
Here is the concrete example:
root@Dev2:/home/dan# kamcmd -s tcp:127.0.0.1:2046 uac.reg_info
l_username 8944538525001446036
root@Dev2:/home/dan# kamcmd -s tcp:127.0.0.1:2046 uac.reg_info l_uuid
8944538525001446036
root@Dev2:/home/dan# kamcmd -s tcp:127.0.0.1:2046 uac.reg_info
auth_username 301
{
l_uuid: 8944538525001446036
l_username: 8944538525001446036
l_domain: 172.16.254.75
r_username: 301
r_domain: pbx.example.com
realm: asterisk
auth_username: 301
auth_password: check123
auth_proxy: sip:172.16.254.75
expires: 360
flags: 12
diff_expires: 120
timer_expires: 1414838083
}
root@Dev2:/home/dan# kamcmd -s tcp:127.0.0.1:2046 uac.reg_info
r_username 301
{
l_uuid: 8944538525001446036
l_username: 8944538525001446036
l_domain: 172.16.254.75
r_username: 301
r_domain: pbx.example.com
realm: asterisk
auth_username: 301
auth_password: check123
auth_proxy: sip:172.16.254.75
expires: 360
flags: 0
diff_expires: 211
timer_expires: 1414838323
}
Thanks in advance for any kind of tip!
DanB
___
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
Re: [SR-Users] [OT] Accounting Drouting Gateway Selection
Hi Spencer, We use a similar approach as yours and use 302 Redirects coming from Kamailio instead of proxying the call (in our case we do it via LCR module in Kamailio). In FreeSWITCH you can then manually route these redirects and get your CDR data out of it. Cheers, DanB On 22.09.2014 12:00, sr-users-requ...@lists.sip-router.org wrote: On 18/09/14 17:34, Spencer Thomason wrote: Hello all, I have a need to determine which calls go to which gateway. The challenge is that CDRs are produced by a FreeSWITCH instance upstream of a provider side Kamailio proxy that handles route selection via drouting module. The topology is like this: customer proxy - FS [1-N] (accounting) - carrier proxy (route selection) Does anyone have any ideas how to make the FreeSWITCH instances aware of which gateway actually received the call? ___ 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
Re: [SR-Users] UAC remote registration - refreshing database
Hey Daniel, I totally agree on improving versus adding new module. The only thing which made me going towards porting was not knowing how easy would be enhancing vs porting something which is implemented. Also the fact that Alexa has mentioned it as an often requested feature made me think that it could take a while until someone would be able to do it in the existing module. Anyway, thanks for your input! DanB PS: Ovidiu, I appreciate your feedback as well. Good to know that you are around ;). ___ 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
Re: [SR-Users] UAC remote registration - refreshing database
Hey Alex, Many thanks for so fast answer. Could be I have missed the past interest (hence re-posting). Anyway, I wonder what would be the chances that we get Ovidiu's interest so he can port registrant module to kamailio maybe? Unfortunately without reloads it is hard to push remote registration in enterprise solutions. Thanks again, DanB On 03.07.2014 12:00, sr-users-requ...@lists.sip-router.org wrote: On 07/02/2014 06:22 AM, Dan Christian Bogos wrote: Anybody aware if it is possible to refresh the list of remote registrations from the database without restarting the whole server? This gets asked a lot, and the answer is no. But it is probably a widely desired feature set by now. -- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ Please be kind to the English language: http://www.entrepreneur.com/article/232906 ___ 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
[SR-Users] UAC remote registration - refreshing database
Hey Guys, Anybody aware if it is possible to refresh the list of remote registrations from the database without restarting the whole server? Ta, DanB ___ 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
