I see the xml trace now. the non vpn call is confusing ...
frame 23 the media invite to itsp is on m=audio 30500 RTP/AVP 0 8 101 but the itsp sends back (frame 24) m=audio 41302 RTP/AVP 0 101 and if you follow the same call from there on it seems like the media port is changing. I don't know why. (wish you could do pfsense where the filters are easier, so are pcaps). On Thu, Jul 8, 2010 at 8:39 AM, [email protected] <[email protected]>wrote: > Hi, Tony. > > Thank you very much again for your fast reply. > > May i ask you take a look at the trace that i attached already > (sipx-trace-nonvpn-call.xml) file and see how all communication between > user phone and ITSP goes? This is a call with audio problems. In this > trace user does not use vpn. He is behind NAT and using local ip > address. > > If is necessary i can send also a snapshot of the system, just let me > know. > > About OpenVPN, i will check this and see how to go. > > On Thu, 2010-07-08 at 06:11 -0400, Tony Graziano wrote: > > > > > > On Thu, Jul 8, 2010 at 4:21 AM, [email protected] > > <[email protected]> wrote: > > Hi, > > > > we have installed as you already know sipxecs behind NAT on a > > virtual > > box guest machine. You can see my expalation for our topology > > here in my > > previous topic: > > > http://forum.sipfoundry.org/index.php?t=msg&th=13717&start=0&S=60af1c90c584a680911ac1565d16b0ea > > > > Now we have problem with one way audio on outgoing calls and a > > strange > > issue related with outgoing calls when we call via VPN > > network. > > > > In the link above you will see that Tony Graziano sent to me a > > link with > > a diagram that is very useful. > > > > I think that our problem is that RTP ports used in both legs > > are > > different and probably this is an issue with iptables rules, > > but i'm i > > would like someone to confirm me this that ports are different > > and if is > > possible to help me to solve this problem. > > > > What i see in trace is that when the invite is sent to > > sipXproxy the > > audio port is one (30000), but in INVITE request from > > sipXproxy to > > sipxbridge is on different port ( 30248 ). Is that normal? > > > > In traces i see also that when the user that do the call > > receive "183 > > Session In Progress" then audio port is also different > > ( 30498 ). I > > suppose this is also wrong. Can you confirm this? > > > > To understand this, a siptrace of the call with audio problems would > > tell a lot. > > > > I attached also the iptables rules that i use right now. I > > followed Tony > > Graziano rules from his posts in my previous thread and also > > followed > > this article too: > > > > > http://sipx-wiki.calivia.com/index.php/SipXbridge_Overview_and_Configuration#Firewall.2FNAT_Configuration > > > > The other problem that we experience is related with calls > > from VPN > > network. > > > > In trace that i have attached you can see on frame 23 that ACK > > package > > is sent to user's public IP address, not to the VPN address. > > Also in > > frame 23 is added a new VIA line that is wrong and this > > totally mess up > > the cominucation between sipx and user ( using vpn ): > > Via: SIP/2.0/UDP > > 192.168.0.23:30256 > ;branch=z9hG4bK-d8754z-8375c91b95668768-1---d8754z-;rport > > Contact: <sip:[email protected]:30256> > > > > So what can be the reason for this and how to solve this > > problem? > > > > Your openvpn should "push" the domain and resolve its records > > internally. This way the softphone will register using the openvpn > > address. BUT the audio needs to follow the vpn path. The only way I > > know to get openvpn to do that is to have the client "route all > > traffic" via the vpn, at least that's what I would start with. > > > > P.S. We have these DNS records set: > > > > ; SIP > > @ IN NAPTR 10 0 "s" "SIPS+D2T" "" > > _sips._tcp.mydomain.net. > > @ IN NAPTR 20 0 "s" "SIP+D2U" "" > > _sip._udp.mydomain.net. > > @ IN NAPTR 30 0 "s" "SIP+D2T" "" > > _sip._tcp.mydomain.net. > > > > ; SRV RECORDS > > > > ; SIP > > _sips._tcp IN SRV 10 0 5060 sipx.mydomain.com. > > _sip._udp IN SRV 20 0 5060 sipx.mydomain.com. > > _sip._tcp IN SRV 30 0 5060 sipx.iguanait.com. > > > > _sips._tcp IN SRV 40 0 5060 odin.mydomain.com. > > _sip._udp IN SRV 50 0 5060 odin.mydomain.com. > > _sip._tcp IN SRV 60 0 5060 odin.mydomain.com. > > > > > > odin.mydomain.com is the server with public ip address > > 87.xxx.xxx.43 > > sipx.mydomain.com is sipxecs server located behind NAt on > > virtual box. > > It has ip 10.1.1.2. > > > > In traces the real domain is changed with 'mydomain' string > > and the > > public ip address is changed to 87.xxx.xxx.43. > > > > IP: 91.2xx.xxx.17 is the user's public ip address that do the > > outgoing > > call. > > > > IP: 10.1.1.5 is user's VPN address. > > IP: 192.168.0.23 is user's private IP address from his LAN's > > DHCP > > server. > > > > The called number is: 883495466 > > > > > > _______________________________________________ > > sipx-users mailing list [email protected] > > List Archive: http://list.sipfoundry.org/archive/sipx-users > > Unsubscribe: > > http://list.sipfoundry.org/mailman/listinfo/sipx-users > > sipXecs IP PBX -- http://www.sipfoundry.org/ > > > > > > > > -- > > ====================== > > Tony Graziano, Manager > > Telephone: 434.984.8430 > > sip: [email protected] > > Fax: 434.984.8431 > > > > Email: [email protected] > > > > LAN/Telephony/Security and Control Systems Helpdesk: > > Telephone: 434.984.8426 > > sip: [email protected] > > Fax: 434.984.8427 > > > > Helpdesk Contract Customers: > > http://www.myitdepartment.net/gethelp/ > > > > Why do mathematicians always confuse Halloween and Christmas? > > Because 31 Oct = 25 Dec. > > > > > -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.984.8431 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ Why do mathematicians always confuse Halloween and Christmas? Because 31 Oct = 25 Dec.
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
