Re: [SR-Users] Issue with Socket selection on Forwarding ACK message

2018-02-02 Thread Timmo Verlaan
Upon inspection I think you should set enable_double_rr to value '2'. It
will always add two record route headers. It is a small line in
documentation.

I don't see how loose_route can be fixed if you only have 1 route header.
It won't be compatible with multi homed kamailio.

Kind regards,
Timmo Verlaan

On 3 Feb 2018 00:15, "Emmanuel BUU"  wrote:


Le 2018-02-02 à 23:12, Timmo Verlaan a écrit :

Hi Emmanuel,

I now understand what you're dealing with. No, we always go out over a
different interface so a double header is always present. Although I'd say
that enable_double_rr should always add two route headers. Even if both
route headers are equal.

I don't think this is the correct behavior to add to identical SIP URI in
the route set.


As a workaround you could add the route headers manually using some
kamailio scripting. We did this for a while until we were able to fix loose
route to cover our usecase (it ignored default port).

We will post a ticket and submit a patch to fix loose_route() instead.
Don't want to add some strange cases to out script which is already quite
complex.


Regards,
Timmo

Emmanuel


On 2 Feb 2018 16:50, "Emmanuel BUU"  wrote:

Hi Timmo,

We do have *enable_double_rr* set to 1 but the route set added by the proxy
when record_route() on the INVITE consists in a single route. This is
because Alice and Bob are BOTH registered with the alternate port 5066 on
the same interfacec and using the same protocol (UDP). To us, this seems
logical.
Do you have a double route in your case even though both party are on the
same port, same interface and both UDP? If so, could you send us an exemple
of Route: header?

Emmanuel BUU
IVèS


Le 2018-02-02 à 14:18, Timmo Verlaan a écrit :

Hi Thomas,

We have a similar situation but we use double route headers so the correct
egress socket is chosen. You can enable this by setting a
modparam: enable_double_rr.
Would this be a solution for you?

Kind regards,
Timmo Verlaan

On 2 Feb 2018 13:57, "Thomas Carvello"  wrote:

> Thank you for you answer.
>
> We have tried to change the local port for Bob, but it doesnt change
> anything. And the contact value in 200 OK message has no influence in this
> case.
>
> In fact, we have made a further investigation regarding the socket
> selection *and read the code. *The issue seems to be located in the RR
> module and the loose_route() function.
> In the  after_loose() function in loose.c, the  function
> set_force_socket()  is called only if a DOUBLE route is mentioned in the
> route set of the ACK message
>
> But when both users are using 5066 as proxy port, we get only ONE route
> for the proxy in the route set (and to us it is OK). In this case, we get a
> trace:
>
> "No next URI found"
>
> and the code exits. Later in the message processing, when t_relay() is
> called, the forward_request() selects the first socket defined in our
> configuration instead.
>
> At this point, we can't presume what socket we be select. We believe that
> it is a software bug  and that after_loose() should force the send_socket
> even though we have only one route in the route set. We also checked the
> 5.1 code and there is no change in this module that would alter this
> behavior.
>
> Are we missing something?
>
> Thank you for you time,
> Thomas
>
> Le 26/01/2018 à 15:43, Евгений Голей a écrit :
>
> Hi
>
> Could it be because of Bob happend to use 5060 as local port?
> Yes, the port and the address in the ACK are indicated by what the value
> in Contact was in reply 200 Ok. Look at the message 200 Ok
>
>
> Четверг, 25 января 2018, 13:00 +03:00 от Thomas Carvello
>  :
>
>
> Hello,
>
> i have an issue with my Kamailio 4.1.9 configuration.
>
> This configuration is multi-homed, we have* two network* interfaces, one
> on a private network and on the public Internet. Kamailio is configured to
> listen on port 5060 and 5066 on both interfaces. We register two users
> Alice and Bob on the  public Internet using port 5066.  Both users are
> behind a NAT and we capture the SIP exchange on the proxy server.
>
> We have set the parameter mhomed=1
>
> When Alice calls Bob, we have
>
> Alice Proxy   Bob
>
> src=5063  dst=5066
> INVITE -->
>
> src=5066
> --  INVITE ---> dst=5060
>
> dst=5066
> <--- 200 OK -- src=5060
>
>
> dst=5063
> <--- 200 OK - src=5066
>
> src=5063  dst=5066
>  ACK --->
>
> *src=5060  (blocked by NAT)*
> --  ACK-xdst=5060
>
>
>
> The ACK packet gets relayed with the wrong source port. Then the NAT
> rejects the packet and the call cannot be established.
>
> For some reason, when Bob calls Alice, the 

