Re: [SR-Users] BYE and TCP

[Kjeld Flarup]

Hi Yuriy

Thanks for Your suggestions. I looked at them, and it seems to me that 
they all are supposed to be on the receiving side.
My side is the client side behind NAT, and only does INVITE, I never 
receives INVITES.


The alias concept looks interesting but I doubt that I can convince the 
provider to use is, as the documentation states it to be dangerous.


When looking up the force_tcp_alias I noticed that fix_natted_contact 
was recomended for NAT traversal. I do not know if the provider uses, 
this function. Could that be the cause?



 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 1/12/21 8:59 AM, Yuriy Gorlichenko wrote:
It doesn't matter whet port used by provider when it sent initial 
INVITE to you.


Record-route and Route headers are Proxy headers. They are announce 
addresses of the proxy for the listening. That means when UA sends the 
request it has to use port mentioned in the first of the Route headers 
or in the Request URI header.
That means that your kamailio has to create new connection to this 
host port pair or reuse it if it already exists to reach provider's 
server. So there is nothing bad if you will create new connection for 
BYE to port 7071.


However, If provider initiated INVITE to you and sent it from the 
different port ( which is true because for that transaction provider 
has to behave atleast as TCP client ) and connection still alive ( 
socket still exists ) - you can try to use $du variable and put here 
existing address used for the connection to provider.

But remember it is a hack.

This is also can be achieved via as mentioned above global param

tcp_accept_aliases =yes

And functions wich has to be called on initial invite:
tcp_keepalive_enable
force_tcp_alias

On Tue, 12 Jan 2021, 07:15 Kjeld Flarup, <mailto:kjeld.fla...@liberalismen.dk>> wrote:


Hi Daniel

The Record route in the INVITE from 194.247.61.26 sets this pair

Record-Route:


Record-Route:


The Bye requests this route

Route:


Route:


But the real port on 194.255.22.44 is 36059

It is my invite to 194.247.61.26 that sets the 7071 port, which
automatically comes from the listen statement.
I suspect that it might work if the invite was using 36059, but
how can I know this port, if the NAT router decides to map it to
another port.


What is the correct behaviour. Should my Kamailio somehow set the
correct port?

Should the providers Kamailio rewrite the route information?

Or something else?



 Med Liberalistiske Hilsner --
Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
Den ikke akademiske hjemmeside for liberalismen -www.liberalismen.dk  
<http://www.liberalismen.dk>

On 1/11/21 10:18 AM, Daniel-Constantin Mierla wrote:


The From/To/Call-ID are not used to match the connection. The
connection is matched based on target IP and port. For BYE, these
are taken from Route header, if there is one for next hop,
otherwise it is the request URI. Check these two to see if
something is not as expected. Otherwise, you have to discuss with
the provider and see the reason it returns back the 477 response.

Cheers,
Daniel

On 08.01.21 20:36, Kjeld Flarup wrote:


Happy New Year everyone.


I haven't solved this problem yet. Although is it not critical,
it is a bit annoying.

I have tried to simplify things, and have a reference setup that
works.
My linphone sends a TCP call and my Asterisk answers, plays a
speak and hangs up.


If I instead sends the call to my PBX, which handles the
authentication via UAC, it fails with this error, which the
customer site also generated.

Status-Line: SIP/2.0 477 Unfortunately error on sending to
next hop occurred (477/SL)

Unfortunately the error is not generated by my Kamailio, but by
a Kamailio at the provider, when it gets a Bye forwarded via
their SBC.


I have attached a capture which the provider send me. This is
the setup

