Hello,
If the user never registered (or few hours passed from its unregister) the
subscription to REGINFO will return an empty body NOTIFY (no xml).
I don't see any flag in module to force a body for this case, as in the
presence module is force_dummy_presence who can force a body on a first
NOTIFY.
The RFC3680 says :
o Notifications triggered from a SUBSCRIBE contain full state
(the list of all contacts bound to the address-of-record).
It appears that in this case the response is not conform to RFC.
Regards,
Adrian
Hello all!
We are running Kamailio version 5.3.3 with 16 small Asterisk servers.
Kamailio uses a dispatcher module to distribute calls. Algorithm #11 is
selected. All destinations are configured with priority set to 50 and
attribute to rweight=50.
We noticed that one server constantly receives more calls than others. I
run a few tests. I was sending 1000 calls to the system. 4 per second. All
servers except one were getting around 60 calls while the last one - around
100.
I then noticed that the server which receives most calls is always last in
the "kamcmd dispatcher.list" command output. I then changed the order in
the dispatcher DB table and repeat the test. The other server that now was
last was getting the most calls.
Does anyone else use algorithm #11 and finds the same thing? Is there
something additional that I can provide to help with the investigation?
Thanks!
Hello Kamailions,
Well, I think I found the cause of my issue where the Dialog profile was
not defined.. Well it was.
I had not enabled antiflood, by not enabling antiflood, the htable
module was also not loaded...
I guess the us of profiles_with_value parameter needs htable? Is that
correct?
If so, that means the htable is a dependency for the dialog module....,
then it would be sometihng that could be added to the documentation of
the dialog module.
When this is not the case, then I have to dig deeper, as I do not get an
error anymore about the profile not being known...
Thank you.
Gertjan
Hello,
Does anybody has used with success the reginfo modules ?
I added lines bellow in configuration, and tried different variations,
Even if my subscribe for "reginfo" events is accepted (with 202 OK), I
receive no notification when respective user registers.
Nor do I get the xml body in the first notification.
Added in my config:
loadmodule "presence_reginfo.so"
loadmodule "pua_reginfo.so"
modparam("pua_reginfo", "default_domain", "192.168.60.65")
modparam("pua_reginfo", "server_address", "sip:reginfo@192.168.60.65")
modparam("pua_reginfo", "publish_reginfo", 1)
Thank you in advance,
Adrian
Aatif Shaikh <aatif.shaikh(a)ecosmob.com>
Mon, Dec 7, 11:00 AM (3 days ago)
to sr-users
Hello All
I configure my kamailio.cfg to handle SLA using (SCA module) and shared
presence is working but still facing some issue in case of hold invite and
BYE and the reason behind of that issue is following error
Nov 26 07:38:40 SBC-4-1 /usr/local/sbin/kamailio[104107]: ERROR: sca
[sca_call_info.c:1008]: sca_call_info_invite_request_handler(): Failed to
update sip:4569@test.sip.abcd.com appearance-index 0 to active
actually, in Kamailio appearances, I can see the entry for this call but
the index is 1 instead of 0, and Kamailio going to update with a 0 index
[root@SBC-4-1 ntcarfte-kamailio]# kamcmd sca.all_appearances
sip:4569@test.sip.abcd.com 1 active 1606376289 sip:4569@10.xx.xx.xx
:5070;transport=udp sip:2003@test.sip.abcd.com
186161_mobile-rel120MTQ5OTcyZjFhMjMyNmI1ZGE1MWY4ODc2M2RkN2VmZmQ
45dc18d8 H6cS9vecZ248B
if I manually update appearances using RPC command with index 1 then the
phone started blinking as I change state to held
# kamcmd sca.update_appearance sip:4569@sc4test.sip.teledge.com 1 held
# kamcmd sca.all_appearances
sip:4569@test.sip.abcd.com 1 held 1606376516 sip:4569@10.xx.xx.xx
:5070;transport=udp sip:2003@test.sip.abcd.com
186161_mobile-rel120NzE5MDgyZDc1NjJiYjcwMWFlYmI3NzM3NjE2OTRhZjU
08f005cb eK9ratm83g92e
kamailio.cfg
route[SCA] {
if(is_method("SUBSCRIBE")) {
if ($hdr(Event) == "call-info" || $hdr(Event) ==
"line-seize") {
xlog("L_INFO","(MAIN) :HELLO ($avp(uuid)) : $avp(rsi) $sp
$hdr(Event)");
xdbg("SCA: $hdr(Event) SUBSCRIBE $ru from $si:$sp");
sca_handle_subscribe();
exit;
}
return;
}
if (!is_method("BYE|CANCEL|INVITE|PRACK|REFER")) {
return;
}
sca_call_info_update();
}
route[RELAY_OUTBOUND_FS] {
xlog("L_INFO","(RELAY_OUTBOUND_FS) : ($avp(uuid)) : INSIDE ROUTE ");
if (!has_totag()){
$avp(set_h) = 1;
}
t_on_reply("REPLY_OUTBOUND_FS");
route(SCA);
if (!t_relay()) {
sl_reply_error();
}
exit;
}
route[RELAY_INBOUND_FS] {
if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) {
$avp(s:puburis_caller) = $fu;
setflag(8);
dlg_manage();
}
if(is_method("REGISTER")) {
t_on_reply("REPLY_REGISTER");
} else {
t_on_reply("REPLY_INBOUND_FS");
}
route(SCA);
if (!t_relay()) {
sl_reply_error();
}
exit;
}
onreply_route[REPLY_INBOUND_FS] {
xdbg("incoming reply\n");
if (status =~ "[456][0-9][0-9]") {
# don't update SCA state here, since there may be
# failure route processing (e.g., call forwarding).
# update state in failure route instead.
return;
}
route(SCA);
}
onreply_route[REPLY_OUTBOUND_FS] {
xdbg("incoming reply\n");
if (status =~ "[456][0-9][0-9]") {
# don't update SCA state here, since there may be
# failure route processing (e.g., call forwarding).
# update state in failure route instead.
return;
}
route(SCA);
}
can someone help me with this Did I missed something to handle SLA?
Hello,
We have a problem with a SIP doorbell device which sends media one way
only, and NAT at the receiving device.
When the doorbell button is pressed it makes a call to a configured
destination. Since the doorbell only sends and doesn't receive it sends the
INVITE with sendonly in the SDP, and the destination then replies with a
200 OK with recvonly in the SDP. The problem is that the destination is
behind NAT, and its reply contains a private network IP in the SDP.
Normally Asterisk when nat=yes works around that by adjusting the
destination for RTP to be the address it actually receives audio from,
however because this device is recvonly Asterisk never receives audio from
it. This means Asterisk keeps trying to send the doorbell's RTP to the
private network IP which of course fails, and the destination never gets
the RTP from the doorbell.
We haven't found a solution in Asterisk to this, so are now looking to
Kamailio which acts as a load-balancing proxy in front of Asterisk for one.
For example, maybe we could use fix_nated_sdp, but only on 200 OK's with
recvonly.
Has anyone else encountered this, and are there any recommended solutions?
Thank you in advance!
--
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
The doorbell is the caller. ICE support would be required on the
callee side (between NATed callee and asterisk).
There's no need for ICE support on the doorbell/caller side.
-ovidiu
On Wed, Dec 9, 2020 at 2:42 AM Alex Balashov <abalashov(a)evaristesys.com> wrote:
>
> ICE support just doesn't seem to me to be something a SIP doorbell would
> have.
>
> On 12/9/20 2:39 AM, Olle E. Johansson wrote:
> >
> >
> >> On 8 Dec 2020, at 18:55, Richard Fuchs <rfuchs(a)sipwise.com
> >> <mailto:rfuchs@sipwise.com>> wrote:
> >>
> >> Use IPv6
> >
> > While I like that proposal, assuming that IPv6 will not have a stateful
> > firewall is propably not a good assumption.
> > So I suspect that an IPv6 firewall would not let the packets in if there
> > is not outbound traffic first. I do like Ovidius
> > ICE-based solution and would like to add RTCP - if muxed it would open
> > the port, but the likelyhood that it’s
> > implemented is propably low.
> >
> > IPv6 greetings!
> > /O :-)
> >>
> >> Cheers
> >>
> >> On 07/12/2020 23.01, David Cunningham wrote:
> >>> Hello,
> >>>
> >>> We have a problem with a SIP doorbell device which sends media one
> >>> way only, and NAT at the receiving device.
> >>>
> >>> When the doorbell button is pressed it makes a call to a configured
> >>> destination. Since the doorbell only sends and doesn't receive it
> >>> sends the INVITE with sendonly in the SDP, and the destination then
> >>> replies with a 200 OK with recvonly in the SDP. The problem is that
> >>> the destination is behind NAT, and its reply contains a private
> >>> network IP in the SDP.
> >>>
> >>> Normally Asterisk when nat=yes works around that by adjusting the
> >>> destination for RTP to be the address it actually receives audio
> >>> from, however because this device is recvonly Asterisk never receives
> >>> audio from it. This means Asterisk keeps trying to send the
> >>> doorbell's RTP to the private network IP which of course fails, and
> >>> the destination never gets the RTP from the doorbell.
> >>>
> >>> We haven't found a solution in Asterisk to this, so are now looking
> >>> to Kamailio which acts as a load-balancing proxy in front of Asterisk
> >>> for one. For example, maybe we could use fix_nated_sdp, but only on
> >>> 200 OK's with recvonly.
> >>>
> >>> Has anyone else encountered this, and are there any recommended
> >>> solutions?
> >>>
> >>> Thank you in advance!
> >>>
> >>> --
> >>> David Cunningham, Voisonics Limited
> >>> http://voisonics.com/ <http://voisonics.com/>
> >>> USA: +1 213 221 1092
> >>> New Zealand: +64 (0)28 2558 3782
> >>>
> >>> _______________________________________________
> >>> Kamailio (SER) - Users Mailing List
> >>> sr-users(a)lists.kamailio.org
> >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >> _______________________________________________
> >> Kamailio (SER) - Users Mailing List
> >> sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
> >
> > _______________________________________________
> > Kamailio (SER) - Users Mailing List
> > sr-users(a)lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
VoIP Embedded, Inc.
http://www.voipembedded.com