Hi Bob, Thanks for the clarification.
First of all, I forgot to say, that when I call from home from 192.168.11.34 to the sipx AA or VM, I can hear announcement. (Call-id OTE2YmExZGUyMjhkYWVlOTVjZWZlN2Y3YTk3MTFiY2E. in the file attached to my previous mail). That's why I think, that port forwarding on my office nat/router (30000 - 30500 from external to internal sipx ip) works ok. And looking at the call OTE2YmExZGUyMjhkYWVlOTVjZWZlN2Y3YTk3MTFiY2E., (where I heard the AA announcement) I see, that the same SDP substitution occurs. (And as far as I understand now, this is the way how "far-end-nat-traversal-assist" works. Right?) Regarding my eyebeam configuration: "use local address" is set, but "enable ice" is turned on. I'll try to disable it and if problem will still persist, I'll take tcpdump and snapshot. Anyway I'll let you know about the result. Thanks again, Nikolay. _____ From: Robert Joly [mailto:[email protected]] Sent: Monday, March 30, 2009 5:54 PM To: Nikolay Kondratyev; [email protected] Subject: RE: [sipX-dev] remote workers: problem with voice Hi Nikolay, First of all, thanks for providing that level of details. I took a look at your debug logs and here are my observations. When you make the call from your Eyebeam outside of the VPN, the sipXproxy detects that this Eyebeam is behind a remote NAT. More specifically, it sees that the configured IP address of the Eyebeam is 192.168.11.34 but it is is behind a NAT whose public IP is 91.77.13.212. When the a call is made by Eyebeam to the Yates box, the NAT traversal feature knows that there are at least one NAT between them, as such, thus these endpoints cannot stream media directly to each other. To allow media to flow between the two endpoints, sipXecs needs to insert a media relay in the middle of the RTP flow. That media relay will dynamically learn the port translations created by the NAT for the media session and will start relaying packets to reachable IP:ports. This is a long-winded way of saying that, given the location of the Eyebeam, it is expected behavior that sipXecs will go in an change the SDP. Having said that, you are still faced with speech path issues. I looked at your sipXecs configuration and it appears to be fine however there are a couple of things I would want you to check: 1- The SDP I'm getting from your eyebeam suggest that you have ICE enabled. if you rely on sipXecs to handle your NAT traversal, you need to disable any NAT-traversal-assist at the phones as those can conflict. Please check the Eyebeam configuration to ensure that 'Enable ICE' is turned off and that that your address is set to 'Use local address'. 2- Have you opened the media ports used by the sipXecs NAT traversal feature on your firewall? More specifically, the range of ports 30000 to 30500 is used to relay media of endpoints that cannot stream to each other directly. In order for this to work, you need to open the 30000-30500 UDP port range on your firewall and configure port forwarding rules to send traffic received on those ports to sipXecs's private IP address (172.23.19.5). If you have done those things and you are still faced with speech path issues, please take a tcpdump of the call on your sipXecs box and send it to me. When you do, please specify the 'any' interface, using '-i any' so that I can see the interprocess communication. Here's the tcpdump command I normally use: tcpdump -n -nn -s 0 -i any w mycapture.cap cheers, bob _____ From: [email protected] [mailto:[email protected]] On Behalf Of Nikolay Kondratyev Sent: Monday, March 30, 2009 3:06 AM To: [email protected] Subject: [sipX-dev] remote workers: problem with voice Hi all, I found the following problem on my test sipx (015027) machine: under certain circumstances there is no voice for remote worker. Here is the detailed description of my setup: I use YATE (http://yate.null.ro) as h323-sip gateway between my sipx and avaya ip office (due to some problems with sip in avaya). YATE is configured to relay media. And YATE is running on the same machine as sipx, but uses port 5059 for sip, and ports 16384 - 18000 for rtp. Sipx has dns name sipx3.lab.nstel.ru and ip address 172.23.19.5 (/24). Network 172.23.0.0/16 is declared local (intranet) for sipx. Intranet domains are *.sipx3.lab.nstel.ru *.yate.lab.nstel.ru Remote workers can either use vpn connection, which does not differ much from local users, or use sipx nat traversal feature. External (nat'ed into internal) ip address is 81.211.30.104 and is named vpn.nstel.ru in the external dns. When a user dials 9 and 7digits the call is routed to yate and then to pstn. The problem is that: When user 3853 (eyebeam), registered trough vpn (Contact: <sip:[email protected]:51860;transport=TCP>), dials 96414045 the call is set up and voice is ok. Call-id MTQ3ODFjZDBmNGFiOTliNWFmMDZjNTFhYjVlZTAyZTA. in the attached merged.xml file. But when the same user is registered using nat-traversal, and dialing the same number, the call is set up, but there is no voice. Call-id NGVlMWUzY2RkMDA1M2ViMTEzYTc0N2RjYTRhODU2MzQ. in the attached merged.xml file. My analysis of the problem is that, in the second (problematic) case, sipxproxy substitutes media ports when forwarding Invite (frames 26 and 41 in the merged.xml) and 200 Ok (frames 44,47) messages. Such substitution does not occur in the first case, and, I believe, should not occur in the second case. I think that it is the cause of my problem. Can somebody please verify if my analysis is correct? Is it a bug, or a configuration problem? The whole snapshot is available at ftp://sipx:[email protected]/sipx-configuration-sipx3.lab.nstel.ru.tar.gz Thanks and regards, Nikolay.
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