linphone -> My Kamailio PBX (194.255.22.44:36089
<http://194.255.22.44:36089>) -> provider
Kamailio(194.247.61.26) -> SBC(194.247.61.32) -> provider
Kamailio(194.247.61.26) -> my Asterisk (194.255.22.44:45075
<http://194.255.22.44:45075>)

A note on the providers Kamailio. It listens on both port 5060
and 5070, and both UDP/TCP.
It is also used as access point for both my PBX and my Asterisk,
thus the trace may be a little confusing to read.

As far as I can see, the provider Kamailio gets the

Re: [SR-Users] BYE and TCP

[Kjeld Flarup]

Hi Daniel

The Record route in the INVITE from 194.247.61.26 sets this pair

Record-Route: 

Record-Route: 



The Bye requests this route

Route: 


Route: 

But the real port on 194.255.22.44 is 36059

It is my invite to 194.247.61.26 that sets the 7071 port, which 
automatically comes from the listen statement.
I suspect that it might work if the invite was using 36059, but how can 
I know this port, if the NAT router decides to map it to another port.



What is the correct behaviour. Should my Kamailio somehow set the 
correct port?


Should the providers Kamailio rewrite the route information?

Or something else?



 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 1/11/21 10:18 AM, Daniel-Constantin Mierla wrote:


The From/To/Call-ID are not used to match the connection. The 
connection is matched based on target IP and port. For BYE, these are 
taken from Route header, if there is one for next hop, otherwise it is 
the request URI. Check these two to see if something is not as 
expected. Otherwise, you have to discuss with the provider and see the 
reason it returns back the 477 response.


Cheers,
Daniel

On 08.01.21 20:36, Kjeld Flarup wrote:


Happy New Year everyone.


I haven't solved this problem yet. Although is it not critical, it is 
a bit annoying.


I have tried to simplify things, and have a reference setup that works.
My linphone sends a TCP call and my Asterisk answers, plays a speak 
and hangs up.



If I instead sends the call to my PBX, which handles the 
authentication via UAC, it fails with this error, which the customer 
site also generated.


Status-Line: SIP/2.0 477 Unfortunately error on sending to next
hop occurred (477/SL)

Unfortunately the error is not generated by my Kamailio, but by a 
Kamailio at the provider, when it gets a Bye forwarded via their SBC.



I have attached a capture which the provider send me. This is the setup

linphone -> My Kamailio PBX (194.255.22.44:36089) -> provider
Kamailio(194.247.61.26) -> SBC(194.247.61.32) -> provider
Kamailio(194.247.61.26) -> my Asterisk (194.255.22.44:45075)

A note on the providers Kamailio. It listens on both port 5060 and 
5070, and both UDP/TCP.
It is also used as access point for both my PBX and my Asterisk, thus 
the trace may be a little confusing to read.


As far as I can see, the provider Kamailio gets the correct To/From 
and CallID in the bye. Thus it should be able to match the TCP 
connection.

The flow is also clean, there is no change of ports etc.



I have this reference setup which works

linphone -> provider Kamailio -> SBC -> provider Kamailio -> my
Asterisk

The only differences towards the reference I can see these. I do not 
have a capture from the provider on this.


  * There is an extra Via step.
  * Contact points to the Linphone IP, not the Kamailio IP

Any hint will be appreciated.



 Med Liberalistiske Hilsner ------
Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
Den ikke akademiske hjemmeside for liberalismen -www.liberalismen.dk
On 11/9/20 12:06 PM, Daniel-Constantin Mierla wrote:


Hello,

there is no association between a SIP call and a TCP connection. SIP 
is not designed on TCP streams, the forwarding is based on the 
headers. It doesn't matter if there are messages belonging to same 
call or not, they can share same connection, or can open a new one...


The BYE from caller gets to 194.247.61.32:5040, which cannot deliver 
it further based on Route header. The system at 194.247.61.26:5070 
must be able to accept connections on advertised port of the Route 
address. Again, connection interruption can happen from various 
cases, it cannot rely on ephemeral ports, but on what the SIP system 
advertises as "listen" address.


One can play with tcp port aliases, look at Kamailio core cookbook, 
in case 194.247.61.32:5040 can do that. But that is not the proper 
way for server to server communication, there will be cases when the 
connection will be cut for various reasons (can be also the IP 
routes in the path that get congested).


Otherwise, you can follow the code of tcp_send() function in the 
tcp_main.c from core to see how tcp connection is matched, there are 
various cases there, also a matter of the config parameters.


Cheers,
Daniel

On 09.11.20 10:13, Kjeld Flarup wrote:

Hello

I have attached a pcap received from the provider.

It is quite informative as it shows bits of how they forward the call.

We send to 194.247.61.26 which is a Kamailio proxy, that forwards 
the call to a SBC  194.247.61.32


My guess is that the  194.247.61.26 kamailio gets confused, and 
does n

Re: [SR-Users] BYE and TCP

[Kjeld Flarup]

Happy New Year everyone.


I haven't solved this problem yet. Although is it not critical, it is a 
bit annoying.


I have tried to simplify things, and have a reference setup that works.
My linphone sends a TCP call and my Asterisk answers, plays a speak and 
hangs up.



If I instead sends the call to my PBX, which handles the authentication 
via UAC, it fails with this error, which the customer site also generated.


   Status-Line: SIP/2.0 477 Unfortunately error on sending to next hop
   occurred (477/SL)

Unfortunately the error is not generated by my Kamailio, but by a 
Kamailio at the provider, when it gets a Bye forwarded via their SBC.



I have attached a capture which the provider send me. This is the setup

   linphone -> My Kamailio PBX (194.255.22.44:36089) -> provider
   Kamailio(194.247.61.26) -> SBC(194.247.61.32) -> provider
   Kamailio(194.247.61.26) -> my Asterisk (194.255.22.44:45075)

A note on the providers Kamailio. It listens on both port 5060 and 5070, 
and both UDP/TCP.
It is also used as access point for both my PBX and my Asterisk, thus 
the trace may be a little confusing to read.


As far as I can see, the provider Kamailio gets the correct To/From and 
CallID in the bye. Thus it should be able to match the TCP connection.

The flow is also clean, there is no change of ports etc.



I have this reference setup which works

   linphone -> provider Kamailio -> SBC -> provider Kamailio -> my Asterisk

The only differences towards the reference I can see these. I do not 
have a capture from the provider on this.


 * There is an extra Via step.
 * Contact points to the Linphone IP, not the Kamailio IP

Any hint will be appreciated.



 Med Liberalistiske Hilsner ------
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen -www.liberalismen.dk

On 11/9/20 12:06 PM, Daniel-Constantin Mierla wrote:


Hello,

there is no association between a SIP call and a TCP connection. SIP 
is not designed on TCP streams, the forwarding is based on the 
headers. It doesn't matter if there are messages belonging to same 
call or not, they can share same connection, or can open a new one...


The BYE from caller gets to 194.247.61.32:5040, which cannot deliver 
it further based on Route header. The system at 194.247.61.26:5070 
must be able to accept connections on advertised port of the Route 
address. Again, connection interruption can happen from various cases, 
it cannot rely on ephemeral ports, but on what the SIP system 
advertises as "listen" address.


One can play with tcp port aliases, look at Kamailio core cookbook, in 
case 194.247.61.32:5040 can do that. But that is not the proper way 
for server to server communication, there will be cases when the 
connection will be cut for various reasons (can be also the IP routes 
in the path that get congested).


Otherwise, you can follow the code of tcp_send() function in the 
tcp_main.c from core to see how tcp connection is matched, there are 
various cases there, also a matter of the config parameters.


Cheers,
Daniel

On 09.11.20 10:13, Kjeld Flarup wrote:

Hello

I have attached a pcap received from the provider.

It is quite informative as it shows bits of how they forward the call.

We send to 194.247.61.26 which is a Kamailio proxy, that forwards the 
call to a SBC  194.247.61.32


My guess is that the  194.247.61.26 kamailio gets confused, and does 
not match the BYE with the ongoing TCP session.
Instead it sees it as a new session, and forwards it according to the 
route information.


Can anybody help explaining what fields Kamailio uses to match an 
ongoing TCP session.


  Regards Kjeld

Den fre. 6. nov. 2020 kl. 10.50 skrev Daniel-Constantin Mierla 
mailto:mico...@gmail.com>>:


Hello,

from SIP specs point of view, can be any port -- ACK and BYE do
not have to follow same path as INVITE, so they can even come
from a different IP.

Then, the call can be closed after 30secs because also the ACK
has the same problems with the header as the BYE. Your pcap
didn't include all the traffic, you have to capture both
directions on your kamailio server to see what happens on each side.

Cheers,
Daniel


On 06.11.20 10:35, Kjeld Flarup wrote:

Hi Daniel

The Unknown Dialog comes because the server hang up the call 30
seconds earlier. We never gets these BYE messages, thus the door
phone hangs times out and hangs up.

My question is still, which port is the BYE from the server
supposed to be sent to?

The original 37148
The new 37150
or the advertised 5071

Regards Kjeld

Den fre. 6. nov. 2020 kl. 10.18 skrev Daniel-Constantin Mierla
mailto:mico...@gmail.com>>:

Hello,

I think you hunt a mirage problem here by looking at t

Re: [SR-Users] BYE and TCP

[Kjeld Flarup]

Hello

I have attached a pcap received from the provider.

It is quite informative as it shows bits of how they forward the call.

We send to 194.247.61.26 which is a Kamailio proxy, that forwards the call
to a SBC  194.247.61.32

My guess is that the  194.247.61.26 kamailio gets confused, and does not
match the BYE with the ongoing TCP session.
Instead it sees it as a new session, and forwards it according to the route
information.

Can anybody help explaining what fields Kamailio uses to match an ongoing
TCP session.

  Regards Kjeld

Den fre. 6. nov. 2020 kl. 10.50 skrev Daniel-Constantin Mierla <
mico...@gmail.com>:

> Hello,
>
> from SIP specs point of view, can be any port -- ACK and BYE do not have
> to follow same path as INVITE, so they can even come from a different IP.
>
> Then, the call can be closed after 30secs because also the ACK has the
> same problems with the header as the BYE. Your pcap didn't include all the
> traffic, you have to capture both directions on your kamailio server to see
> what happens on each side.
>
> Cheers,
> Daniel
>
>
> On 06.11.20 10:35, Kjeld Flarup wrote:
>
> Hi Daniel
>
> The Unknown Dialog comes because the server hang up the call 30 seconds
> earlier. We never gets these BYE messages, thus the door phone hangs times
> out and hangs up.
>
> My question is still, which port is the BYE from the server supposed to be
> sent to?
>
> The original 37148
> The new 37150
> or the advertised 5071
>
> Regards Kjeld
>
> Den fre. 6. nov. 2020 kl. 10.18 skrev Daniel-Constantin Mierla <
> mico...@gmail.com>:
>
>> Hello,
>>
>> I think you hunt a mirage problem here by looking at the ports of tcp
>> connections, if you think that being different ports is the cause of BYE
>> failure. The ACK fpr 200ok is independent of the INVITE transaction and can
>> have a completely different path than INVITE, thus is completely valid to
>> use another connection. Of course, if follows the same path as INVITE, if
>> the connection is still open, it should be reused. But is a matter of
>> matching, it can be that the INVITE uses different destination identifiers
>> or the connection gets cut from different reasons. But the point is that
>> even if there is a different connection, it should work.
>>
>> So, I actually looked at the pcap capture you sent in one of your
>> previous emails and the BYE is sent out, but gets back:
>>
>> SIP/2.0 481 Unknown Dialog.
>>
>> Therefore it gets to the end point, which doesn't match it with any of
>> its active calls. Looking at the headers, the 200ok/INVITE has:
>>
>> From: "Front Door" 
>> ;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
>> To: ;tag=12003375157297.
>> Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
>>
>> And the BYE:
>>
>> From: "Front Door" 
>> ;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
>> To:
>> sip:195.249.145.198:5060;transport=udp;line=sr-z-yMngm27FwI73qx0CQo6gm2n3ao03LMn5UILt2NziWIO3ooTDc*;tag=12003375157297
>> .
>> Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
>>
>> While the dialog should be matched on call-id, from/to-tags, the From/To
>> URI should be the same to be strict conformant with RFC3261 (that mandates
>> unchanged From/To for backward compatibility with RFC2543). Likely you do
>> some From/To header changes that are not done correctly to update/restore
>> the values for traffic within dialog.
>>
>> Cheers,
>> Daniel
>> On 06.11.20 09:31, Kjeld Flarup wrote:
>>
>> Thanks Juha
>>
>> That makes it somehow easier to understand my capture. My Kamailio must
>> then have detected a broken TCP connection, though I cannot see why in the
>> capture, neither in the log, but I only run on debug level 2.
>> It receives a 200 OK on port 37148, and then establishes 37150 to reply
>> with an ACK.
>>
>> However two seconds before receiving the 200 OK, there are some spurious
>> retransmissions and out of order on 37148. Perhaps this has caused Kamailio
>> to deem the connection bad, but it still receives data on it.
>> Now I assume that the providers server (Which also is flying Kamailio)
>> should detect the new port, and continue using that. I got a trace from the
>> provider, where there is no disturbance. Thus the server thinks that the
>> connection is OK.
>>
>> Now my next question is, what makes a Kamailio detect this change?
>> Is it a problem that I only rewrite To and From in the INVITE, thus the
>> ACK contains some other values.
>>
>>
>> It is also a bit strange that I get this error exactly

Re: [SR-Users] BYE and TCP

[Kjeld Flarup]

Hi Daniel

The Unknown Dialog comes because the server hang up the call 30 seconds
earlier. We never gets these BYE messages, thus the door phone hangs times
out and hangs up.

My question is still, which port is the BYE from the server supposed to be
sent to?

The original 37148
The new 37150
or the advertised 5071

Regards Kjeld

Den fre. 6. nov. 2020 kl. 10.18 skrev Daniel-Constantin Mierla <
mico...@gmail.com>:

> Hello,
>
> I think you hunt a mirage problem here by looking at the ports of tcp
> connections, if you think that being different ports is the cause of BYE
> failure. The ACK fpr 200ok is independent of the INVITE transaction and can
> have a completely different path than INVITE, thus is completely valid to
> use another connection. Of course, if follows the same path as INVITE, if
> the connection is still open, it should be reused. But is a matter of
> matching, it can be that the INVITE uses different destination identifiers
> or the connection gets cut from different reasons. But the point is that
> even if there is a different connection, it should work.
>
> So, I actually looked at the pcap capture you sent in one of your previous
> emails and the BYE is sent out, but gets back:
>
> SIP/2.0 481 Unknown Dialog.
>
> Therefore it gets to the end point, which doesn't match it with any of its
> active calls. Looking at the headers, the 200ok/INVITE has:
>
> From: "Front Door" 
> ;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
> To: ;tag=12003375157297.
> Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
>
> And the BYE:
>
> From: "Front Door" 
> ;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
> To:
> sip:195.249.145.198:5060;transport=udp;line=sr-z-yMngm27FwI73qx0CQo6gm2n3ao03LMn5UILt2NziWIO3ooTDc*;tag=12003375157297
> .
> Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
>
> While the dialog should be matched on call-id, from/to-tags, the From/To
> URI should be the same to be strict conformant with RFC3261 (that mandates
> unchanged From/To for backward compatibility with RFC2543). Likely you do
> some From/To header changes that are not done correctly to update/restore
> the values for traffic within dialog.
>
> Cheers,
> Daniel
> On 06.11.20 09:31, Kjeld Flarup wrote:
>
> Thanks Juha
>
> That makes it somehow easier to understand my capture. My Kamailio must
> then have detected a broken TCP connection, though I cannot see why in the
> capture, neither in the log, but I only run on debug level 2.
> It receives a 200 OK on port 37148, and then establishes 37150 to reply
> with an ACK.
>
> However two seconds before receiving the 200 OK, there are some spurious
> retransmissions and out of order on 37148. Perhaps this has caused Kamailio
> to deem the connection bad, but it still receives data on it.
> Now I assume that the providers server (Which also is flying Kamailio)
> should detect the new port, and continue using that. I got a trace from the
> provider, where there is no disturbance. Thus the server thinks that the
> connection is OK.
>
> Now my next question is, what makes a Kamailio detect this change?
> Is it a problem that I only rewrite To and From in the INVITE, thus the
> ACK contains some other values.
>
>
> It is also a bit strange that I get this error exactly, the same place in
> the conversation every time I make a call. Somehow I suspect some NAT
> timeout in the router. (it is not carrier grade NAT).
> Can I do anything to prevent a NAT timeout from the client side?
>
>
> Another thing. I assume that sending my internal port in the From field,
> or any kind of advertising, should be ignored by the server.
>
> Regards Kjeld
>
>
>
> Den fre. 6. nov. 2020 kl. 07.45 skrev Juha Heinanen :
>
>> Kjeld Flarup writes:
>>
>> > How is TCP SIP actually supposed to handle a BYE, when the client is
>> > behind NAT.
>>
>> Client behind NAT is supposed to keep its TCP connection to SIP Proxy
>> alive and use it for all requests of the call.  If the connection breaks
>> for some reason, the client sets up a new one for the remaining
>> requests.
>>
>> -- Juha
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
> --
>
> - Med Liberalistiske Hilsner --
>
>Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
>Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
>Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
>
>
> ________

Re: [SR-Users] BYE and TCP

[Kjeld Flarup]

Thanks Juha

That makes it somehow easier to understand my capture. My Kamailio must
then have detected a broken TCP connection, though I cannot see why in the
capture, neither in the log, but I only run on debug level 2.
It receives a 200 OK on port 37148, and then establishes 37150 to reply
with an ACK.

However two seconds before receiving the 200 OK, there are some spurious
retransmissions and out of order on 37148. Perhaps this has caused Kamailio
to deem the connection bad, but it still receives data on it.
Now I assume that the providers server (Which also is flying Kamailio)
should detect the new port, and continue using that. I got a trace from the
provider, where there is no disturbance. Thus the server thinks that the
connection is OK.

Now my next question is, what makes a Kamailio detect this change?
Is it a problem that I only rewrite To and From in the INVITE, thus the ACK
contains some other values.


It is also a bit strange that I get this error exactly, the same place in
the conversation every time I make a call. Somehow I suspect some NAT
timeout in the router. (it is not carrier grade NAT).
Can I do anything to prevent a NAT timeout from the client side?


Another thing. I assume that sending my internal port in the From field, or
any kind of advertising, should be ignored by the server.

Regards Kjeld



Den fre. 6. nov. 2020 kl. 07.45 skrev Juha Heinanen :

> Kjeld Flarup writes:
>
> > How is TCP SIP actually supposed to handle a BYE, when the client is
> > behind NAT.
>
> Client behind NAT is supposed to keep its TCP connection to SIP Proxy
> alive and use it for all requests of the call.  If the connection breaks
> for some reason, the client sets up a new one for the remaining
> requests.
>
> -- Juha
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 

- Med Liberalistiske Hilsner --

   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] BYE and TCP

[Kjeld Flarup]

Hello

I got an answer from the VOIP provider.

They claim that we have an error in our port forwarding. Because we 
advertise 5071, but traffic comes from another port.


As I understand, it is however impossible for TCP to send all traffic 
from just one port.


How is TCP SIP actually supposed to handle a BYE, when the client is 
behind NAT.


 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 11/4/20 10:00 PM, Kjeld Flarup wrote:


Hello again

I have attached a Capture.

My public IP is 194.255.22.44, and I have a port forward of 5071 in my 
router


The Raspberry Pi running the Kamailio is on 192.168.2.9 with an alias 
192.168.2.40


My listening is setup like this

listen=127.0.0.1:5071
listen=eth0:5071  advertise 194.255.22.44:5071
alias=194.255.22.44:5071

Kamailio is forwarding an invite from a door phone thus I also rewrite 
FROM:


uac_replace_from("sip:"+$dbr(ra=>[0,1])+"@194.255.22.44:5071");
And the failure route to
$fu = "sip:"+$dbr(ra=>[0,0])+"@194.255.22.44:5071";

In the route doing the INVITE I also set this:

set_advertised_address("194.255.22.44:5071");


Regarding tcp_reuse_port, if I set this I get this error, which I 
understand is due to the way TCP works.


Nov  4 18:38:41 scantronpbx /usr/sbin/kamailio[15864]: {1 ACK 16191 
ACK C2Az-Xm2b0CEPyV5eQuz7yEf9IJo4PyJ} WARNING:  
[core/tcp_main.c:1061]: tcp_do_connect(): binding to source address 
192.168.2.40:5071 failed: Address already in use [98]


I do have tcp_reuse_port=yes with this capture. But much to my 
surprise, the 200 OK from is send to 37148, but the ACK to it comes 
from 37150



 Med Liberalistiske Hilsner --
Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
Den ikke akademiske hjemmeside for liberalismen -www.liberalismen.dk
On 11/4/20 1:59 PM, Carsten Bock wrote:

Hi,

I think you are searching for this parameter:

http://www.kamailio.org/wiki/cookbooks/devel/core#tcp_reuse_port

It basically tells the kernel not to choose a new port at random for 
a new connection, but it will try to reuse the existing port (in your 
case 5071).


Thanks,
Carsten


--
Carsten Bock I CTO & Founder

ng-voice GmbH

Trostbrücke 1 I 20457 Hamburg I Germany
T +49 40 524 75 93-40 | M +49 179 2021244 I www.ng-voice.com 
<http://www.ng-voice.com/>


Registry Office at Local Court Hamburg, HRB 120189
Managing Directors: Dr. David Bachmann, Carsten Bock



Am Mi., 4. Nov. 2020 um 12:07 Uhr schrieb Kjeld Flarup 
mailto:kjeld.fla...@liberalismen.dk>>:


Hello

I have a Kamailio running behind NAT, which sends calls to a VOIP
service provider.

I have setup the Kamalio to listen on port 5071, and also setup a
port
forward in the router.

Now the problem is that with TCP, 5071 is not used for the
dialog, but a
new port is chosen everytime. This means that when the mobile phone
called hands up, I never sees the BYE, because BYE is a new dialog.


To which port is the server supposed to send the BYE, and what field
tells the server this.


-- 
 Med Liberalistiske Hilsner

--
    Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min
tegnebog
    Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
    Den ikke akademiske hjemmeside for liberalismen -
www.liberalismen.dk <http://www.liberalismen.dk>


___
Kamailio (SER) - Users Mailing List
sr-users@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@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] BYE and TCP

