Hello, Yes. The log is for sems with mo profile. I used SEMS as sbc applications in my network. Let me paste my configurations below: #sems.conf interfaces=intern,extern
sip_ip_intern=192.168.18.20 sip_port_intern=5060 media_ip_intern=192.168.18.20 rtp_low_port_intern=2000 rtp_high_port_intern=5000
sip_ip_extern=94.182.110.10 sip_port_extern=4080 media_ip_extern=94.182.110.10 rtp_low_port_extern=2000 rtp_high_port_extern=5000 public_ip_extern=94.182.110.10 #sig_sock_opts_extern=force_via_address tcp_connect_timeout_extern=1000 tcp_idle_timeout_extern=900000 I was forced to disable "sig_sock_opts_extern" option,
#sbc.conf is like this:
profiles=refuse_with_200,register,mo,mt,refuse active_profile=$M($m=>methodmap),$M($si=>src_ipmap),refuse regex_maps=src_ipmap,methodmap
#mo profile is like this:
# defaults: transparent #RURI=$r #From=$f #To=$t #Contact=sip:$Ri #Call-ID Call-ID=$ci_leg2 ## routing # outbound proxy: #outbound_proxy=sip:192.168.5.106:5060 outbound_proxy=sip:192.168.18.19:5060
# force outbound proxy (in-dialog requests)? #force_outbound_proxy=yes force_outbound_proxy=yes
# destination IP[:port] for outgoing requests #next_hop=192.168.5.106:5060 next_hop=192.168.18.19:5060
# set RURI to (calculated) next_hop #patch_ruri_next_hop=yes # update next_hop from remote destination? (e.g. from SRV) #next_hop_fixed=yes # outbound interface to use (interface ID) outbound_interface=intern
# SIP NAT handling: recommended if dealing with far end NATs dlg_nat_handling=yes
## RTP relay # enable RTP relaying (bridging): enable_rtprelay=yes # force symmetric RTP (start with passive mode): rtprelay_force_symmetric_rtp=yes
# RTP interface to use for A leg aleg_rtprelay_interface=extern
# RTP interface to use for B leg rtprelay_interface=intern
#mt profile is like this:
#RURI=$r #From=$f #To=$t
#Contact=sip:$Ri
#Call-ID Call-ID=$ci_leg2
## routing # outbound proxy: #outbound_proxy=sip:192.168.5.106:5060 #outbound_proxy=sip:$H(P-Route) #outbound_proxy=sip:$H(P-Source-IP):$H(P-Source-Port)
# force outbound proxy (in-dialog requests)? force_outbound_proxy=yes # destination IP[:port] for outgoing requests #next_hop=192.168.5.106:5060 # set RURI to (calculated) next_hop #patch_ruri_next_hop=yes # update next_hop from remote destination? (e.g. from SRV) #next_hop_fixed=yes # outbound interface to use (interface ID) outbound_interface=extern
# SIP NAT handling: recommended if dealing with far end NATs dlg_nat_handling=yes
## RTP relay # enable RTP relaying (bridging): enable_rtprelay=yes # force symmetric RTP (start with passive mode): rtprelay_force_symmetric_rtp=yes
# RTP interface to use for A leg aleg_rtprelay_interface=intern
# RTP interface to use for B leg rtprelay_interface=extern
## filters: ## filters: header_filter=blacklist #header_list=P-App-Param,P-App-Name,P-Route,Remote-Party-ID header_list=P-Route,Remote-Party-ID,P-Source-IP,P-Source-Port
I think it is big challenge if i am dependent to NAT between the uac and SEMS (SIP ALG) when i changed default port on sbc. How can i solved this problem in this regards? Thanks. With Regards.Mojtaba
On Thu, Jan 25, 2018 at 7:31 PM, Stefan Sayer stefan.sayer@googlemail.com wrote:
Hello,
Mojtaba wrote on 24.01.2018 12:17:
Hello, I have a problem today, It's strange for me. Suppose we have this senario: uac1------->SEMS(mo profile)------->Kamailio-------->SEMS(mt profile)---------->uac2
In above topology, we have two interfaces(intern,extern) for SEMS, and just used as SBC (sbc application). if i used port=5060 as external port, every things is right and log file is like this: [#7fed3f9f9700/32820] [run, udp_trsp.cpp:352] DEBUG: vv M [|] u recvd msg via UDP from 89.165.117.125:42411 vv --++-- REGISTER sip:kava.shatel.ir;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 89.165.117.125:42411;branch=z9hG4bK-d8754z-021bd8b61efc7ac0-1---d8754z- Max-Forwards: 70 Contact: sip:4000@ 89.165.117.125:42411;rinstance=79011092e56e1a09;transport=UDP To: sip:4000@kava.shatel.ir;transport=UDP From: sip:4000@kava.shatel.ir;transport=UDP;tag=82820e1f Call-ID: Y2U4YThiYjEwNTUzMzliZTIwNWZkMDI3MTM4OTZlNWU. CSeq: 2 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri User-Agent: Z 3.3.25608 r25552 Allow-Events: presence, kpml Content-Length: 0
but when i changed port=4080 for external port, The Via header and contact header are changed to my public ip, like this:
[#7fed3f9f9700/32820] [run, udp_trsp.cpp:352] DEBUG: vv M [|] u recvd msg via UDP from 89.165.117.125:42411 vv --++-- REGISTER sip:kava.shatel.ir;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 172.1.1.125:42411;branch=z9hG4bK-d8754z-021bd8b61efc7ac0-1---d8754z- Max-Forwards: 70 Contact: sip:4000@172.1.1.125:42411;rinstance=79011092e56e1a09;transport=UDP To: sip:4000@kava.shatel.ir;transport=UDP From: sip:4000@kava.shatel.ir;transport=UDP;tag=82820e1f Call-ID: Y2U4YThiYjEwNTUzMzliZTIwNWZkMDI3MTM4OTZlNWU. CSeq: 2 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri User-Agent: Z 3.3.25608 r25552 Allow-Events: presence, kpml Content-Length: 0 Why my public ip address is there here? I just changed external port=4080 in sems server. In SDP protocol i have the same problem when i changed external ip port in sems server.
is this message log the one of the first SEMS (mo profile) which is sent by uac1? In that case it's the uac1 which puts the 172.1.1.125 IP addresses in the SIP message. Or rather: I can imagine that there's a SIP ALG on the NAT between the uac1 and SEMS, which only changes packets when the destination port is 5060.
Stefan
Thanks. --Mojtaba Esfandiari.S
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users