date:20210113

Re: [SR-Users] BYE and TCP

2021-01-13 Thread 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, > 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  


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.

Re: [SR-Users] Source Port on TLS OPTIONS from Dispatcher

2021-01-13 Thread Daniel-Constantin Mierla

SIP transactions are decoupled from the transport layer, by specs, the
connections have to be reused for the same target ip/port.

Cheers,
Daniel

On 12.01.21 16:51, Charles Phillips wrote:
> It is my understanding that for outbound connections, subsequent
> transactions to the same destination IP:port reuse an existing TLS
> socket (if one exists) by design.  By the logs, it appears that this
> matching takes place early in the processing so there is no regard for
> a new outbound transaction that has different SNI.  Is this correct?
> Is there a way to force a new outbound TLS connection for a new
> transaction based on some other identifier? 
>
>
> - Charles Phillips
>
>
>
>
>> On Jan 11, 2021, at 9:00 AM, Charles Phillips > > wrote:
>>
>> That is what I figured was happening.  I have tried sending it back
>> to a standard routing block, but perhaps I am doing it incorrectly.
>>
>> When I try to send it back to a regular routing block I get the
>> following error:
>>
>> CRITICAL: tm [tm.c:1754]: _w_t_relay_to(): unsupported route type: 64
>>
>> Config:
>>
>> event_route[tm:local-request] {
>>     sip_trace();
>>     if(is_method("OPTIONS") && $ru =~ "pstnhub.microsoft.com
>> ") {
>>         $var(domain) = $fd;
>>         append_hf("Contact: > >\r\n");
>>         xlog("L_INFO", “TEAMS Contact: $var(domain)\r\n");
>>         route(TEAMS_SEND);
>>     }
>>     xlog("L_INFO", "Sent out tm request: $mb\n");
>> }
>>
>> route[TEAMS_SEND] {
>>     $var(domain) = $fd;
>>     $xavp(tls=>server_name) = $var(domain);
>>     $xavp(tls[0]=>server_id) = $var(domain);
>>     $du = "sip:$var(domain):5061;transport=tls
>> "; 
>>     t_relay();
>> }
>>
>>
>> For testing, I also tried generating the packets in a normal route
>> using t_uac_send and controlling it with rtimer.  As ugly a hack that
>> this approach is, it did manage to create the packets and set the
>> xavp as required (although, it certainly wouldn’t help dispatcher
>> know if a gateway is offline…).  Additional trouble is that if a
>> second domain attempts to send OPTIONS packets in the while loop (see
>> below) it goes out the same TLS connection, so it is rejected.
>>
>> Config:
>>
>> route["PING-TEAMS"] {
>>     sql_query("db", "select domain from domain;", "domain_list");
>>     $var(i) = 0;
>>     while ($dbr(domain_list=>[$var(i),0]) != $null) {
>>         $var(domain) = $dbr(domain_list=>[$var(i),0]);
>>         xlog(“OPTIONS from domain name $var(domain)");
>>         $xavp(tls=>server_name) = $var(domain);
>>         $xavp(tls[0]=>server_id) = $var(domain);
>>         $du = "sip:$var(domain):5061;transport=tls
>> "; 
>>         t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls
>> ", 
>> "sip:sip3.pstnhub.microsoft.com;transport=tls
>> ", "", "From:
>> sip:$var(domain) \r\nTo:
>> sip:sip3.pstnhub.microsoft.com;transport=tls
>> \r\nContact:
>> > >\r\n", "");
>>         sleep(2);
>>         t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls
>> ", 
>> "sip:sip2.pstnhub.microsoft.com;transport=tls
>> ", "", "From:
>> sip:$var(domain) \r\nTo:
>> sip:sip2.pstnhub.microsoft.com;transport=tls
>> \r\nContact:
>> > >\r\n", "");
>>         sleep(2);
>>         t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls
>> ", 
>> "sip:sip.pstnhub.microsoft.com;transport=tls
>> ", "", "From:
>> sip:$var(domain) \r\nTo:
>> sip:sip.pstnhub.microsoft.com;transport=tls
>> \r\nContact:
>> > >\r\n", "");
>>         sleep(5);
>>         $var(i) = $var(i) + 1; 
>>                
>>     }
>> }
>>
>> 200 from MS on domain 0:
>>
>> 2021/01/11 08:48:31.291048 52.114.7.24:5061 -> *myip*:52606
>> SIP/2.0 200 OK
>> FROM: > >;tag=3393f0703fb0ccaca74109ff37de39f5-5a503a0a
>> TO: >
>> CSEQ: 10 OPTIONS
>> CALL-ID: 0f37a09f409a4e41-24410@127.0.0.1
>> 
>> VIA: SIP/2.0/TLS
>> *myip*:5061;branch=z9hG4bK9306.42d92227.0
>> CONTENT-LENGTH: 0
>> ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
>> SERVER: Microsoft.PSTNHub.SIPProxy v.2020.12.28.1 i.ASEA.0
>>
>>
>> 403 from MS on domain 1:
>>
>> 2021/01/11 08:49:39.755005 52.114.7.24:5061 -> *myip*:52606
>> SIP/2.0 403 Forbidden
>> FROM: > >;tag=3393f0703fb0ccaca74109ff37de39f5-69555a28
>> TO: >
>> CSEQ: 10 OPTIONS
>> CALL-ID: 0f37a09f409a4e44-24410@127.0.0.1
>> 
>> VIA: SIP/2.0/TLS
>> *myip*:5061;branch=z9hG4bK4306.973e1562.0
>> REASON:
>> Q.850;cause=63;text="00cce062-66c6-45a4-8b5c-ccd48b71a9f6;Provided
>> Trunk FQDN '101.sbc.*mydomain*.net' is not allowed. Connection allows
>> ollowing fqdns: 100.sbc.*mydomain*.net, 100.sbc.*mydomain*.net."
>> CONTENT-LENGTH: 0
>> ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
>> SERVER: Microsoft.PSTNHub.SIPProxy v.2020.12.28.1 i.ASEA.0
>>
>>
>>
>> - Charles Phillips
>>
>>
>>
>>
>>> On Jan 11, 2021, at 4:13 AM, Daniel-Constantin Mierla
>>> mailto:mico...@gmail.com>> wrote:
>>>
>>> Hello,
>>>
>>> the

Re: [SR-Users] Source Port on TLS OPTIONS from Dispatcher

2021-01-13 Thread Daniel-Constantin Mierla

It doesn't work to use t_relay() in event_route[tm:local-request] (and
executed sub-routes), because it is already processing a relayed local
request. That's why you get the error. Just set the $du and then exit,
or set the outbound proxy attribute in the dispatcher record.

Also, setting the tls-related xavps does not have effect.

Cheers,
Daniel

On 11.01.21 15:00, Charles Phillips wrote:
> That is what I figured was happening.  I have tried sending it back to
> a standard routing block, but perhaps I am doing it incorrectly.
>
> When I try to send it back to a regular routing block I get the
> following error:
>
> CRITICAL: tm [tm.c:1754]: _w_t_relay_to(): unsupported route type: 64
>
> Config:
>
> event_route[tm:local-request] {
>     sip_trace();
>     if(is_method("OPTIONS") && $ru =~ "pstnhub.microsoft.com
> ") {
>         $var(domain) = $fd;
>         append_hf("Contact:  >\r\n");
>         xlog("L_INFO", “TEAMS Contact: $var(domain)\r\n");
>         route(TEAMS_SEND);
>     }
>     xlog("L_INFO", "Sent out tm request: $mb\n");
> }
>
> route[TEAMS_SEND] {
>     $var(domain) = $fd;
>     $xavp(tls=>server_name) = $var(domain);
>     $xavp(tls[0]=>server_id) = $var(domain);
>     $du = "sip:$var(domain):5061;transport=tls
> "; 
>     t_relay();
> }
>
>
> For testing, I also tried generating the packets in a normal route
> using t_uac_send and controlling it with rtimer.  As ugly a hack that
> this approach is, it did manage to create the packets and set the xavp
> as required (although, it certainly wouldn’t help dispatcher know if a
> gateway is offline…).  Additional trouble is that if a second domain
> attempts to send OPTIONS packets in the while loop (see below) it goes
> out the same TLS connection, so it is rejected.
>
> Config:
>
> route["PING-TEAMS"] {
>     sql_query("db", "select domain from domain;", "domain_list");
>     $var(i) = 0;
>     while ($dbr(domain_list=>[$var(i),0]) != $null) {
>         $var(domain) = $dbr(domain_list=>[$var(i),0]);
>         xlog(“OPTIONS from domain name $var(domain)");
>         $xavp(tls=>server_name) = $var(domain);
>         $xavp(tls[0]=>server_id) = $var(domain);
>         $du = "sip:$var(domain):5061;transport=tls
> "; 
>         t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls
> ", 
> "sip:sip3.pstnhub.microsoft.com;transport=tls
> ", "", "From:
> sip:$var(domain) \r\nTo:
> sip:sip3.pstnhub.microsoft.com;transport=tls
> \r\nContact:
>  >\r\n", "");
>         sleep(2);
>         t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls
> ", 
> "sip:sip2.pstnhub.microsoft.com;transport=tls
> ", "", "From:
> sip:$var(domain) \r\nTo:
> sip:sip2.pstnhub.microsoft.com;transport=tls
> \r\nContact:
>  >\r\n", "");
>         sleep(2);
>         t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls
> ", 
> "sip:sip.pstnhub.microsoft.com;transport=tls
> ", "", "From:
> sip:$var(domain) \r\nTo:
> sip:sip.pstnhub.microsoft.com;transport=tls
> \r\nContact:
>  >\r\n", "");
>         sleep(5);
>         $var(i) = $var(i) + 1; 
>                
>     }
> }
>
> 200 from MS on domain 0:
>
> 2021/01/11 08:48:31.291048 52.114.7.24:5061 -> *myip*:52606
> SIP/2.0 200 OK
> FROM:  >;tag=3393f0703fb0ccaca74109ff37de39f5-5a503a0a
> TO: >
> CSEQ: 10 OPTIONS
> CALL-ID: 0f37a09f409a4e41-24410@127.0.0.1
> 
> VIA: SIP/2.0/TLS
> *myip*:5061;branch=z9hG4bK9306.42d92227.0
> CONTENT-LENGTH: 0
> ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
> SERVER: Microsoft.PSTNHub.SIPProxy v.2020.12.28.1 i.ASEA.0
>
>
> 403 from MS on domain 1:
>
> 2021/01/11 08:49:39.755005 52.114.7.24:5061 -> *myip*:52606
> SIP/2.0 403 Forbidden
> FROM:  >;tag=3393f0703fb0ccaca74109ff37de39f5-69555a28
> TO: >
> CSEQ: 10 OPTIONS
> CALL-ID: 0f37a09f409a4e44-24410@127.0.0.1
> 
> VIA: SIP/2.0/TLS
> *myip*:5061;branch=z9hG4bK4306.973e1562.0
> REASON:
> Q.850;cause=63;text="00cce062-66c6-45a4-8b5c-ccd48b71a9f6;Provided
> Trunk FQDN '101.sbc.*mydomain*.net' is not allowed. Connection allows
> ollowing fqdns: 100.sbc.*mydomain*.net, 100.sbc.*mydomain*.net."
> CONTENT-LENGTH: 0
> ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
> SERVER: Microsoft.PSTNHub.SIPProxy v.2020.12.28.1 i.ASEA.0
>
>
>
> - Charles Phillips
>
>
>
>
>> On Jan 11, 2021, at 4:13 AM, Daniel-Constantin Mierla
>> mailto:mico...@gmail.com>> wrote:
>>
>> Hello,
>>
>> the xavp_cfg set in the event_route is not propagated (kept) to the
>> moment when the message is sent out to tls. The
>> event_route[tm:local-request] is executed when the local request is
>> constructed, terminated before sending out, so whatever avp/xavp is
>> set in the event route are deleted when the block execution is
>> terminated.
>>
>> It requires another solution here, I am thinking about what can be
>> done and will be added soon in the master branch.
>>
>> Meanwhile, a workaround is to look traffic back to

Re: [SR-Users] handling rejected REFER messages

2021-01-13 Thread Daniel-Constantin Mierla

Hello,

converting a REFER to an INVITE and sending out is not going to solve
anything. The REFER is to trigger a different call to another target,
while the invite is to renegotiate the session (eventually with a
replace indication). If the endpoints do not support REFER, then you
need SIP application servers (b2bua) like Asterisk, FreeSwich or SEMS to
handle it and initiate new calls.

Cheers,
Daniel

On 12.01.21 21:20, Jaime Gajardo wrote:
> Actually we have installed kamailio 5.4.2 and rtpengine like load
> balancer in a NAT environment. behind the nat we have 2 identical
> nodes using REFER for transfer  
> call to another destiny. On the other NAt side we have our public
> carrier.
> When some node sends to kamailio the REFER message and kamailio
> reroutes this message to the carrier. The call is rejected due company
> policies.
>
> We want to know how we can convert or modify the REFER message into
> INVITE for finally transfer the call.
>
>
> kamailio -v:
> version: kamailio 5.4.2 (x86_64/linux) 4fdc21
> flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
> F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX,
> FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
> USE_DST_BLACKLIST, HAVE_RESOLV_RES
> ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE
> 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: 4fdc21
> compiled on 20:43:45 Dec  1 2020 with unknown
>
> Uname -a:
> Linux proxy 4.15.0-124-generic #127-Ubuntu SMP Fri Nov 6 10:54:43 UTC
> 2020 x86_64 x86_64 x86_64 GNU/Linux
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

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

[SR-Users] handling rejected REFER messages

2021-01-13 Thread Jaime Gajardo

Actually we have installed kamailio 5.4.2 and rtpengine like load balancer
in a NAT environmet. behind the nat we have 2 identycal nodes using REFER
for transfer
call to another destiny. in the other NAt side we have our public carrier.
When some node send to kamailio the REFER message and kamailio reroute this
message to the carrier. The call is rejected due company policies.

We want know how can we do for convert or modify the REFER message into
INVITE for finally transfer the call.


kamailio -v:
version: kamailio 5.4.2 (x86_64/linux) 4fdc21
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE,
USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC,
TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024,
BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 4fdc21
compiled on 20:43:45 Dec  1 2020 with unknown

Uname -a:
Linux proxy 4.15.0-124-generic #127-Ubuntu SMP Fri Nov 6 10:54:43 UTC 2020
x86_64 x86_64 x86_64 GNU/Linux

rtpengine -v:
Version: 9.2.0.0+0~mr9.2.0.0 git-master-aa5e0244
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] handling rejected REFER messages

2021-01-13 Thread Jaime Gajardo

Actually we have installed kamailio 5.4.2 and rtpengine like load balancer
in a NAT environment. behind the nat we have 2 identical nodes using REFER
for transfer
call to another destiny. On the other NAt side we have our public carrier.
When some node sends to kamailio the REFER message and kamailio reroutes
this message to the carrier. The call is rejected due company policies.

We want to know how we can convert or modify the REFER message into INVITE
for finally transfer the call.


kamailio -v:
version: kamailio 5.4.2 (x86_64/linux) 4fdc21
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE,
USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC,
TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024,
BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 4fdc21
compiled on 20:43:45 Dec  1 2020 with unknown

Uname -a:
Linux proxy 4.15.0-124-generic #127-Ubuntu SMP Fri Nov 6 10:54:43 UTC 2020
x86_64 x86_64 x86_64 GNU/Linux

rtpengine -v:
Version: 9.2.0.0+0~mr9.2.0.0 git-master-aa5e0244
___
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

Re: [SR-Users] Source Port on TLS OPTIONS from Dispatcher

Re: [SR-Users] Source Port on TLS OPTIONS from Dispatcher

Re: [SR-Users] handling rejected REFER messages

[SR-Users] handling rejected REFER messages

[SR-Users] handling rejected REFER messages

6 matches

Site Navigation

Mail list logo

Footer information