[Kjeld Flarup]

Hello again

I have attached a Capture.

My public IP is 194.255.22.44, and I have a port forward of 5071 in my 
router


The Raspberry Pi running the Kamailio is on 192.168.2.9 with an alias 
192.168.2.40


My listening is setup like this

listen=127.0.0.1:5071
listen=eth0:5071  advertise 194.255.22.44:5071
alias=194.255.22.44:5071

Kamailio is forwarding an invite from a door phone thus I also rewrite FROM:

uac_replace_from("sip:"+$dbr(ra=>[0,1])+"@194.255.22.44:5071");
And the failure route to
$fu = "sip:"+$dbr(ra=>[0,0])+"@194.255.22.44:5071";

In the route doing the INVITE I also set this:

set_advertised_address("194.255.22.44:5071");


Regarding tcp_reuse_port, if I set this I get this error, which I 
understand is due to the way TCP works.


Nov  4 18:38:41 scantronpbx /usr/sbin/kamailio[15864]: {1 ACK 16191 ACK 
C2Az-Xm2b0CEPyV5eQuz7yEf9IJo4PyJ} WARNING:  
[core/tcp_main.c:1061]: tcp_do_connect(): binding to source address 
192.168.2.40:5071 failed: Address already in use [98]


I do have tcp_reuse_port=yes with this capture. But much to my surprise, 
the 200 OK from is send to 37148, but the ACK to it comes from 37150



 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 11/4/20 1:59 PM, Carsten Bock wrote:

Hi,

I think you are searching for this parameter:

http://www.kamailio.org/wiki/cookbooks/devel/core#tcp_reuse_port

It basically tells the kernel not to choose a new port at random for a 
new connection, but it will try to reuse the existing port (in your 
case 5071).


Thanks,
Carsten


--
Carsten Bock I CTO & Founder

ng-voice GmbH

Trostbrücke 1 I 20457 Hamburg I Germany
T +49 40 524 75 93-40 | M +49 179 2021244 I www.ng-voice.com 
<http://www.ng-voice.com/>


Registry Office at Local Court Hamburg, HRB 120189
Managing Directors: Dr. David Bachmann, Carsten Bock



Am Mi., 4. Nov. 2020 um 12:07 Uhr schrieb Kjeld Flarup 
mailto:kjeld.fla...@liberalismen.dk>>:


Hello

I have a Kamailio running behind NAT, which sends calls to a VOIP
service provider.

I have setup the Kamalio to listen on port 5071, and also setup a
port
forward in the router.

Now the problem is that with TCP, 5071 is not used for the dialog,
but a
new port is chosen everytime. This means that when the mobile phone
called hands up, I never sees the BYE, because BYE is a new dialog.


To which port is the server supposed to send the BYE, and what field
tells the server this.


-- 
 Med Liberalistiske Hilsner --

    Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min
tegnebog
    Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
    Den ikke akademiske hjemmeside for liberalismen -
www.liberalismen.dk <http://www.liberalismen.dk>


___
Kamailio (SER) - Users Mailing List
sr-users@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@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


tcpbye.cap
Description: application/vnd.tcpdump.pcap
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] BYE and TCP

[Kjeld Flarup]

Hello

I have a Kamailio running behind NAT, which sends calls to a VOIP 
service provider.


I have setup the Kamalio to listen on port 5071, and also setup a port 
forward in the router.


Now the problem is that with TCP, 5071 is not used for the dialog, but a 
new port is chosen everytime. This means that when the mobile phone 
called hands up, I never sees the BYE, because BYE is a new dialog.



To which port is the server supposed to send the BYE, and what field 
tells the server this.



--
 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk


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

Re: [SR-Users] Mysql lastinsertid

[Kjeld Flarup]

Hi Daniel

I can do that, but am I guaranteed, that the right value is returned?

Kamailio is multithreaded, and I do now know if the mysql connection is 
shared across threads.


 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 8/12/20 12:25 PM, Daniel-Constantin Mierla wrote:


Have you tried to do "SELECT LAST_INSERT_ID()" with sql_query() from 
sqlops module?


Cheers, Daniel

On 12.08.20 11:24, Kjeld Flarup wrote:

In the configuration file.

  Kjeld

Den ons. 12. aug. 2020 kl. 11.14 skrev Daniel-Constantin Mierla 
mailto:mico...@gmail.com>>:


Hello,

do you need it in the configuration file, or inside C code?

Cheers,
Daniel

On 12.08.20 00:09, Kjeld Flarup wrote:
> Hello
>
> I wonder if there is some way to get the lastinsertid from an
"INSERT
> INTO" sql_query
>
> --
>  Med Liberalistiske Hilsner
------
>    Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min
tegnebog
>    Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
>    Den ikke akademiske hjemmeside for liberalismen -
www.liberalismen.dk <http://www.liberalismen.dk>
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>

www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Funding: https://www.paypal.me/dcmierla



--

- Med Liberalistiske Hilsner --

Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
Den ikke akademiske hjemmeside for liberalismen -www.liberalismen.dk  
<http://www.liberalismen.dk>


___
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

Re: [SR-Users] Mysql lastinsertid

[Kjeld Flarup]

In the configuration file.

  Kjeld

Den ons. 12. aug. 2020 kl. 11.14 skrev Daniel-Constantin Mierla <
mico...@gmail.com>:

> Hello,
>
> do you need it in the configuration file, or inside C code?
>
> Cheers,
> Daniel
>
> On 12.08.20 00:09, Kjeld Flarup wrote:
> > Hello
> >
> > I wonder if there is some way to get the lastinsertid from an "INSERT
> > INTO" sql_query
> >
> > --
> > -------- Med Liberalistiske Hilsner --
> >Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
> >Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
> >Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
> >
> >
> > ___
> > 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
>
>

-- 

- Med Liberalistiske Hilsner --

   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Mysql lastinsertid

[Kjeld Flarup]

Hello

I wonder if there is some way to get the lastinsertid from an "INSERT 
INTO" sql_query


--
 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk


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

Re: [SR-Users] Bad request when INVITE relayed to another kamailio

[Kjeld Flarup]

Is it possible to get a log, sip trace or even a capture for wireshark 
out of the phone?


That may reveal more about what had happened.


 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 1/25/20 8:20 AM, Alex Balashov wrote:

Hi Zhan,

At first glance, it does not appear that anything about the second
request is grammatically invalid.

I suspect the problem you are encountering is UDP fragmentation, as
explained in my blog post here:

http://www.evaristesys.com/blog/sip-udp-fragmentation-and-kamailio-the-sip-header-diet/

The size of the second INVITE you pasted is 1198 bytes. Add 463 bytes of
encapsulated SDP body (Content-Length header), and it's 1661 bytes -
over the UDP fragmentation threshold of ~1480 based on an MTU of 1500
bytes.

This is due to the additional "contributions" of the second Kamailio -
extra Via and Record-Route headers. Removing these extras probably puts
the message length at just under the fragmentation threshold.

Because the receiver does not get a fully reassembled UDP datagram, the
message arrives partly formed (first UDP fragment is the only one
received), the Polycom's SIP stack is confused.

-- Alex

On Fri, Jan 24, 2020 at 10:34:21AM -0700, Zhan Bazarov wrote:


We have Kamailio-cluster via route53(round-robin) some-domain.net

we have two kamailio with public IP's

phone1 is registered on kam1
phone2 is registered on kam2

when we are calling from phone1 to phone2 callflow looks:

phone1 => kam1 => asterisk => kam1 => t_relay(address of second
kamailio:5078) => kam2 => phone2

it works perfectly, but in case when we are using polycom as phone2 - we are
getting 404 response from polycom...


*Invite from second kamailio
*
2020/01/20 10:31:21.799327 10.199.240.19:5078 -> 37.17.41.5:49811
INVITE sip:jyu3xsfkrz6c5qn@10.3.0.116;transport=tcp SIP/2.0
Record-Route:

Record-Route: 
Record-Route: 
Via: SIP/2.0/TCP
some-domain.net:5078;branch=z9hG4bK9ca3.93c2345f3eb1d4b0e1244e722a9bfb6e.0
Via: SIP/2.0/UDP
some-domain.net:5078;rport=5078;received=10.199.240.135;branch=z9hG4bK9ca3.89b66f1dd6e86a5922180b8ed8475072.0
Via: SIP/2.0/UDP
10.199.240.179:7060;received=10.199.240.179;rport=7060;branch=z9hG4bKPj269365e0-798d-404b-bb77-2ad78472905c
From: "Penny"
;tag=ba402508-a640-409f-ba30-dffdfe499f43
To: 
Contact: 
Call-ID: c3a406ca-9ac7-423d-9697-06d0603f48d5
CSeq: 22619 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE,
CANCEL, UPDATE, MESSAGE, REFER
Supported: timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
P-Asserted-Identity: "Penny" 
Max-Forwards: 68
User-Agent: Awesome Calling Platform 3.0
Content-Type: application/sdp
Content-Length:  463


*Response from POLYCOM
*
2020/01/20 10:31:22.054766 37.17.41.5:49811 -> 10.199.240.19:5078
SIP/2.0 400 Bad Request
Via: SIP/2.0/TCP
some-domain.net:5078;branch=z9hG4bK9ca3.93c2345f3eb1d4b0e1244e722a9bfb6e.0
Via: SIP/2.0/UDP
some-domain.net:5078;rport=5078;received=10.199.240.135;branch=z9hG4bK9ca3.89b66f1dd6e86a5922180b8ed8475072.0
Via: SIP/2.0/UDP
10.199.240.179:7060;received=10.199.240.179;rport=7060;branch=z9hG4bKPj269365e0-798d-404b-bb77-2ad78472905c
From: "Penny"
;tag=ba402508-a640-409f-ba30-dffdfe499f43
To: ;tag=8BC58304-83D9B045
CSeq: 22619 INVITE
Call-ID: c3a406ca-9ac7-423d-9697-06d0603f48d5
Record-Route:
,
,

User-Agent: PolycomVVX-VVX_450-UA/5.8.0.12848
Accept-Language: en
Content-Length: 0



Any ideas how to fix it?



--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html

___
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] uac_replace_from and uac_auth fails to authenticate.

[Kjeld Flarup]

Thanks for the suggestions.

Much to my surprise just setting $fu did the trick.


 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 1/20/20 4:27 AM, Joel Serrano wrote:
Have you tried setting $fU/$fd directly in failure_route before 
uac_auth()?



On Sun, Jan 19, 2020 at 14:35 Kjeld Flarup 
mailto:kjeld.fla...@liberalismen.dk>> 
wrote:


Thanks for confirming.

As there seems to be no way to correct the From header in
failure_dialog, then the From header has to be modified before I
receive
the call then. Which could be done by cascading with a Cascading
Kamailio instance.


 Med Liberalistiske Hilsner --
    Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min
tegnebog
Sofienlundvej 6B, 7560 Hjerm

<https://www.google.com/maps/search/Sofienlundvej+6B,+7560+Hjerm?entry=gmail=g>,
Tlf: 40 29 41 49
    Den ikke akademiske hjemmeside for liberalismen -
www.liberalismen.dk <http://www.liberalismen.dk>

On 1/19/20 11:22 PM, Alex Balashov wrote:
> In non-REGISTER requests, the From URI is the identity being
asserted,
> and supported by the authentication credentials.
>
> If you have control over the upstream Kamailio server, you can
tinker
> with authentication options which enforce equivalence between the
> authentication username/realm and the From URI user/domain --
> specifically, by turning off this enforcement.
>
> If you don't, then a modified From value will indeed be a problem
> insofar as it may deviate from the authentication credentials.
>
> -- Alex
>
    > On Sun, Jan 19, 2020 at 11:19:26PM +0100, Kjeld Flarup wrote:
