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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users