[OpenSIPS-Users] locally generated replies
Hi Guys, How's it possible locally generated replied triggering on_reply_route ? I ran in to issue where all opensips process gets stuck in processing same call replies and causing other traffic to get drop. /usr/sbin/opensips[27464]: Call: Reply from a NAT endpoint - S=408 D=Request Timeout F=sip:xxx@xxx T=sip:yyy yy@x IP=a.b.c.d ID=asgasgasgas Request process by opensips before this is an ACK request belong to the call where I don't think It'll expect a reply. Could it be an issue If I call t_on_reply on an ACK msg ? I'm trying to figure out where the bug in my opensips routing script. It causes all sip listerner processes to get stuck in a loop causing to generate above message. IP a.b.c.d is the sip server IP which confuse me as locally generated replies shouldn't trigger on_reply_route as per docs. Any clue is welcome. I'm using opensips 2.3.6 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Mid-Registrar REGISTER with Auth header
Hello Everyone,
When REGISTER with Auth header ( registration update ) is send out contact
header is not rewritten. Is this normal behavior ?
Mid-Registrar is operation mode 2
REGISTRAR module
loadmodule "mid_registrar.so"
modparam("mid_registrar", "mode", 2)
modparam("mid_registrar", "received_avp", "$avp(RECEIVED)")
modparam("mid_registrar", "max_contacts", 10)
modparam("mid_registrar", "tcp_persistent_flag", "TCP_PERSIST_REGISTRATIONS")
modparam("mid_registrar", "outgoing_expires", 7200)
2019/02/12 20:05:47.343433 10.30.100.41:5060 -> 10.30.100.49:5160
REGISTER sip:domain.com:5160 SIP/2.0
Via: SIP/2.0/UDP 10.30.100.41:5060;branch=z9hG4bKdc87.52e497f3.0;i=6d42cd15
Via: SIP/2.0/TLS
192.168.1.58:5070;received=186.146.92.92;branch=z9hG4bK687754333;rport=48658;alias
Route:
From: ;tag=1228599454
To:
Call-ID: 943618234-507...@bjc.bgi.b.fi
CSeq: 2004 REGISTER
Contact:
;reg-id=6;+sip.instance=""
Authorization: Digest username="106", realm="domain.com",
nonce="0f668738-a4cd-4ede-9767-51439035aad0", uri="sip:domain.com:5160",
response="27d5335eb36c0f0c
6c6d62c6f564fe", algorithm=MD5, cnonce="01204462", qop=auth, nc=0004
X-Grandstream-PBX: true
Max-Forwards: 69
User-Agent: Grandstream GXP2160 1.0.9.127
Expires: 180
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER,
UPDATE, MESSAGE
Content-Length: 0
Supported: path
Path: ___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] tls -> udp
Hello Using opensips 2.4.4, Phone -> tls and srtp -> opensips -> udp -> provider I have a socket on 5061 tls and a socket on 5060 udp and mhomed is one, Call arrives in opensips but is not correctly routed to the provider. Feb 12 21:20:47 ns3012072 /usr/local/opensips/sbin/opensips[7140]: DBG:tm:run_trans_callbacks: trans=0x7ff70a24dc68, callback type 4, id 1 entered Feb 12 21:20:47 ns3012072 /usr/local/opensips/sbin/opensips[7140]: DBG:dialog:dlg_update_contact: Using the same contact for dialog 0x7ff70a24bdd8 on leg 0 Feb 12 21:20:47 ns3012072 /usr/local/opensips/sbin/opensips[7140]: DBG:core:mk_proxy: doing DNS lookup... Feb 12 21:20:47 ns3012072 /usr/local/opensips/sbin/opensips[7140]: DBG:core:sip_resolvehost: no port, has proto -> do SRV lookup! Feb 12 21:20:47 ns3012072 /usr/local/opensips/sbin/opensips[7140]: DBG:core:get_record: lookup(_sips._tcp. That is logic as the provider doesn't listen on tcp. How can I force opensips to relay from tls on the phone to udp at the provider ? Small homer trace in attachment. Johan De Clercq, Managing Director Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke Tel +3256980990 - GSM +32478720104 HOMER5-5.135.140.139-00321566-2_12_2019 21_14_39.pcap Description: Binary data ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Use of multiple outgoing TCP Trunks with B2B
Hello, We have a use case with some specific requirements on the TCP connection usage by the outgoing register trunk. Requirements are imposed by the service provider and cannot be modified by us. a) Trunk must use TCP. b) There has to be a registration over an established TCP connection. c) INVITEs can be send only over established TCP connection that was previously used for successful registration. I managed to get around this limitations by using uac_registrant and b2b modules. I also set tcp_connection_lifetime=3600 to have the TCP connection open for a pretty long time between possible SIP communications. B2B module reuses TCP connection established by uac_registrant and it works so far. Now there is another limitation on this trunk and it is the number of parallel calls. We need more parallel calls then a single trunk is allowed to have. We can have additional trunks and multiply the capacity. I added additional trunk credentials to the uac_registrant DB and multiple registrations are successfully established. Here come the problems: 1) outgoing INVITE does not reuse any of the established TCP connection. Instead the new TCP connection is established. 2) Even if INVITE would reuse one of the established TCP connections the credentials used by INVITE have to match the ones that were used during the registration. Is there anything that can be done to correlate TCP connections and credentials between uac_registrant and B2B modules? In our case It would be enough to have a random pick of registered trunk with established TCP connection and relevant credentials for every forwarded INVITE to use additional capacity given by additional trunks. Thanks, Xaled ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