>
>> I have a setup where I have a fallback to a GSM number
>>
>> I look up the GSM number and provider information in a database
and sets the
>> headers.
>>
>>    dlg_manage();
>>    $du = "sip:" + $dbr(ra=>[0,0]);
>>    $tu = "sip:"+$rU+"@"+$dbr(ra=>[0,0]);
>>    $ru = "sip:"+$rU+"@"+$dbr(ra=>[0,0]);
>> uac_replace_from("sip:"+$dbr(ra=>[0,1])+"@EXTERNALIP");
>>
>> After this the call goes to a failure_route to do uac_auth()
>>
>> Now my problem is that this works with the providers Asterisk
server.
>> But if the call is send to the providers Kamailio server,
authentication is
>> rejected.
>>
>> Removing uac_replace_from makes the call accepted on the
Kamailio server
>>
>> The only possible problem I can see is that the first INVITE
without
>> authentication, has correct From header.
>> But the second with the nonce and auth, uses the wrong From
header. Thus two
>> different From headers in the same SIP dialog.
>>
>> Unfortunately uac_replace_from is not allowed in failure_route,
so I could
>> test if this is the problem.
>>
>> Is the two different From headers a problem, and how could that
be fixed.
>>
>>
>> --
>>  Med Liberalistiske Hilsner
--
>>     Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end
min tegnebog
>>     Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
>>     Den ikke akademiske hjemmeside for liberalismen -
www.liberalismen.dk <http://www.liberalismen.dk>
>>
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@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@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@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] uac_replace_from and uac_auth fails to authenticate.

[Kjeld Flarup]

Thanks for confirming.

As there seems to be no way to correct the From header in 
failure_dialog, then the From header has to be modified before I receive 
the call then. Which could be done by cascading with a Cascading 
Kamailio instance.



 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 1/19/20 11:22 PM, Alex Balashov wrote:

In non-REGISTER requests, the From URI is the identity being asserted,
and supported by the authentication credentials.

If you have control over the upstream Kamailio server, you can tinker
with authentication options which enforce equivalence between the
authentication username/realm and the From URI user/domain --
specifically, by turning off this enforcement.

If you don't, then a modified From value will indeed be a problem
insofar as it may deviate from the authentication credentials.

-- Alex

On Sun, Jan 19, 2020 at 11:19:26PM +0100, Kjeld Flarup wrote:


I have a setup where I have a fallback to a GSM number

I look up the GSM number and provider information in a database and sets the
headers.

   dlg_manage();
   $du = "sip:" + $dbr(ra=>[0,0]);
   $tu = "sip:"+$rU+"@"+$dbr(ra=>[0,0]);
   $ru = "sip:"+$rU+"@"+$dbr(ra=>[0,0]);
uac_replace_from("sip:"+$dbr(ra=>[0,1])+"@EXTERNALIP");

After this the call goes to a failure_route to do uac_auth()

Now my problem is that this works with the providers Asterisk server.
But if the call is send to the providers Kamailio server, authentication is
rejected.

Removing uac_replace_from makes the call accepted on the Kamailio server

The only possible problem I can see is that the first INVITE without
authentication, has correct From header.
But the second with the nonce and auth, uses the wrong From header. Thus two
different From headers in the same SIP dialog.

Unfortunately uac_replace_from is not allowed in failure_route, so I could
test if this is the problem.

Is the two different From headers a problem, and how could that be fixed.


--
---- Med Liberalistiske Hilsner --
Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk


___
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] uac_replace_from and uac_auth fails to authenticate.

[Kjeld Flarup]

I have a setup where I have a fallback to a GSM number

I look up the GSM number and provider information in a database and sets 
the headers.


  dlg_manage();
  $du = "sip:" + $dbr(ra=>[0,0]);
  $tu = "sip:"+$rU+"@"+$dbr(ra=>[0,0]);
  $ru = "sip:"+$rU+"@"+$dbr(ra=>[0,0]);
uac_replace_from("sip:"+$dbr(ra=>[0,1])+"@EXTERNALIP");

After this the call goes to a failure_route to do uac_auth()

Now my problem is that this works with the providers Asterisk server.
But if the call is send to the providers Kamailio server, authentication 
is rejected.


Removing uac_replace_from makes the call accepted on the Kamailio server

The only possible problem I can see is that the first INVITE without 
authentication, has correct From header.
But the second with the nonce and auth, uses the wrong From header. Thus 
two different From headers in the same SIP dialog.


Unfortunately uac_replace_from is not allowed in failure_route, so I 
could test if this is the problem.


Is the two different From headers a problem, and how could that be fixed.


--
-------- Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk


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

Re: [SR-Users] Kamailio in Docker Compile Error

[Kjeld Flarup]

I made a build using this
FROM ubuntu:18.04

RUN apt update
RUN apt install -y build-essential git bison flex pkg-config
libmysqlclient-dev libssl-dev libpcre3-dev mysql-client

RUN mkdir -p /usr/local/src/kamailio-devel && \
  cd /usr/local/src/kamailio-devel && \
  git clone --depth 1 -b 5.3.1 https://github.com/kamailio/kamailio kamailio
RUN cd /usr/local/src/kamailio-devel/kamailio && \
  make cfg && \
  make include_modules="db_mysql dialplan" cfg && \
  make all && \
  make install


  Kjeld

Den fre. 10. jan. 2020 kl. 02.23 skrev Sam Ware :