Re: [SR-Users] Issue with Socket selection on Forwarding ACK message

2018-02-02 Thread Timmo Verlaan
Hi Emmanuel,

I now understand what you're dealing with. No, we always go out over a
different interface so a double header is always present. Although I'd say
that enable_double_rr should always add two route headers. Even if both
route headers are equal.

As a workaround you could add the route headers manually using some
kamailio scripting. We did this for a while until we were able to fix loose
route to cover our usecase (it ignored default port).

Regards,
Timmo

On 2 Feb 2018 16:50, "Emmanuel BUU"  wrote:

Hi Timmo,

We do have *enable_double_rr* set to 1 but the route set added by the proxy
when record_route() on the INVITE consists in a single route. This is
because Alice and Bob are BOTH registered with the alternate port 5066 on
the same interfacec and using the same protocol (UDP). To us, this seems
logical.
Do you have a double route in your case even though both party are on the
same port, same interface and both UDP? If so, could you send us an exemple
of Route: header?

Emmanuel BUU
IVèS


Le 2018-02-02 à 14:18, Timmo Verlaan a écrit :

Hi Thomas,

We have a similar situation but we use double route headers so the correct
egress socket is chosen. You can enable this by setting a
modparam: enable_double_rr.
Would this be a solution for you?

Kind regards,
Timmo Verlaan

On 2 Feb 2018 13:57, "Thomas Carvello"  wrote:

> Thank you for you answer.
>
> We have tried to change the local port for Bob, but it doesnt change
> anything. And the contact value in 200 OK message has no influence in this
> case.
>
> In fact, we have made a further investigation regarding the socket
> selection *and read the code. *The issue seems to be located in the RR
> module and the loose_route() function.
> In the  after_loose() function in loose.c, the  function
> set_force_socket()  is called only if a DOUBLE route is mentioned in the
> route set of the ACK message
>
> But when both users are using 5066 as proxy port, we get only ONE route
> for the proxy in the route set (and to us it is OK). In this case, we get a
> trace:
>
> "No next URI found"
>
> and the code exits. Later in the message processing, when t_relay() is
> called, the forward_request() selects the first socket defined in our
> configuration instead.
>
> At this point, we can't presume what socket we be select. We believe that
> it is a software bug  and that after_loose() should force the send_socket
> even though we have only one route in the route set. We also checked the
> 5.1 code and there is no change in this module that would alter this
> behavior.
>
> Are we missing something?
>
> Thank you for you time,
> Thomas
>
> Le 26/01/2018 à 15:43, Евгений Голей a écrit :
>
> Hi
>
> Could it be because of Bob happend to use 5060 as local port?
> Yes, the port and the address in the ACK are indicated by what the value
> in Contact was in reply 200 Ok. Look at the message 200 Ok
>
>
> Четверг, 25 января 2018, 13:00 +03:00 от Thomas Carvello
>  :
>
>
> Hello,
>
> i have an issue with my Kamailio 4.1.9 configuration.
>
> This configuration is multi-homed, we have* two network* interfaces, one
> on a private network and on the public Internet. Kamailio is configured to
> listen on port 5060 and 5066 on both interfaces. We register two users
> Alice and Bob on the  public Internet using port 5066.  Both users are
> behind a NAT and we capture the SIP exchange on the proxy server.
>
> We have set the parameter mhomed=1
>
> When Alice calls Bob, we have
>
> Alice Proxy   Bob
>
> src=5063  dst=5066
> INVITE -->
>
> src=5066
> --  INVITE ---> dst=5060
>
> dst=5066
> <--- 200 OK -- src=5060
>
>
> dst=5063
> <--- 200 OK - src=5066
>
> src=5063  dst=5066
>  ACK --->
>
> *src=5060  (blocked by NAT)*
> --  ACK-xdst=5060
>
>
>
> The ACK packet gets relayed with the wrong source port. Then the NAT
> rejects the packet and the call cannot be established.
>
> For some reason, when Bob calls Alice, the call is correctly established.
> Could it be because Bob happend to use 5060 as local port?
>
> Also, if we set nhomed=0 it works BUT we are not sure that multi homed is
> handled correctly.
> I was wondering if you have encounter this issue before?
>
> I have investigated the code for selection socket and what is the logic of
> this selection ?
>
>
> *How does kamailo knows that it should choose 5066 as src port if the user
> is registered using port 5066 instead of 5066? *
>
> Thank you for your time.
>
> Thomas
>
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> 

