Robert, Thanks for help.
I agree that the problem is on YATE side (since rfc 4566 clearly says that media-level c-line must be used). I've sent a mail to yate mail-list. I hope Yate guys will fix the problem. Thanks and regards, Nikolay. _____ From: Robert Joly [mailto:[email protected]] Sent: Monday, March 30, 2009 9:24 PM To: Nikolay Kondratyev Subject: RE: [sipX-dev] remote workers: problem with voice Nikolay, You have found the problem. The issue is that Yate does not comply with the SDP specification and uses the session-level c-line when it must use the media-level one. If it did (like any of the endpoints you have successful calls with) then your call would have 2-way speech path. The RFC that describes the c-line precedence rules is 4566 section 5.7. Changing the NAT traversal code to use only a single media-level c-line is not something that I'm really interested in doing at this point for a couple of reasons: 1- sipXecs is not broken; 2- we would have to re-run all the NAT traversal interop test cases to make sure that all the functionality is preserved and that takes a lot of time and effort and would end up delaying the 4.0 release; 3- Conceptually, leaving the session-level c-line intact and applying my changes to the media is the right thing to do because it localizes the changes done by the NAT traversal feature to specific audio media session it operates on. Your best bet is to socialize your finding with the Yate guys to see if they have plans to address this issue. I'm sorry I could not provide a fix for your issue. Cheers, bob _____ From: Nikolay Kondratyev [mailto:[email protected]] Sent: Monday, March 30, 2009 12:25 PM To: Joly, Robert (CAR:9D30) Subject: RE: [sipX-dev] remote workers: problem with voice Robert, hi again. Sending this mail directly to you, because the attachment is too large for sipx mail list. I asked my colleague to make a test call from home. User 3881, sitting at home 192.168.12.201, behind nat with the external address 212.1.246.116, dials 989162413260. The call is routed to yate, then via h323 to ip office (172.23.14.2), then via isdn pri to my mobile. The call is set up, but there is no voice. I attached the trace (tcpdump -n -nn -i any -s 0 -w rem-work-yate-3). If you let me tell my idea (again :-)), I found that: Yate is trying to send rtp directly to 192.168.12.201 . for example packet 1061 in the trace. But can not do it. packet 1062 in the trace And yate does so due to the Invite (packet 432), which contains the following SDP: v=0 o=- 7 2 IN IP4 192.168.12.201 s=CounterPath eyeBeam 1.5 c=IN IP4 192.168.12.201 t=0 0 m=audio 30092 RTP/AVP 107 0 8 18 101 c=IN IP4 172.23.19.5 a=fmtp:18 annexb=yes a=fmtp:101 0-15 a=rtpmap:107 BV32/16000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv a=x-sipx-ntap:X172.23.19.5-81.211.30.104;47 That is two "c=" fields. And Yate uses the first one. What do you think? Please advise if it is ok? Who is guilty? What should I do to make it work. The calls from the same user to local phones are ok. Only calls to yate are without voice. Thanks and regards, Nikolay. _____ From: [email protected] [mailto:[email protected]] On Behalf Of Nikolay Kondratyev Sent: Monday, March 30, 2009 6:36 PM To: 'Robert Joly'; [email protected] Subject: Re: [sipX-dev] remote workers: problem with voice 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