> I am attempting to create my own docker image on Centos 7.  During the
> build, I get the following error message during the "make all" phase.
> --
> CC (gcc) [kamailio] core/cfg.tab.o
> LD (gcc) [kamailio] kamailio
> make[1]: which: Command not found
> make[1]: which: Command not found
> make[1]: which: Command not found
> make[1]: which: Command not found
> make[1]: which: Command not found
> make[1]: which: Command not found
> CC (gcc) [M db_mysql.so]km_dbase.o
> km_dbase.c:36:19: fatal error: mysql.h: No such file or directory
>  #include 
>^
> compilation terminated.
> make[1]: *** [km_dbase.o] Error 1
> make: *** [modules] Error 1
> 
>
> I checked and the mysql.h exists in the /usr/include/mysql directory.
>
> Any thoughts?
>
> FYI, here is my Dockerfile
>
> FROM centos:7
> MAINTAINER “Sam D Ware” sw...@o1.com
> ENV container docker
> RUN (cd /lib/systemd/system/sysinit.target.wants/; for i in ; do [ $i ==
> systemd-tmpfiles-setup.service ] || rm -f $i; done);
> RUN rm -rf /lib/systemd/system/multi-user.target.wants/ \
> && rm -rf /etc/systemd/system/.wants/ \
> && rm -rf /lib/systemd/system/local-fs.target.wants/ \
> && rm -f /lib/systemd/system/sockets.target.wants/udev \
> && rm -f /lib/systemd/system/sockets.target.wants/initctl \
> && rm -rf /lib/systemd/system/basic.target.wants/ \
> && rm -f /lib/systemd/system/anaconda.target.wants/*
> VOLUME [ “/sys/fs/cgroup”]
> RUN yum -y install epel-release
> RUN yum -y update
> RUN yum -y install git-core gcc gcc-c++ flex bison mysql-devel
> RUN yum -y install mariadb-devel hiredis hiredis-devel curl nss make
> WORKDIR /usr/local/src/
> RUN git clone --depth 1 --no-single-branch
> https://github.com/kamailio/kamailio kamailio
> WORKDIR /usr/local/src/kamailio/
> RUN git checkout -b 5.3 origin/5.3
> RUN make cfg
> COPY modules.lst /usr/local/src/kamailio/src/
> RUN make all
> RUN make install
> RUN groupadd kamailio
> RUN adduser --system -g kamailio --shell /bin/false -c "Kamailio" --home
> /var/run/kamailio kamailio
> RUN cp /usr/local/src/kamailio/pkg/kamailio/obs/kamailio.sysconfig
> /etc/sysconfig/kamailio
> COPY kamailio.service /etc/systemd/system/kamailio.service
> RUN yum clean all; systemctl enable kamailio
> CMD ["/usr/sbin/init"]
>
> --
> Sam  D Ware
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 

- Med Liberalistiske Hilsner --

   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Removing extra Connection information in SDP

[Kjeld Flarup]

Hello

I have a problem with some phone numbers at Telenor. Our door telephone 
does not reply with an ACK on the 200 OK.

All I found was a weird SDP response with two "connection information" lines

Session Description Protocol

    Session Description Protocol Version (v): 0

    Owner/Creator, Session Id (o): BroadWorks 307119541 1 IN IP4 194.247.61.31

    Session Name (s): -

    Connection Information (c): IN IP4 194.247.61.31

    Time Description, active time (t): 0 0

    Session Attribute (a): sendrecv

    Media Description, name and address (m): audio 23116 RTP/AVP 8 101

    Connection Information (c): IN IP4 194.247.61.31

    Media Attribute (a): rtpmap:8 PCMA/8000

    Media Attribute (a): rtpmap:101 telephone-event/8000

    Media Attribute (a): fmtp:101 0-15

    Media Attribute (a): maxptime:40

    Media Attribute (a): bsoft:1 image udptl t38

    Media Attribute (a): sendrecv

    Media Attribute (a): silenceSupp:off - - - -

    Media Attribute (a): setup:actpass

To debug, I would like to remove one of the "Connection Information (c): 
IN IP4 194.247.61.31", to see if this is what confuses the door telephone.

But how do I do that?

I tried with this but nothing happeded

onreply_route[DOOR_MANAGE_REPLY] {

        if (is_method("INVITE|SUBSCRIBE"))

        {

  sdp_remove_line_by_prefix("c=IN IP4 194");

        }

    return 1;

}





--

- Med Liberalistiske Hilsner ------

   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen -www.liberalismen.dk  
<http://www.liberalismen.dk>

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

[SR-Users] Get totally rid of H.264 SDP

[Kjeld Flarup]

Hi

I have a door telephone, with GSM fallback. Since telephone operators are
going away from SS7, more and more traffic goes SIP.
Thus we now have some numbers where we can see that doing an invite with
H.264 causes them to fail.

I have tried to remove coded 96 with sdp_remove_codecs_by_id, but it still
leaves most of the video SDP in the invite.

SDP received by kamailio
Media Description, name and address (m): video 6100 RTP/AVP 96
Media Attribute (a): rtcp:6101 IN IP4 192.168.237.239
Media Attribute (a): rtpmap:96 H264/9
Media Attribute (a): fmtp:96
profile-level-id=42000d;packetization-mode=1
Media Attribute (a): sendrecv

After sdp_remove_codecs_by_id I send this. But without "96"
Media Description, name and address (m): video 6534 RTP/AVP
Media Attribute (a): sendrecv
Media Attribute (a): rtcp:6535
Media Attribute (a): ice-ufrag:35ZngQdL
Media Attribute (a): ice-pwd:DG6kUbcYwBFKNS6YzCG27wRlG4
Media Attribute (a): candidate:r9KO0wNPMTGktklS 1 UDP
2130706431 192.168.237.15 6534 typ host
Media Attribute (a): candidate:r9KO0wNPMTGktklS 2 UDP
2130706430 192.168.237.15 6535 typ host

My problem is that the door telephone does not do an ACK when it gets the
200 OK
My suspicion is that it does not understand the video response
Media Description, name and address (m): video 0 RTP/AVP 0
Media Attribute (a): ice-ufrag:35ZngQdL
Media Attribute (a): ice-pwd:DG6kUbcYwBFKNS6YzCG27wRlG4
Media Attribute (a): sendrecv

Is there a way to remove the whole video part and not just the coded id?

It is not an option to disable video in the door telephone, as we need the
video. It is just in the fallback is must be removed.

-- 

- Med Liberalistiske Hilsner --

   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] set_advertised_address

[Kjeld Flarup]

So I could do something like this:

listen=192.168.2.9:5070 advertise 20.30.40.50:5070
listen=192.168.2.9:5050

However when I do an invite to 192.168.2.32, would Kamailio choose 5050 
or 5070?

Same when inviting to 40.40.40.40

If I were to listen to another local IP, then the routing table in Linux 
could perhaps dictate which connection to use.



 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 12/5/18 6:10 PM, Sergiu Pojoga wrote:
For whatever reason my initial impression was if it was possible for 
external devices to connect without port forwarding...


I stand corrected.


On Wed, Dec 5, 2018 at 11:30 AM Daniel-Constantin Mierla 
mailto:mico...@gmail.com>> wrote:


It is not about an external network interface, but external
traffic/devices. The NAT in this case is a port forwarding
firewall, like Amazon or Google cloud, where you have a local
address on server and the firewall is forwarding by port all
traffic from an assigned public address.

Such scenario is quite common in enterprise environment, the
devices on local network connect by private IP, and the external
devices connect to the firewall ip and this one does port forwarding.

Cheers,
Daniel

On 05.12.18 16:56, Sergiu Pojoga wrote:

Slightly confused here... didn't he say that Kamailio and PBX are
behind NAT? If so, what external interface are we talking about?

On Wed, Dec 5, 2018 at 9:18 AM Daniel-Constantin Mierla
mailto:mico...@gmail.com>> wrote:

Hello,

you do not need a second kamailio, the same instance can
listen on
multiple sockets. You can also use a single ip, just listen
on one port
for traffic from local network and on another port for
external traffic
(this socket with advertise address).

If the router cannot handle dns query based on local traffic,
most
devices support so called outbound proxy address, you can set
that to
the sip server address with ip.

Cheers,
Daniel

On 05.12.18 13:02, Kjeld Flarup wrote:
> That might work, provided that the router can handle a
local DNS.
>
> It would, however still require adding an extra Kamailio
instance with
> another IP. Plus a branch of the invite to both local and
public
> instance. Plus an extra location table.
>
>  Med Liberalistiske Hilsner
--
    >    Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end
min tegnebog
>    Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
>    Den ikke akademiske hjemmeside for liberalismen -
www.liberalismen.dk <http://www.liberalismen.dk>
>
> On 12/5/18 12:11 PM, Daniel Tryba wrote:
    >> On Wed, Dec 05, 2018 at 09:40:38AM +0100, Kjeld Flarup wrote:
>>> Yes, the Phones may be on either local LAN (Wifi) and
Internet via
>>> mobile
>>> data.
>> How about use different local address, 1 with an advertise
for external
>> clients, 1 without. Have local DNS resolv to the 1 ip
without advertise.
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@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@lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com

<http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio World Conference -- www.kamailioworld.com
<http://www.kamailioworld.com>
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin --
www.asipto.com <http://www.asipto.com>


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

-- 
Daniel-Constantin Mierla --www.asipto.com  <http://www.asipto.com>

www.twitter.com

Re: [SR-Users] set_advertised_address

[Kjeld Flarup]

That might work, provided that the router can handle a local DNS.

It would, however still require adding an extra Kamailio instance with 
another IP. Plus a branch of the invite to both local and public 
instance. Plus an extra location table.


 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 12/5/18 12:11 PM, Daniel Tryba wrote:

On Wed, Dec 05, 2018 at 09:40:38AM +0100, Kjeld Flarup wrote:

Yes, the Phones may be on either local LAN (Wifi) and Internet via mobile
data.

How about use different local address, 1 with an advertise for external
clients, 1 without. Have local DNS resolv to the 1 ip without advertise.

___
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] set_advertised_address

[Kjeld Flarup]

Hi Daniel

Yes, the Phones may be on either local LAN (Wifi) and Internet via 
mobile data.


 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 12/5/18 8:40 AM, Daniel-Constantin Mierla wrote:

Hello,

it is not clear what exactly you want to achieve...

Is it that for connected phones from local network to use the local IP
and for sip messages with devices outside to use external ip?

Cheers,
Daniel

On 04.12.18 23:33, Kjeld Flarup wrote:

Hello

I have a PBX behind NAT.
Thus I advertise the public IP, and forwards the port to my PBX.

listen=LOCALIP:5070 advertise EXTERNALIP:5070

Now clients can connect to the PBX from the Internet. And also inside
the LAN, because I have enabled NAT loopback.

However some customers sysadmins complains that NAT loopback is a
security risk. I have not been able to find any exploits of this, but
the sales and support people asks if it is possible to remove this NAT
loopback requirement.

I could look at $rd and if it is local, then I could  advertise LOCALIP.
I found set_advertised_address("LOCALIP");

set_advertised_address however only seems to modify the latest Via
header, not the Record-route, and audio neither works.

Could I do something to make this work, or is it a dead end?




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

[SR-Users] set_advertised_address

[Kjeld Flarup]

Hello

I have a PBX behind NAT.
Thus I advertise the public IP, and forwards the port to my PBX.

listen=LOCALIP:5070 advertise EXTERNALIP:5070

Now clients can connect to the PBX from the Internet. And also inside 
the LAN, because I have enabled NAT loopback.


However some customers sysadmins complains that NAT loopback is a 
security risk. I have not been able to find any exploits of this, but 
the sales and support people asks if it is possible to remove this NAT 
loopback requirement.


I could look at $rd and if it is local, then I could  advertise LOCALIP.
I found set_advertised_address("LOCALIP");

set_advertised_address however only seems to modify the latest Via 
header, not the Record-route, and audio neither works.


Could I do something to make this work, or is it a dead end?


--
 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk


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

Re: [SR-Users] high availability and load balancing

[Kjeld Flarup]

Hi Eyas


A typical HA setup has two kamailio proxies with identical setup.

Use keepalived or similar to give the proxies a shared IP.

Because of the shared IP, all traffic will go to one proxy only.

Thus each of the proxies must be able to handle all traffic, mening the 
functionality must be very simple - no media handling.


Then use the dispatcher module to do load balancing.




 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 11/9/18 5:09 PM, eyas barhouk wrote:

hello dears,

i'm using kamailio 5.1 as IMS , and i have the following servers:

  * p-cscf
  * i-cscf-1 ,icscf-2
  * s-cscf-1,scscf-2

i need to do high availability and load balancing between my servers , 
but i have some questions like do i have to use keepalived or 
dispatcher module and what the benefits of each one of them ,and on 
load balancing method should i do it for the register requests or only 
for invite requests or just for every thing ??

if any one has an idea or any thing to guide me i will be thankful

thanks in advance and regards

___
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] cfg_lock_helper(): lock set not initialized

[Kjeld Flarup]

Hi

What does this error actually mean? I get it with 5.1.4

Nov  6 13:27:02 scantronpbx /usr/sbin/kamailio[2149]: ERROR: cfgutils 
[cfgutils.c:708]: cfg_lock_helper(): lock set not initialized (attempt 
to do op: 1 on: u1)



--
 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk


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

[SR-Users] How is ruid calculated

[Kjeld Flarup]

I got two tablets registering with the same username, this used to work 
but now I got a bug report that only one of them gets a call.


I found out that the problem is in the ruid column as they both end up 
with this ruid value uloc-1-5bd0abe9-83c-e4


How is that ruid value calculated, and how can I change this?

--
 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk


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

[SR-Users] How is ruid calculated

[Kjeld Flarup]

I got two tablets registering with the same username, this used to work 
but now I got a bug report that only one of them gets a call.


I found out that the problem is in the ruid column as they both end up 
with this ruid value uloc-1-5bd0abe9-83c-e4


How is that ruid value calculated, and how can I change this?

--
 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk


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

Re: [SR-Users] Kamailio installation

[Kjeld Flarup]

Anybody would recommend using these ?

https://hub.docker.com/u/kamailio/

 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk



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

Re: [SR-Users] ACK to 200 OK without to tag

[Kjeld Flarup]

That clearly sound like a bug in the Grandstream.

But lets say that we simply need to make this work.

Is it possible to save the TO field from the 200 OK and reapply it to 
the ACK before processing?



 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 06/03/2018 11:06 PM, Alex Balashov wrote:

The end-to-end ACK for a 2xx reply to an INVITE is an in-dialog request
and must have a To-tag.

On Sun, Jun 03, 2018 at 11:04:47PM +0200, Kjeld Flarup wrote:


We have a SIP doorstation Grandstream GDS3710. When I connect it via
kamailio, it does not setup call correct.

Kamailio sends a 200 OK with this to field:
     t:
;tag=e33a13d3-c18c-4df1-b68f-446e42957de6

Grandstream answers with:
     To: 

As the code follows this example: 
https://kamailio.org/docs/modules/4.3.x/modules/dispatcher.html#dispatcher.ex.config,
it seems obvious that this will fail, as there is not

route[WITHINDLG] {
     if (has_totag()) {

There simply is not to tag. Is this a bug in the grandstream?

If so how could that go unnoticed, or is it me who misses something?

I have attached the full sip text for the 200OK and the ACK

--
 Med Liberalistiske Hilsner --
Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

   43847 12:49:34.444277192.168.1.150 192.168.1.155 SIP/SDP 
 320Status: 200 OK |

Frame 43847: 320 bytes on wire (2560 bits), 320 bytes captured (2560 bits)
 Encapsulation type: Linux cooked-mode capture (25)
 Arrival Time: Jun  3, 2018 14:49:34.444277000 CEST
 [Time shift for this packet: 0.0 seconds]
 Epoch Time: 1528030174.444277000 seconds
 [Time delta from previous captured frame: 0.26000 seconds]
 [Time delta from previous displayed frame: 0.26000 seconds]
 [Time since reference or first frame: 21839.020163000 seconds]
 Frame Number: 43847
 Frame Length: 320 bytes (2560 bits)
 Capture Length: 320 bytes (2560 bits)
 [Frame is marked: False]
 [Frame is ignored: False]
 [Protocols in frame: sll:ethertype:ip:udp:sip:sdp]
 [Coloring Rule Name: UDP]
 [Coloring Rule String: udp]
Linux cooked capture
 Packet type: Sent by us (4)
 Link-layer address type: 1
 Link-layer address length: 6
 Source: Raspberr_fb:99:9f (b8:27:eb:fb:99:9f)
 Unused: fffe
 Protocol: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.150, Dst: 192.168.1.155
 0100  = Version: 4
  0101 = Header Length: 20 bytes (5)
 Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT)
 0001 00.. = Differentiated Services Codepoint: Unknown (4)
  ..00 = Explicit Congestion Notification: Not ECN-Capable 
Transport (0)
 Total Length: 304
 Identification: 0x3c2f (15407)
 Flags: 0x00b9
 0...    = Reserved bit: Not set
 .0..    = Don't fragment: Not set
 ..0.    = More fragments: Not set
 ...0  1011 1001 = Fragment offset: 185
 Time to live: 64
 Protocol: UDP (17)
 Header checksum: 0xb843 [validation disabled]
 [Header checksum status: Unverified]
 Source: 192.168.1.150
 Destination: 192.168.1.155
 [2 IPv4 Fragments (1764 bytes): #43845(1480), #43847(284)]
 [Frame: 43845, payload: 0-1479 (1480 bytes)]
 [Frame: 43847, payload: 1480-1763 (284 bytes)]
 [Fragment count: 2]
 [Reassembled IPv4 length: 1764]
 [Reassembled IPv4 data: 
13cd13c406e440da5349502f322e3020323030204f4b0d0a...]
User Datagram Protocol, Src Port: 5069, Dst Port: 5060
 Source Port: 5069
 Destination Port: 5060
 Length: 1764
 Checksum: 0x40da [unverified]
 [Checksum Status: Unverified]
 [Stream index: 3]
Session Initiation Protocol (200)
 Status-Line: SIP/2.0 200 OK
 Status-Code: 200
 [Resent Packet: True]
 [Suspected resend of frame: 43826]
 [Request Frame: 43831]
 [Response Time (ms): 498]
 Message Header
 v: SIP/2.0/UDP 
192.168.1.155:5060;rport=5060;received=192.168.1.155;branch=z9hG4bK1571336256
 Transport: UDP
 Sent-by Address: 192.168.1.155
 Sent-by port: 5060
 RPort: 5060
 Received: 192.168.1.155
 Branch: z9hG4bK1571336256
 Record-Route: 

 Record-Route URI: 
sip:5.103.133.210:5070;transport=tcp;lr;r2=on;ftag=851466465;vst=CwUAARgIAAAUBAoCATg1MDt0cmFuc3BvcnQ9VENQO29i;nat=yes
 Record-Route Host Part: 5.103.133.210
 Record-Route Host Port: 5070

[SR-Users] ACK to 200 OK without to tag

[Kjeld Flarup]

We have a SIP doorstation Grandstream GDS3710. When I connect it via 
kamailio, it does not setup call correct.


Kamailio sends a 200 OK with this to field:
    t: 
;tag=e33a13d3-c18c-4df1-b68f-446e42957de6


Grandstream answers with:
    To: 

As the code follows this example: 
https://kamailio.org/docs/modules/4.3.x/modules/dispatcher.html#dispatcher.ex.config, 
it seems obvious that this will fail, as there is not


route[WITHINDLG] {
    if (has_totag()) {

There simply is not to tag. Is this a bug in the grandstream?

If so how could that go unnoticed, or is it me who misses something?

I have attached the full sip text for the 200OK and the ACK

--
 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

  43847 12:49:34.444277192.168.1.150 192.168.1.155 SIP/SDP  
320Status: 200 OK | 

Frame 43847: 320 bytes on wire (2560 bits), 320 bytes captured (2560 bits)
Encapsulation type: Linux cooked-mode capture (25)
Arrival Time: Jun  3, 2018 14:49:34.444277000 CEST
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1528030174.444277000 seconds
[Time delta from previous captured frame: 0.26000 seconds]
[Time delta from previous displayed frame: 0.26000 seconds]
[Time since reference or first frame: 21839.020163000 seconds]
Frame Number: 43847
Frame Length: 320 bytes (2560 bits)
Capture Length: 320 bytes (2560 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: sll:ethertype:ip:udp:sip:sdp]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Linux cooked capture
Packet type: Sent by us (4)
Link-layer address type: 1
Link-layer address length: 6
Source: Raspberr_fb:99:9f (b8:27:eb:fb:99:9f)
Unused: fffe
Protocol: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.150, Dst: 192.168.1.155
0100  = Version: 4
 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT)
0001 00.. = Differentiated Services Codepoint: Unknown (4)
 ..00 = Explicit Congestion Notification: Not ECN-Capable Transport 
(0)
Total Length: 304
Identification: 0x3c2f (15407)
Flags: 0x00b9
0...    = Reserved bit: Not set
.0..    = Don't fragment: Not set
..0.    = More fragments: Not set
...0  1011 1001 = Fragment offset: 185
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xb843 [validation disabled]
[Header checksum status: Unverified]
Source: 192.168.1.150
Destination: 192.168.1.155
[2 IPv4 Fragments (1764 bytes): #43845(1480), #43847(284)]
[Frame: 43845, payload: 0-1479 (1480 bytes)]
[Frame: 43847, payload: 1480-1763 (284 bytes)]
[Fragment count: 2]
[Reassembled IPv4 length: 1764]
[Reassembled IPv4 data: 
13cd13c406e440da5349502f322e3020323030204f4b0d0a...]
User Datagram Protocol, Src Port: 5069, Dst Port: 5060
Source Port: 5069
Destination Port: 5060
Length: 1764
Checksum: 0x40da [unverified]
[Checksum Status: Unverified]
[Stream index: 3]
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: True]
[Suspected resend of frame: 43826]
[Request Frame: 43831]
[Response Time (ms): 498]
Message Header
v: SIP/2.0/UDP 
192.168.1.155:5060;rport=5060;received=192.168.1.155;branch=z9hG4bK1571336256
Transport: UDP
Sent-by Address: 192.168.1.155
Sent-by port: 5060
RPort: 5060
Received: 192.168.1.155
Branch: z9hG4bK1571336256
Record-Route: 

Record-Route URI: 
sip:5.103.133.210:5070;transport=tcp;lr;r2=on;ftag=851466465;vst=CwUAARgIAAAUBAoCATg1MDt0cmFuc3BvcnQ9VENQO29i;nat=yes
Record-Route Host Part: 5.103.133.210
Record-Route Host Port: 5070
Record-Route URI parameter: transport=tcp
Record-Route URI parameter: lr
Record-Route URI parameter: r2=on
Record-Route URI parameter: ftag=851466465
Record-Route URI parameter: 
vst=CwUAARgIAAAUBAoCATg1MDt0cmFuc3BvcnQ9VENQO29i
Record-Route URI parameter: nat=yes
Record-Route: 

Record-Route URI: 
sip:127.0.0.1:5070;lr;r2=on;ftag=851466465;vst=CwUAARgIAAAUBAoCATg1MDt0cmFuc3BvcnQ9VENQO29i;nat=yes
Record-Route Host Part: 127.0.0.1
Record-Route Host Port: 5070
Record-Route URI parameter: lr
Record-Route URI parameter: r2

[SR-Users] Garbage in to field

[Kjeld Flarup]

I'm having problems with my To field.

I'm doing an async_route, and afterwards sends the call with auth to a 
SIP server.


My problem is that in the first invite I see the expected To field
sip:004520202...@isp.com

But when the Auto is send the To field is changed to the, To field for 
the PBX

sip:1234@pbx.local


I tried to fix this with uac_replace_to("$ru"), but that ends up in this 
To field:

sip:004520202020@isp.comsip:004520202...@isp.com

It seems like uac_replace_to sometimes appends rather that replaces.
If I run it twice, then it for sure appends. Is this expected behaviour.



--
 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk


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

Re: [SR-Users] How long time does a push take?

[Kjeld Flarup]

We are already using VoIP push for Apple, so we must accept, that this 
is never going to be good.


 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 05/01/2018 06:14 PM, Joel Serrano wrote:
AFAIR, there was an option you can set when you send the request to 
Google/Apple to mark the push as a "high priority push". Apple itself 
has also a specific VoIP push, (it's a different type of push, not 
regular push). it should be what you are using for VoIP related stuff. 
Not that this will speed up things, but it might make a difference 
when Google/Apple have issues delivering push notifications.


I think that is as much as you can get.. from that point onwards, 
there are just too many variables out of your control that can add 
extra delay in receiving a push notification.


Joel.





On Sun, Apr 29, 2018 at 12:42 AM, Kjeld Flarup 
<kjeld.fla...@liberalismen.dk <mailto:kjeld.fla...@liberalismen.dk>> 
wrote:


We have a suspicion that the delay is caused by Google and Apple
being busy pushing "spam" to the whole world. A lot of messages,
which does not require "real time".

 Med Liberalistiske Hilsner ----------
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min
tegnebog
Sofienlundvej 6B, 7560 Hjerm

<https://maps.google.com/?q=Sofienlundvej+6B,+7560+Hjerm=gmail=g>,
Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen -
www.liberalismen.dk <http://www.liberalismen.dk>

On 04/29/2018 12:25 AM, Alex Balashov wrote:

When it comes to speed at which things happen, nothing in
wireless is impressive when we are talking about telephony. :)

On April 28, 2018 6:24:36 PM EDT, Kjeld Flarup
<kjeld.fla...@liberalismen.dk
<mailto:kjeld.fla...@liberalismen.dk>> wrote:

Hello

I have a question to those of You who uses push via Google
or Apple to
initiate calls.

How long time does it usually take, before the phone gets
the push and
wakes up?

Our experience is, that it can take from 2 to 10 seconds,
and that not
impressing when we are talking about telephony.


-- 
 Med Liberalistiske Hilsner

        --
  Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end
min t

<https://maps.google.com/?q=ind+er+mere+%C3%A5bent+end+min+t=gmail=g>egnebog
    Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
  Den ikke akademiske hjemmeside for liberalismen -
www.liberalismen.dk <http://www.liberalismen.dk>


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
<mailto: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>


-- Alex

--
Sent via mobile, please forgive typos and brevity.

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org <mailto: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>



___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org <mailto: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>




___
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] How long time does a push take?

[Kjeld Flarup]

We have a suspicion that the delay is caused by Google and Apple being 
busy pushing "spam" to the whole world. A lot of messages, which does 
not require "real time".


 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 04/29/2018 12:25 AM, Alex Balashov wrote:

When it comes to speed at which things happen, nothing in wireless is 
impressive when we are talking about telephony. :)

On April 28, 2018 6:24:36 PM EDT, Kjeld Flarup <kjeld.fla...@liberalismen.dk> 
wrote:

Hello

I have a question to those of You who uses push via Google or Apple to
initiate calls.

How long time does it usually take, before the phone gets the push and
wakes up?

Our experience is, that it can take from 2 to 10 seconds, and that not
impressing when we are talking about telephony.


--
 Med Liberalistiske Hilsner ------
  Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
  Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk


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


-- Alex

--
Sent via mobile, please forgive typos and brevity.

___
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] How long time does a push take?

[Kjeld Flarup]

Hello

I have a question to those of You who uses push via Google or Apple to 
initiate calls.


How long time does it usually take, before the phone gets the push and 
wakes up?


Our experience is, that it can take from 2 to 10 seconds, and that not 
impressing when we are talking about telephony.



--
 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk


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

Re: [SR-Users] Branching and rejects.

[Kjeld Flarup]

What could change this behavior? I see that the first 404 I get return 
is passed on.


Could it be the t_newtran(). I Honestly don't remember why we put it there.
if ( !lookup("doorlocation") ) {
                $var(rc) = $rc;
                t_newtran();
                switch ($var(rc)) {


The doorlocation is also a "fake" location table, not used for 
registrations, but to make a branch to either a fixed terminal, or a 
mobile phone, which uses a second location table.
The fixed terminal can right away return 404, but the mobile phone, 
first has to receive a push, which can take some seconds.

Can this time difference in reply cause the issue?

  Kjeld Flarup

2018-04-16 9:23 GMT+02:00 Daniel-Constantin Mierla <mico...@gmail.com 
<mailto:mico...@gmail.com>>:


   Hello,

   you do not need to discard the branch replies at all. Kamailio sends
   only one reply back, even if you do many outgoing branches, kamailio is
   going to wait until all of the get a final reply and then selects the
   one with highest priority to send back.

   Cheers,
   Daniel


   On 14.04.18 23:05, Kjeld Flarup wrote:
> Hello
>
> What is the correct way to handle, if a branched call reaches a
   404 on
> one of the branches.
>
> Currently I discard all 404 in onreply_route, but if all branches has
> 404, then this is never send to the caller.
>

   -- 
   Daniel-Constantin Mierla

   www.twitter.com/miconda <http://www.twitter.com/miconda> --
   www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
   Kamailio Advanced Training - April 16-18, 2018, Berlin -
   www.asipto.com <http://www.asipto.com>
   Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
   <http://www.kamailioworld.com>


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

Re: [SR-Users] Problem with resuming suspended transacation

[Kjeld Flarup]

You are suspending in [6039] and resuming in [6092], does these two
processes share memory?

  Kjeld

2018-04-12 11:52 GMT+02:00 Arik Halperin :

> Hello,
>
>
>
> I’m trying to resume a suspended transaction, but keep getting this error:
>
>
>
> WARNING: tm [t_suspend.c:193]: t_continue(): transaction is not suspended
> [20608:1256194941]
>
> WARNING: tmx [tmx_mod.c:686]: w_t_continue(): resuming the processing of
> transaction [20608:1256194941] failed
>
> WARNING: tm [t_lookup.c:1483]: t_unref(): script writer didn't release
> transaction
>
>
>
>
>
> I’m implementing push handling, in INVITE I do the following:
>
>
>
> route[INVITE] {
>
>   *if (!lookup("location"))*
>
>   {
>
>
>
>send_reply("100", "Trying");
>
> record_route();
>
> *route(SUSPEND);*
>
>   }
>
>   else
>
>   {
>
>  # NAT detection
>
>  route(NATMANAGE);
>
>  if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY");
>
> record_route();
>
>  t_relay();
>
>  ts_store();
>
>  $sht(vtp=>stored::$rU) = 1;
>
> }
>
> route(SENDPUSH);
>
> }
>
>
>
> # suspend the transaction
>
> route[SUSPEND] {
>
>
>
> *if(!t_suspend()) *//Transaction is suspended!
>
> {
>
>   exit;
>
> }
>
> $sht(vtp=>join::$rU) = "" + $T(id_index) + ":" +$T(id_label);
>
> }
>
>
>
> In Register I call the PUSHJOIN route:
>
>
>
> # append branches or resume the transaction
>
> route[PUSHJOIN] {
>
> $var(hjoin) = 0;
>
> lock("$tU");
>
> $var(hjoin) = $sht(vtp=>join::$tU);
>
> $var(hstored) = $sht(vtp=>stored::$tU);
>
> $sht(vtp=>join::$tU) = $null;
>
> unlock("$tU");
>
> if ($var(hjoin)==0)
>
> {
>
> if ($var(hstored))
>
> ts_append("location", "$tu");
>
> return;
>
> }
>
> $var(id_index) = $(var(hjoin){s.select,0,:}{s.int});
>
> $var(id_label) = $(var(hjoin){s.select,1,:}{s.int});
>
> ($var(hjoin))\n");
>
> * t_continue("$var(id_index)", "$var(id_label)", "INVRESUME");*
>
> }
>
>
>
>
>
> For some reason I keep getting:
>
>
>
> Apr 12 12:37:11 kamprod /usr/local/sbin/kamailio[6039]: ERROR: 

