date:20201209

[SR-Users] SLA presence not working proper with (SCA module)

2020-12-09 Thread Aatif Shaikh

Aatif Shaikh 
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:4...@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:4...@test.sip.abcd.com 1 active 1606376289 sip:4...@10.xx.xx.xx
:5070;transport=udp sip:2...@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:4...@sc4test.sip.teledge.com 1 held
# kamcmd sca.all_appearances
sip:4...@test.sip.abcd.com 1 held 1606376516 sip:4...@10.xx.xx.xx
:5070;transport=udp sip:2...@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?
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] NAT problem with recvonly calls

2020-12-09 Thread David Cunningham

Thanks Alex!


On Thu, 10 Dec 2020 at 14:09, Alex Balashov 
wrote:

> if(has_body("application/sdp") && search("a=sendonly")) [1]
>
> It's what comes to mind off the top of my head, anyway.
>
> -- Alex
>
> [1] https://www.kamailio.org/docs/modules/stable/modules/textops.html
>
> On 12/9/20 7:43 PM, David Cunningham wrote:
> > Hi Alex,
> >
> > Thank you for that. Do you offhand know of an easy way to test if the
> > sendonly attribute is set? Presumably we can use
> > sdp_remove_line_by_prefix() to remove it.,
> >
> >
> > On Wed, 9 Dec 2020 at 20:52, Alex Balashov  > > wrote:
> >
> > The salient quality of a reinvite is that has_totag() == true; it is
> > handled in the loose_route() section of your config. You want to do
> the
> > SDP manipulation in the part below that, where initial INVITEs are
> > handled.
> >
> > On 12/9/20 2:47 AM, David Cunningham wrote:
> >  > Hi Daniel,
> >  >
> >  > Removing the sendonly from the INVITE SDP sounds like the most
> > workable
> >  > solution in our case. We'd only want to do it for a new INVITE
> > though,
> >  > not a re-INVITE in a situation where a call is put on hold. Would
> > you be
> >  > able to give an example of such a configuration?
> >  >
> >  > Thanks very much for your help!
> >  >
> >  >
> >  > On Tue, 8 Dec 2020 at 21:56, Daniel-Constantin Mierla
> > mailto:mico...@gmail.com>
> >  > >> wrote:
> >  >
> >  > Hello,
> >  >
> >  > if the endpoint is not behind a port forwarding nat/firewall
> > (when
> >  > one can instruct the rtp relay to use signaling address), then
> >  > probably you can try to remove the sendonly from the INVITE
> SDP.
> >  > That will enable rtp from endpoint to doorbell, which may rise
> >  > additional concerns (e.g., privacy) if its is explicitly not
> > wanted
> >  > to happen. But as Alex said in another response, the only way
> > to get
> >  > it work is to make the endpoint behind nat to send a RTP
> packet.
> >  > Usually the doorbells I encountered so far were accepting
> > incoming
> >  > traffic as well, to discuss/interact with the person ringing
> > on it.
> >  >
> >  > Cheers,
> >  > Daniel
> >  >
> >  > On 08.12.20 05: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/ 
> > >
> >  >> USA: +1 213 221 1092
> >  >> New Zealand: +64 (0)28 2558 3782
> >  >>
> >  >> ___
> >  >> Kamailio (SER) - Users Mailing List
> >  >> sr-users@lists.kamailio.org
> > 
> >  > >
> >  >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> > 
> >  >

Re: [SR-Users] NAT problem with recvonly calls

2020-12-09 Thread Alex Balashov


if(has_body("application/sdp") && search("a=sendonly")) [1]

It's what comes to mind off the top of my head, anyway.

-- Alex

[1] https://www.kamailio.org/docs/modules/stable/modules/textops.html

On 12/9/20 7:43 PM, David Cunningham wrote:

Hi Alex,

Thank you for that. Do you offhand know of an easy way to test if the 
sendonly attribute is set? Presumably we can use 
sdp_remove_line_by_prefix() to remove it.,



On Wed, 9 Dec 2020 at 20:52, Alex Balashov > wrote:


The salient quality of a reinvite is that has_totag() == true; it is
handled in the loose_route() section of your config. You want to do the
SDP manipulation in the part below that, where initial INVITEs are
handled.

On 12/9/20 2:47 AM, David Cunningham wrote:
 > Hi Daniel,
 >
 > Removing the sendonly from the INVITE SDP sounds like the most
workable
 > solution in our case. We'd only want to do it for a new INVITE
though,
 > not a re-INVITE in a situation where a call is put on hold. Would
you be
 > able to give an example of such a configuration?
 >
 > Thanks very much for your help!
 >
 >
 > On Tue, 8 Dec 2020 at 21:56, Daniel-Constantin Mierla
mailto:mico...@gmail.com>
 > >> wrote:
 >
 >     Hello,
 >
 >     if the endpoint is not behind a port forwarding nat/firewall
(when
 >     one can instruct the rtp relay to use signaling address), then
 >     probably you can try to remove the sendonly from the INVITE SDP.
 >     That will enable rtp from endpoint to doorbell, which may rise
 >     additional concerns (e.g., privacy) if its is explicitly not
wanted
 >     to happen. But as Alex said in another response, the only way
to get
 >     it work is to make the endpoint behind nat to send a RTP packet.
 >     Usually the doorbells I encountered so far were accepting
incoming
 >     traffic as well, to discuss/interact with the person ringing