[SR-Users] SDP Rewrite issues

2018-02-02 Thread Steven Meyer
Our topology is:

Client <> Client Router <> Internet <> Firewall (NAT) <> Kamailio <> FS

Unfortunately, when enabling SDP Rewrite: fix_nated_sdp, 0x08, it rewrites 
packets to the firewall external IP, not the client router external IP.

Right now we have to do a local NATed IP on each phone.

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


Re: [SR-Users] Routing based on A and B numbers

2018-02-02 Thread Grant Bagdasarian
Thanks! Will have a look at it.
I did try the LCR module with using the from_uri in the rules table, but the 
result wasn’t what I was expecting. Will play with it around some more, and 
after that try your suggestions!
Much appreciated!

From: sr-users  on behalf of Emmanuel BUU 

Sent: Friday, February 2, 2018 5:34:02 PM
To: sr-users@lists.kamailio.org
Subject: Re: [SR-Users] Routing based on A and B numbers


Really depends on what you want

  *   carrierroute is great for prefix based routing but lacks multiple 
information output
 *   if you want to use carrierroute on A and B, I would use it in cascade 
mode: first carrierroute call on A number, and use the result of the first 
carrierroute ($rd) as context for the second call B number. That is a kind of 
an elegant hack
  *   I would use DIALPLAN for maximum flexibility with regex

Emmanuel

Le 2018-02-02 à 15:00, Grant Bagdasarian a écrit :
Hi,

Which module would be best suited for routing calls based on A and B numbers?
We’re currently using the LCR module, with some additional htables to add this 
functionality, but I was wondering if there is a module which does exactly 
this? Or perhaps a combination of modules?

Regards,

Grant Bagdasarian

Senior Developer

+31765727054

cm.com

[cid:part3.A1478516.A54054AA@ives.fr]





___
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


[SR-Users] Distributed Registrations.

2018-02-02 Thread Володимир Іванець
Hello!

Yesterday I read email conversation "Distributed Presence between Multiple
Kamailios" where it was suggested to use Presence module with new dmq
parameter. So was wondering if someone was thinking about approach to share
registrations between multiple Kamailio servers without using database?

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


Re: [SR-Users] is_audio_on_hold() doesn't support rfc3264

2018-02-02 Thread Ovidiu Sas
According to the code, both rfc2543 and rfc3264 are handled.
Just tested this out with jitsi and it's working fine.
Can you provide a sample of your tests?

Regards,
Ovidiu Sas

On Tue, Oct 24, 2017 at 9:52 AM, Julia Boudniatsky  wrote:
> FYI,
>
> After some tests found, that function "is_audio_on_hold()" (textops)
> supports only rfc 2543,
> where "hold"  is indicated by setting  the "c" destination  addresses for
> the media streams to zero  (0.0.0.0).
> The newest rfc3264, where "hold" is indicated by a=sendonly/inactive, is not
> supported.
> Kamailio version 4.4.6.
>
> Best regards,
> Julia
>
>
> ___
> 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] Routing based on A and B numbers

2018-02-02 Thread Emmanuel BUU