Re: [SR-Users] no corresponding socket found for

[Kjeld Flarup]

Hi Daniel

I was actually using

kamailio:5069 lookup() => 12345678@kamailio:5070 forward() => 
kamailio:5071 t_relay()

    u1@kamailio:5070 (404)

I thus tried to change forward() to t_relay(), but then I found that the 
call was cancelled. Removing all 404 reply generations in the system, 
made my call get through.


It seems that lookup() branched the call, and the "u1" branch in 
kamailio:5070 generated a 404 back to kamailio:5069, but also a cancel 
to kamailio:5071. The cancel to kamailio:5071 was however for the u1 
branch and not the 12345678 branch. But the callid was the same!



 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 04/10/2018 10:49 AM, Daniel-Constantin Mierla wrote:


Looks like the socket used for sending out is the loopback address and 
thus cannot send to 192.168.2.101.


Do you use t_relay() for forwarding the request?

Cheers,
Daniel


On 10.04.18 10:08, Kjeld Flarup wrote:

Listening is configured like this:

#!define LOCALIP 192.168.2.9
#!subst "/LOCALIP/192.168.2.9/g <http://192.168.2.9/g>"
listen=127.0.0.1:5069 <http://127.0.0.1:5069>
listen=LOCALIP:5069


Kjeld

2018-04-10 9:43 GMT+02:00 Daniel-Constantin Mierla <mico...@gmail.com 
<mailto:mico...@gmail.com>>:


Hello,

is the instance throwing the error listening only on 127.0.0.1
address?

    Cheers,
Daniel


On 09.04.18 23:54, Kjeld Flarup wrote:


Hi

I have a setup with three kamailio's in the same host but on
different ports. client ->5069 -> 5070 -> 5071 -> SIP provider

Now I get this error from the 5069 Kamailio when it is routing a
200 Ok to the client:

Apr  9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: 
[forward.c:181]: get_out_socket(): no socket found
Apr  9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: 
[forward.c:183]: get_out_socket(): no corresponding socket found
for(udp:192.168.2.101:10120 <http://192.168.2.101:10120>)
Apr  9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: 
[forward.c:808]: do_forward_reply(): cannot forward reply

By manipulating the database I can skip the 5070 Kamailio, and
then it works.

I captured these two 200 Ok packets to the 5069 kamailio

*Failing:*

No. Time Source    Destination Protocol Length Info
   4713 21:54:12.814245 127.0.0.1 127.0.0.1 SIP/SDP 
2297   Status: 200 OK |

Frame 4713: 2297 bytes on wire (18376 bits), 2297 bytes captured
(18376 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
User Datagram Protocol, Src Port: 5070, Dst Port: 5069
Session Initiation Protocol (200)
    Status-Line: SIP/2.0 200 OK
    Message Header
    Via: SIP/2.0/UDP

127.0.0.1:5069;rport=5069;branch=z9hG4bK6ef1.0c009dcf5b4965c5d1a13d508e0b31c5.0
    Via: SIP/2.0/UDP

192.168.2.101:10120;received=192.168.2.101;rport=10120;branch=z9hG4bKPjIq.uY6jYbHkIqCo03bYLsTzccb7oy9jw
    Record-Route:
<sip:127.0.0.8;line=sr-z-yMngm271wI73zx7gmx0CmHdDZWd-w*>
    Record-Route:

<sip:127.0.0.8;line=sr-z-yMngm271wI73zx7gmx0Cq.7Cc-039Sz4Rxz5kezbQWOtUMn-9yTjcWODXoTC9BzK**>
    Record-Route:

<sip:127.0.0.8;line=sr-z-yMngmS0-R4LCz2LtZ-Lg02L-JoLNQGn3057t0SntZ5LNL2QD7Vz12-sjkSTtMxTiB.7Cc-0399LtUqzgSGnCQx0gQ56gLG6g0wn5UILt2NziWIO3ooTDcHdDZ*>
    Record-Route:

<sip:127.0.0.8;line=sr-z-yMngm271wI73zx7gmx0Nm.7Cc5039Sz4Rxz5kezbQWOtUMn-9yTjcWODXoTC9BzK**>
    Record-Route:

<sip:127.0.0.8;line=sr-z-yMngm271wI7CJx0gZx73Q.7Cc50C9I0goedg9Bzgoedg94OiRbvEynTR7EFm0wFSOZQCOsOiGQs3EIzyUMTi7jnD7qzmWjn-UVT3SwTiJx7NLo0Q**>
    Record-Route:

<sip:127.0.0.1:5071;r2=on;lr=on;ftag=YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;did=8de.7651>
    Record-Route:

<sip:127.0.0.1:5070;lr=on;ftag=YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;did=8de.01b2>
    Record-Route:

<sip:127.0.0.1:5069;r2=on;lr=on;ftag=YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;vsf=AAABAAAIMDE-;did=8de.d821>
    Record-Route:

<sip:192.168.2.9:5069;r2=on;lr=on;ftag=YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;vsf=AAABAAAIMDE-;did=8de.d821>
    From: "Door" <sip:u1@192.168.2.101>
<mailto:sip:u1@192.168.2.101>;tag=YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW
    To: <sip:004540294...@scantron.viptel.dk:5070>
<mailto:sip:004540294...@scantron.viptel.dk:5070>;tag=1865008112
    Call-ID: ou8V0cLHn.P7Oca-pgsnMmrWO43kIQX8
    CSeq: 5778 INVITE
    Contact:

<sip:127.0.0.8;line=sr-z-yMnrBS7C

Re: [SR-Users] no corresponding socket found for

[Kjeld Flarup]

Listening is configured like this:

#!define LOCALIP 192.168.2.9
#!subst "/LOCALIP/192.168.2.9/g"
listen=127.0.0.1:5069
listen=LOCALIP:5069


Kjeld

2018-04-10 9:43 GMT+02:00 Daniel-Constantin Mierla <mico...@gmail.com>:

> Hello,
>
> is the instance throwing the error listening only on 127.0.0.1 address?
>
> Cheers,
> Daniel
>
> On 09.04.18 23:54, Kjeld Flarup wrote:
>
> Hi
>
> I have a setup with three kamailio's in the same host but on different
> ports. client ->5069 -> 5070 -> 5071 -> SIP provider
>
> Now I get this error from the 5069 Kamailio when it is routing a 200 Ok to
> the client:
>
> Apr  9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: 
> [forward.c:181]: get_out_socket(): no socket found
> Apr  9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: 
> [forward.c:183]: get_out_socket(): no corresponding socket found for(udp:
> 192.168.2.101:10120)
> Apr  9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: 
> [forward.c:808]: do_forward_reply(): cannot forward reply
>
> By manipulating the database I can skip the 5070 Kamailio, and then it
> works.
>
> I captured these two 200 Ok packets to the 5069 kamailio
>
> *Failing:*
>
> No. Time   SourceDestination
> Protocol Length Info
>4713 21:54:12.814245127.0.0.1 127.0.0.1
> SIP/SDP  2297   Status: 200 OK |
>
> Frame 4713: 2297 bytes on wire (18376 bits), 2297 bytes captured (18376
> bits)
> Linux cooked capture
> Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
> User Datagram Protocol, Src Port: 5070, Dst Port: 5069
> Session Initiation Protocol (200)
> Status-Line: SIP/2.0 200 OK
> Message Header
> Via: SIP/2.0/UDP 127.0.0.1:5069;rport=5069;branch=z9hG4bK6ef1.
> 0c009dcf5b4965c5d1a13d508e0b31c5.0
> Via: SIP/2.0/UDP 192.168.2.101:10120;received=
> 192.168.2.101;rport=10120;branch=z9hG4bKPjIq.uY6jYbHkIqCo03bYLsTzccb7oy9jw
> Record-Route: <sip:127.0.0.8;line=sr-z-
> yMngm271wI73zx7gmx0CmHdDZWd-w*>
> Record-Route: <sip:127.0.0.8;line=sr-z-yMngm271wI73zx7gmx0Cq.7Cc-
> 039Sz4Rxz5kezbQWOtUMn-9yTjcWODXoTC9BzK**>
> Record-Route: <sip:127.0.0.8;line=sr-z-yMngmS0-R4LCz2LtZ-Lg02L-
> JoLNQGn3057t0SntZ5LNL2QD7Vz12-sjkSTtMxTiB.7Cc-
> 0399LtUqzgSGnCQx0gQ56gLG6g0wn5UILt2NziWIO3ooTDcHdDZ*>
> Record-Route: <sip:127.0.0.8;line=sr-z-yMngm271wI73zx7gmx0Nm.
> 7Cc5039Sz4Rxz5kezbQWOtUMn-9yTjcWODXoTC9BzK**>
> Record-Route: <sip:127.0.0.8;line=sr-z-yMngm271wI7CJx0gZx73Q.
> 7Cc50C9I0goedg9Bzgoedg94OiRbvEynTR7EFm0wFSOZQCOsOiGQs3EIzyUMTi7jnD7qzmWjn-
> UVT3SwTiJx7NLo0Q**>
> Record-Route: <sip:127.0.0.1:5071;r2=on;lr=on;ftag=
> YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;did=8de.7651>
> Record-Route: <sip:127.0.0.1:5070;lr=on;ftag=
> YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;did=8de.01b2>
> Record-Route: <sip:127.0.0.1:5069;r2=on;lr=on;ftag=
> YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;vsf=AAABAAAIMDE-;
> did=8de.d821>
> Record-Route: <sip:192.168.2.9:5069;r2=on;lr=on;ftag=
> YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;vsf=AAABAAAIMDE-;
> did=8de.d821>
> From: "Door" <sip:u1@192.168.2.101> <sip:u1@192.168.2.101>;tag=
> YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW
> To: <sip:004540294...@scantron.viptel.dk:5070>
> <sip:004540294...@scantron.viptel.dk:5070>;tag=1865008112
> Call-ID: ou8V0cLHn.P7Oca-pgsnMmrWO43kIQX8
> CSeq: 5778 INVITE
> Contact: <sip:127.0.0.8;line=sr-z-yMnrBS7CQM0gqS0CQ2Q3m27FwI73qx
> 0CQo6gJSngJM7gcHODXPdb7Md5XSvjEqzc**>
> Allow: INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,
> UPDATE
> P-AS-Response: 40294149
> Content-Type: application/sdp
> Content-Length: 499
> Message Body
>
> *OK (Without 5070)*
>
> No. Time   SourceDestination
> Protocol Length Info
> 373 21:44:42.955075127.0.0.1 127.0.0.1
> SIP/SDP  2199   Status: 200 OK |
>
> Frame 373: 2199 bytes on wire (17592 bits), 2199 bytes captured (17592
> bits)
> Linux cooked capture
> Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
> User Datagram Protocol, Src Port: 5071, Dst Port: 5069
> Session Initiation Protocol (200)
> Status-Line: SIP/2.0 200 OK
> Message Header
> Via: SIP/2.0/UDP 127.0.0.1:5069;rport=5069;branch=z9hG4bKeea.
> 431611add9dee6ae89135983a85d3021.0
> Via: SIP/2.0/UDP 192.168.2.101:10120;received=
> 192.168.2.101;rport=10120;branch=z9hG4bKPjXjzYAzDU-AJ9ug6mWhSQVI4gwRomuejk
> Record-Route: <sip:127.0.0.8;line=sr-z-
> yMngm271wI73zx7gmx0Cm

[SR-Users] no corresponding socket found for

[Kjeld Flarup]

BAAAIMDE-;did=ea4.7dd2>
    From: "Door" 
<sip:u1@192.168.2.101>;tag=sJQFliIRYoYobikO47pCVGUi7HH0KxiP

    To: <sip:004540294...@scantron.viptel.dk:5070>;tag=1402236088
    Call-ID: 31a27HAVA7aFhLaX9uZkBxHu31OEZqOz
    CSeq: 9542 INVITE
    Contact: 
<sip:127.0.0.8;line=sr-z-yMnrBS7CQM0gqS0CQ2Q3m27FwI73qx0CQo6gJSngJM7gcHODXPdb7Md5XSvjEqzc**>
    Allow: 
INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,UPDATE

    P-AS-Response: 40294149
    Content-Type: application/sdp
    Content-Length: 500
    Message Body

Somehow it must be the contents in the 200 Ok package, but I really cant 
se any significant difference.


Anybody knows what that message is caused by?

--
 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

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

Re: [SR-Users] Calling a mobile SIP client, which needs to update the registration

[Kjeld Flarup]

Perhaps this presentation can be of inspiration.

You would need to branch Your call if You have more destinations.

A simpler approach which I use is to loop for some seconds after sending 
the push, and see if the registration shows up in the location table.


 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 04/09/2018 09:36 AM, Igor Olhovskiy wrote:

Look at https://www.kamailio.org/docs/modules/5.0.x/modules/tsilo.html

Regards, Igor

On Apr 9, 2018, 9:44 AM +0300, Ulrich Henning <hulr...@telba.de>, wrote:


Hi everybody,

I am trying to call a sip client on a mobile cellphone, which is 
registered fine at my Kamailio instance. Everything is working fine 
if the phone is awake and the mobile app is not sleeping (e.g. energy 
saving by OS). If the device is sleeping, the cellphone gets a wakeup 
request call via apple push kit and wakes the app. Currently my app 
is doing a Register after each wakeup, because the device does not 
know if the cellular network changed (external IPv4 address with 
Carrier Grade NAT).


At this point an incoming call already got routed to any existing 
user registrations in userloc db. In this case, if the cellular 
provided network address changed, the sip client on the device won’t 
receive any invite of this last call. Instead all last known 
Contact-URIs are tried to be called until this sip invite times out 
because no response message is received back in time.


I tried to delay the incoming invite message, but this doesn’t seem 
the right way to go, since I can’t know if the mobile device is 
actually reachable and this method would potentially delay every call.


What is the best approach to solve this issue? I am looking forward 
for any comment or suggestion.


BR,

Henning

___
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

Re: [SR-Users] htable not visible in another thread

[Kjeld Flarup]

Thanks for the clarification.

I just was confused by the db_url parameter in the configuration.

And that also explains why it didn't work for me, because I have two 
Kamailio's running in my setup, and the other thread was on another 
kamailio.


I found a way to make both threads run on the same Kamailio.

 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 03/22/2018 09:58 AM, Daniel-Constantin Mierla wrote:

Hello,

htable is not writing to database at runtime, keeps everything in
memory. You should use kamctl rpc htable.dump ... in order to see what
is inside a htable.

Cheers,
Daniel


On 19.03.18 23:45, Kjeld Flarup wrote:

Im trying to do a t_suspend, but cant get htable to work

I save to $sht

$sht(vtp=>join::$rU) = "" + $T(id_index) + ":" + $T(id_label);
xlog( "L_ALERT", "Suspended transaction sht(vtp=>join::$rU) =
[$sht(vtp=>join::$rU)]\n" );

     Mar 19 23:36:28 raspberrypi /usr/sbin/kamailio[2167]: ALERT:

Re: [SR-Users] Push and tcpconn_main_timeout

[Kjeld Flarup]

Thanks for Your suggestion. I'm however not sure that it will solve the 
problem which is a TCP connection problem.


I solved the issue by sending the call back to the kamailio which 
handles the registrations, and just let the other kamailio's do the 
topoh module.


 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 03/22/2018 10:24 AM, Daniel Tryba wrote:

On Wed, Mar 21, 2018 at 07:44:50PM +0100, Kjeld Flarup wrote:

My own fault

Because I needed to be able to forward the call to multiple GSM numbers at
the same voip provider, I split the call onto several instances of Kamalio
to be able to create new call id's

As a result, the registers were made on one instance, and the invites on
another. That apparently worked fine most of the time, because Kamailio is a
proxy.

You maybe could fix this by using the Path module by storing the
proxy/registrar that received the call. If the endpoint registers
directly you might have to create your on path headers before save()
(atleast that was my conclusion for 4.3).


___
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] Push and tcpconn_main_timeout

[Kjeld Flarup]

My own fault

Because I needed to be able to forward the call to multiple GSM numbers 
at the same voip provider, I split the call onto several instances of 
Kamalio to be able to create new call id's


As a result, the registers were made on one instance, and the invites on 
another. That apparently worked fine most of the time, because Kamailio 
is a proxy.



 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 03/19/2018 10:09 PM, Kjeld Flarup wrote:


I got a bit wiser on my problem.

It seems that the sequence of events matters.

I have a PBX which should send the call to the App. If the App does 
not respond within three seconds, the call should be forwarded to a 
GSM number.


I have two scenarios, this one works:

 1. PBX gets call
 2. App registers
 3. PBX sends invite
 4. App rings

This fails

 1. PBX gets call
 2. PBX sends a push
 3. App registers
 4. PBX generates tcpconn_main_timeout or handle_tcpconn_ev on connect
to App

I'm using a simple loop to wait for the registration (I got plenty of 
ressources!)


The obvious difference is that in the failing scenario, the call is in 
progress when the register arrives.


I do  not use the technique with t_suspend. Would that make a difference?

We are using TCP. We have tried with UDP, and then the Invite is send 
to the App.



 Med Liberalistiske Hilsner --
Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
Den ikke akademiske hjemmeside for liberalismen -www.liberalismen.dk

On 03/19/2018 05:57 PM, Daniel Tryba wrote:

On Mon, Mar 19, 2018 at 04:23:01PM +0100, Kjeld Flarup wrote:

Interesting

Just to be sure that I understand You correctly.
When a Register is done, then an Invite, must create a new TCP connection.

That is not what I tried to say. All I wanted to say was:

uac ipA:portX -> syn -> server ipB:5060
uac ipA:portX <- syn-ack <- server ipB:5060
uac ipA:portX -> ack -> server ipB:5060
uac ipA:portX <->   server ipB:5060

Whether the uac is behind NAT or not, it is impossible to recreate the
connection between ipA:portX and ipB:5060 if there is ever a network
interruption.

Atleast that used to be true before SO_REUSEPORT support in kernels so
maybe the uac may be capable to reconnect with the same port, but it is
definitly impossible for the server to do this since there is simply no
listener to connect to.
  

I agree, that a perfect implementetion would be to keep the TCP stream up
while the client is connected, and use that connection for all
communication between the two stacks.

How about reregisters can they reuse the connection? Or should the
connection be closed once the packet is consumed?

This is all up to the endpoint, but having a DNS based loadbalancing
setup (SRV records, round robin A records) may have an influence.

Most clients I have seen sofar will simply reuse an existing TCP
connection for both INVITEs and re-REGISTERs. Clients with decend
NAPTR/SRV implementation will probably query DNS and iterate over the
available servers (with hopefuly 1 per server).

Kamailio will just reuse an existing connection as far as I have seen.


___
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] htable not visible in another thread