on it.
 >
 >     Cheers,
 >     Daniel
 >
 >     On 08.12.20 05: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/ 
>
 >>     USA: +1 213 221 1092
 >>     New Zealand: +64 (0)28 2558 3782
 >>
 >>     ___
 >>     Kamailio (SER) - Users Mailing List
 >> sr-users@lists.kamailio.org
 
>
 >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
 
>
 >
 >     --
 >     Daniel-Constantin Mierla --www.asipto.com
  >
 > www.twitter.com/miconda  
> 
--www.linkedin.com/in/miconda  
>
 >

Re: [SR-Users] NAT problem with recvonly calls

2020-12-09 Thread David Cunningham

Hi Alex,

Thank you for that. Do you offhand know of an easy way to test if the
sendonly attribute is set? Presumably we can use
sdp_remove_line_by_prefix() to remove it.,


On Wed, 9 Dec 2020 at 20:52, Alex Balashov 
wrote:

> The salient quality of a reinvite is that has_totag() == true; it is
> handled in the loose_route() section of your config. You want to do the
> SDP manipulation in the part below that, where initial INVITEs are handled.
>
> On 12/9/20 2:47 AM, David Cunningham wrote:
> > Hi Daniel,
> >
> > Removing the sendonly from the INVITE SDP sounds like the most workable
> > solution in our case. We'd only want to do it for a new INVITE though,
> > not a re-INVITE in a situation where a call is put on hold. Would you be
> > able to give an example of such a configuration?
> >
> > Thanks very much for your help!
> >
> >
> > On Tue, 8 Dec 2020 at 21:56, Daniel-Constantin Mierla  > > wrote:
> >
> > Hello,
> >
> > if the endpoint is not behind a port forwarding nat/firewall (when
> > one can instruct the rtp relay to use signaling address), then
> > probably you can try to remove the sendonly from the INVITE SDP.
> > That will enable rtp from endpoint to doorbell, which may rise
> > additional concerns (e.g., privacy) if its is explicitly not wanted
> > to happen. But as Alex said in another response, the only way to get
> > it work is to make the endpoint behind nat to send a RTP packet.
> > Usually the doorbells I encountered so far were accepting incoming
> > traffic as well, to discuss/interact with the person ringing on it.
> >
> > Cheers,
> > Daniel
> >
> > On 08.12.20 05: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/ 
> >> USA: +1 213 221 1092
> >> New Zealand: +64 (0)28 2558 3782
> >>
> >> ___
> >> Kamailio (SER) - Users Mailing List
> >> sr-users@lists.kamailio.org  
> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users  <
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> >
> > --
> > Daniel-Constantin Mierla --www.asipto.com  
> > www.twitter.com/miconda    --
> www.linkedin.com/in/miconda  
> > Funding:https://www.paypal.me/dcmierla  <
> https://www.paypal.me/dcmierla>
> >
> >
> >
> > --
> > David Cunningham, Voisonics Limited
> > http://voisonics.com/ 
> > USA: +1 213 221 1092
> > New Zealand: +64 (0)28 2558 3782
> >
> > ___
> > Kamailio (SER) - Users Mailing List
> > sr-users@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@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] NAT problem with recvonly calls

2020-12-09 Thread Ovidiu Sas

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  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  >> > 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/ 
> >>> USA: +1 213 221 1092
> >>> New Zealand: +64 (0)28 2558 3782
> >>>
> >>> ___
> >>> Kamailio (SER) - Users Mailing List
> >>> sr-users@lists.kamailio.org
> >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >> ___
> >> Kamailio (SER) - Users Mailing List
> >> sr-users@lists.kamailio.org 
> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
> >
> > ___
> > Kamailio (SER) - Users Mailing List
> > sr-users@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@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] GitHub discussion

2020-12-09 Thread Daniel-Constantin Mierla

Hello,

personally I prefer to keep the "official" community discussions in a
single place, because can be distracting and unproductive to follow many
places, risking that the main goal of building a knowledge base reduces
its efficiency.

I understand that one medium doesn't match all needs, a reason there is
irc/matrix room, to offer a place for more real time interactions. But I
would not like to use many platforms for the same type of communication.
I know that some people organized "unofficial" discussion channels (on
slack, telegram), that's fine, I am referring to what the project
advertises to be somehow "official" and what is under kamailio github
organization is implicitly in this category.

No matter I am more an email-oriented person than real time IM or
forums, but considering that it's a new feature of github, at this
moment I think makes no sense to go for it. There are probably other
concerns related to it, like ability to migrate the content when/if
wanting to switch to another platform, copyright of the content and the
fact that we enforce the entire community (not only the registered
developers) to make an account and "sign" the agreement with
github/microsoft.

Cheers,
Daniel

On 09.12.20 11:51, Sergey Safarov wrote:
> GitHub release new feature - discussion.
>
> Example
> https://github.com/vercel/vercel/discussions
> 
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] GitHub discussion

2020-12-09 Thread Sergey Safarov

GitHub release new feature - discussion.

Example
https://github.com/vercel/vercel/discussions
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] SLA presence not working proper with (SCA module)

Re: [SR-Users] NAT problem with recvonly calls

Re: [SR-Users] NAT problem with recvonly calls

Re: [SR-Users] NAT problem with recvonly calls

Re: [SR-Users] NAT problem with recvonly calls

Re: [SR-Users] GitHub discussion

[SR-Users] GitHub discussion

7 matches

Site Navigation

Mail list logo

Footer information