Really depends on what you want

 * carrierroute is great for prefix based routing but lacks multiple
   information output
 o if you want to use carrierroute on A and B, I would use it in
   cascade mode: first carrierroute call on A number, and use the
   result of the first carrierroute ($rd) as context for the second
   call B number. That is a kind of an elegant hack
 * I would use DIALPLAN for maximum flexibility with regex

Emmanuel

Le 2018-02-02 à 15:00, Grant Bagdasarian a écrit :


Hi,

Which module would be best suited for routing calls based on A and B 
numbers?


We’re currently using the LCR module, with some additional htables to 
add this functionality, but I was wondering if there is a module which 
does exactly this? Or perhaps a combination of modules?


Regards,

Grant Bagdasarian

Senior Developer

+31765727054 

cm.com 



___
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


Re: [SR-Users] Issue with Socket selection on Forwarding ACK message

2018-02-02 Thread Emmanuel BUU

Hi Timmo,

We do have *enable_double_rr* set to 1 but the route set added by the 
proxy when record_route() on the INVITE consists in a single route. This 
is because Alice and Bob are BOTH registered with the alternate port 
5066 on the same interfacec and using the same protocol (UDP). To us, 
this seems logical.


Do you have a double route in your case even though both party are on 
the same port, same interface and both UDP? If so, could you send us an 
exemple of Route: header?


Emmanuel BUU
IVèS

Le 2018-02-02 à 14:18, Timmo Verlaan a écrit :

Hi Thomas,

We have a similar situation but we use double route headers so the 
correct egress socket is chosen. You can enable this by setting a 
modparam: enable_double_rr.

Would this be a solution for you?

Kind regards,
Timmo Verlaan

On 2 Feb 2018 13:57, "Thomas Carvello" > wrote:


Thank you for you answer.

We have tried to change the local port for Bob, but it doesnt
change anything. And the contact value in 200 OK message has no
influence in this case.

In fact, we have made a further investigation regarding the socket
selection *and read the code. *The issue seems to be located in
the RR module and the loose_route() function.

In the  after_loose() function in loose.c, the  function
set_force_socket()  is called only if a DOUBLE route is mentioned
in the route set of the ACK message

But when both users are using 5066 as proxy port, we get only ONE
route for the proxy in the route set (and to us it is OK). In this
case, we get a trace:

"No next URI found"

and the code exits. Later in the message processing, when
t_relay() is called, the forward_request() selects the first
socket defined in our configuration instead.

At this point, we can't presume what socket we be select. We
believe that it is a software bug  and that after_loose() should
force the send_socket even though we have only one route in the
route set. We also checked the 5.1 code and there is no change in
this module that would alter this behavior.

Are we missing something?

Thank you for you time,

Thomas

Le 26/01/2018 à 15:43, Евгений Голей a écrit :

Hi

Could it be because of Bob happend to use 5060 as local port?
Yes, the port and the address in the ACK are indicated by what
the value in Contact was in reply 200 Ok. Look at the message 200 Ok


Четверг, 25 января 2018, 13:00 +03:00 от Thomas Carvello
 :


Hello,

i have an issue with my Kamailio 4.1.9 configuration.

This configuration is multi-homed, we have*two network*
interfaces, one on a private network and on the public
Internet. Kamailio is configured to listen on port 5060 and
5066 on both interfaces. We register two users Alice and Bob
on the  public Internet using port 5066.  Both users are
behind a NAT and we capture the SIP exchange on the proxy server.

We have set the parameter mhomed=1

When Alice calls Bob, we have

Alice   Proxy   Bob

src=5063dst=5066
INVITE -->

 src=5066
 --  INVITE ---> dst=5060

 dst=5066
 <--- 200 OK -- src=5060


dst=5063
<--- 200 OK - src=5066

src=5063dst=5066
 ACK --->

 *src=5060 (blocked by NAT)*
 --  ACK-xdst=5060


The ACK packet gets relayed with the wrong source port. Then
the NAT rejects the packet and the call cannot be established.

For some reason, when Bob calls Alice, the call is correctly
established. Could it be because Bob happend to use 5060 as
local port?

Also, if we set nhomed=0 it works BUT we are not sure that
multi homed is handled correctly.