[Kjeld Flarup]

Im trying to do a t_suspend, but cant get htable to work

I save to $sht

$sht(vtp=>join::$rU) = "" + $T(id_index) + ":" + $T(id_label);
xlog( "L_ALERT", "Suspended transaction sht(vtp=>join::$rU) = 
[$sht(vtp=>join::$rU)]\n" );


    Mar 19 23:36:28 raspberrypi /usr/sbin/kamailio[2167]: ALERT: 

[SR-Users] Push and tcpconn_main_timeout

[Kjeld Flarup]

I got a bit wiser on my problem.

It seems that the sequence of events matters.

I have a PBX which should send the call to the App. If the App does not 
respond within three seconds, the call should be forwarded to a GSM number.


I have two scenarios, this one works:

1. PBX gets call
2. App registers
3. PBX sends invite
4. App rings

This fails

1. PBX gets call
2. PBX sends a push
3. App registers
4. PBX generates tcpconn_main_timeout or handle_tcpconn_ev on connect
   to App

I'm using a simple loop to wait for the registration (I got plenty of 
ressources!)


The obvious difference is that in the failing scenario, the call is in 
progress when the register arrives.


I do  not use the technique with t_suspend. Would that make a difference?

We are using TCP. We have tried with UDP, and then the Invite is send to 
the App.



 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 03/19/2018 05:57 PM, Daniel Tryba wrote:

On Mon, Mar 19, 2018 at 04:23:01PM +0100, Kjeld Flarup wrote:

Interesting

Just to be sure that I understand You correctly.
When a Register is done, then an Invite, must create a new TCP connection.

That is not what I tried to say. All I wanted to say was:

uac ipA:portX -> syn -> server ipB:5060
uac ipA:portX <- syn-ack <- server ipB:5060
uac ipA:portX -> ack -> server ipB:5060
uac ipA:portX <->   server ipB:5060

Whether the uac is behind NAT or not, it is impossible to recreate the
connection between ipA:portX and ipB:5060 if there is ever a network
interruption.

Atleast that used to be true before SO_REUSEPORT support in kernels so
maybe the uac may be capable to reconnect with the same port, but it is
definitly impossible for the server to do this since there is simply no
listener to connect to.
  

I agree, that a perfect implementetion would be to keep the TCP stream up
while the client is connected, and use that connection for all
communication between the two stacks.

How about reregisters can they reuse the connection? Or should the
connection be closed once the packet is consumed?

This is all up to the endpoint, but having a DNS based loadbalancing
setup (SRV records, round robin A records) may have an influence.

Most clients I have seen sofar will simply reuse an existing TCP
connection for both INVITEs and re-REGISTERs. Clients with decend
NAPTR/SRV implementation will probably query DNS and iterate over the
available servers (with hopefuly 1 per server).

Kamailio will just reuse an existing connection as far as I have seen.


___
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] tcpconn_main_timeout

[Kjeld Flarup]

Interesting

Just to be sure that I understand You correctly.
When a Register is done, then an Invite, must create a new TCP connection.

I agree, that a perfect implementetion would be to keep the TCP stream up
while the client is connected, and use that connection for all
communication between the two stacks.

How about reregisters can they reuse the connection? Or should the
connection be closed once the packet is consumed?

2018-03-19 13:47 GMT+01:00 Daniel Tryba <d.tr...@pocos.nl>:

> On Sun, Mar 18, 2018 at 12:59:28PM +0100, Kjeld Flarup wrote:
> > Does this mean that Kamailio doesn't reuse this connection, and instead
> > tries to establish a new one.
> >
> > And is it possible to have two concurrent connections, especially when
> it is
> > trying to send an invite to a client behind NAT.
>
> It is impossible for a listener to reuse/reconnect a TCP connection even
> without NAT (a listener can only reuse the ip/port it was listening on).
> This is the main drawback of SIP over TCP with a REGISTERing endpoint
> IMHO.
>
> ___
> 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] tcpconn_main_timeout

[Kjeld Flarup]

We are developing an app with a pjsip client.

I see this error when trying to send an invite from kamailio.

Mar 17 00:29:46 raspberrypi /usr/sbin/kamailio[18720]: ERROR:  
[tcp_main.c:4258]: tcpconn_main_timeout(): connect 62.44.134.85:43829 
failed (timeout)


A few seconds before 62.44.134.85:43829 did a register.

I can understand that either the TCP connection was close by the other 
end or no one is listening.


How much can I see in a pcap from this scenario? I cannot see the 
invite, but somehow there must be some TCP communication to show what is 
failing.




--
 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk


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

Re: [SR-Users] IOS 10 and SIP

[Kjeld Flarup]

Thanks Frederico

Thanks for that. The Tsilo module simplifies this a lot.

One thing I still see as a challenge is in the multi client scenario, 
where we may have a plain SIP phone, an IOS and an Android. How to 
manage which push to enable, or do we always try to push.



Med venlig hilsen / Best regards
Kjeld Flarup (Christensen) M.Sc E.E, Teknisk chef
Viptel ApS, Hammershusvej 16C, DK-7400 Herning
Telefon: +45 46949949, Telefax: +45 46949950, http://viptel.dk

On 2017-06-30 14:31, Federico Cabiddu wrote:

Hi,
good news: you can easily handle this scenario with Kamailio!
If you want to have an overall view of VoIP you can have 
a look at this speech I gave at Kamailio World 2015: 
https://www.youtube.com/watch?v=4XIrR9bwUkM 
<https://www.youtube.com/watch?v=4XIrR9bwUkM>.
And the slides: 
https://www.kamailio.org/events/2015-KamailioWorld/Day2/20-Federico.Cabiddu-Kamailio-In-A-Mobile-World.pdf 
<https://www.kamailio.org/events/2015-KamailioWorld/Day2/20-Federico.Cabiddu-Kamailio-In-A-Mobile-World.pdf>.


Cheers,

Federico

On Fri, Jun 30, 2017 at 2:07 PM, Kjeld Flarup <k...@viptel.dk 
<mailto:k...@viptel.dk>> wrote:


Rumours is that Apple no longer accepts apps which can do
persistent connections in the background.

To my best knowledge that means that IOS no longer supports SIP
incoming calls.
The app should now use Push Notifications, but SIP does not
support this.

Anybody faced this problem?

Is the solution to call an external program when processing an
Invite? This leaves some issues.

1. Should we wait some seconds before proceeding or wait until the
Push notification has been processed, to give the app time to
register.
We cannot start to send invites, before we have a correct
registration. An old registration may change ports when the app
wakes up and makes a new register via NAT.

2. How do we know, if a given user should have a push notification?

3. Which information do we need to be able to send the push
notification?

4. Does this give a penalty to Android users, because we have to
wait for IOS?



-- 
Med venlig hilsen / Best regards

Kjeld Flarup (Christensen) M.Sc E.E, Teknisk chef
Viptel ApS, Hammershusvej 16C, DK-7400 Herning
Telefon: +45 46949949 <tel:%2B45%2046949949>, Telefax: +45
46949950 <tel:%2B45%2046949950>, http://viptel.dk


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org <mailto: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>




___
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] IOS 10 and SIP

[Kjeld Flarup]

Rumours is that Apple no longer accepts apps which can do persistent 
connections in the background.


To my best knowledge that means that IOS no longer supports SIP incoming 
calls.

The app should now use Push Notifications, but SIP does not support this.

Anybody faced this problem?

Is the solution to call an external program when processing an Invite? 
This leaves some issues.


1. Should we wait some seconds before proceeding or wait until the Push 
notification has been processed, to give the app time to register.
We cannot start to send invites, before we have a correct registration. 
An old registration may change ports when the app wakes up and makes a 
new register via NAT.


2. How do we know, if a given user should have a push notification?

3. Which information do we need to be able to send the push notification?

4. Does this give a penalty to Android users, because we have to wait 
for IOS?




--
Med venlig hilsen / Best regards
Kjeld Flarup (Christensen) M.Sc E.E, Teknisk chef
Viptel ApS, Hammershusvej 16C, DK-7400 Herning
Telefon: +45 46949949, Telefax: +45 46949950, http://viptel.dk


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