I was wondering if you have encounter this issue before?

I have investigated the code for selection socket and what is
the logic of this selection ?

/*How does kamailo knows that it should choose 5066 as src
port if the user is registered using port 5066 instead of 5066?*
/

Thank you for your time.

Thomas



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




Best
Evgeniy




[SR-Users] Routing based on A and B numbers

2018-02-02 Thread Grant Bagdasarian
Hi,

Which module would be best suited for routing calls based on A and B numbers?
We're currently using the LCR module, with some additional htables to add this 
functionality, but I was wondering if there is a module which does exactly 
this? Or perhaps a combination of modules?

Regards,

Grant Bagdasarian

Senior Developer

+31765727054

cm.com

[cid:image001.png@01D39C36.945A76C0]


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


Re: [SR-Users] Issue with Socket selection on Forwarding ACK message

2018-02-02 Thread Thomas Carvello

Thank you for you answer.

We have tried to change the local port for Bob, but it doesnt change 
anything. And the contact value in 200 OK message has no influence in 
this case.


In fact, we have made a further investigation regarding the socket 
selection *and read the code. *The issue seems to be located in the RR 
module and the loose_route() function.


In the  after_loose() function in loose.c, the  function 
set_force_socket()  is called only if a DOUBLE route is mentioned in the 
route set of the ACK message


But when both users are using 5066 as proxy port, we get only ONE route 
for the proxy in the route set (and to us it is OK). In this case, we 
get a trace:


"No next URI found"

and the code exits. Later in the message processing, when t_relay() is 
called, the forward_request() selects the first socket defined in our 
configuration instead.


At this point, we can't presume what socket we be select. We believe 
that it is a software bug  and that after_loose() should force the 
send_socket even though we have only one route in the route set. We also 
checked the 5.1 code and there is no change in this module that would 
alter this behavior.


Are we missing something?

Thank you for you time,

Thomas

Le 26/01/2018 à 15:43, Евгений Голей a écrit :

Hi

Could it be because of Bob happend to use 5060 as local port?
Yes, the port and the address in the ACK are indicated by what the 
value in Contact was in reply 200 Ok. Look at the message 200 Ok



Четверг, 25 января 2018, 13:00 +03:00 от Thomas Carvello
:


Hello,

i have an issue with my Kamailio 4.1.9 configuration.

This configuration is multi-homed, we have*two network*
interfaces, one on a private network and on the public Internet.
Kamailio is configured to listen on port 5060 and 5066 on both
interfaces. We register two users Alice and Bob on the  public
Internet using port 5066.  Both users are behind a NAT and we
capture the SIP exchange on the proxy server.

We have set the parameter mhomed=1

When Alice calls Bob, we have

Alice   Proxy   Bob

src=5063dst=5066
INVITE -->

 src=5066
 --  INVITE ---> dst=5060

 dst=5066
 <--- 200 OK -- src=5060


dst=5063
<--- 200 OK - src=5066

src=5063dst=5066
 ACK --->

 *src=5060 (blocked by NAT)*
 --  ACK-xdst=5060


The ACK packet gets relayed with the wrong source port. Then the
NAT rejects the packet and the call cannot be established.

For some reason, when Bob calls Alice, the call is correctly
established. Could it be because Bob happend to use 5060 as local
port?

Also, if we set nhomed=0 it works BUT we are not sure that multi
homed is handled correctly.

I was wondering if you have encounter this issue before?

I have investigated the code for selection socket and what is the
logic of this selection ?

/*How does kamailo knows that it should choose 5066 as src port if
the user is registered using port 5066 instead of 5066?*
/

Thank you for your time.

Thomas



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



Best
Evgeniy


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


[SR-Users] Contact Header need update?

2018-02-02 Thread Duarte Rocha
Greetings,

My proxy does some number normalization in order to guarantee E164
numeration. It also verifies for valid Calling Numbers and replaces them if
needed.

In order to this, i'm updating the $fU pseudo-variable. Should i update the
"Contact" Header too? I've made some testing and i can get calls to work
with keeping the Contact intact and changing it to the new number. What is
the most correct approach?

Cheers,

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