By default sipx automatically assumes the following: 10.0.0.0/8 172.160.0./12 192.168.0.0/16
are on your network. If these two nodes mentioned below are on your network, just be sure the statements are correct in reflecting your actual networks and their mask, otherwise I see no foul if the networks can route or bridge to each other without nat. On Tue, Sep 25, 2012 at 12:57 PM, Joegen Baclor <[email protected]> wrote: > Jeff, > > I might be missing something but the SDP you pasted > > > o=- 1348230370 1348230371 IN IP4 172.21.201.60 > s=Polycom IP Phone > c=IN IP4 172.21.201.60 > t=0 0 > m=audio 30248 RTP/AVP 9 0 8 18 101 > c=IN IP4 192.168.54.46 > a=rtpmap:9 G722/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=rtpmap:18 G729/8000 > a=fmtp:18 annexb=no > a=rtpmap:101 telephone-event/8000 > a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54 > > > 172.21.201.60 being the original IP of the polycom > > and > > 192.168.54.46 being the IP of sipX > > I assumed that there is a firewall linking these two networks. Maybe a > packet capture and a topology description would save us the need to > speculate much :-) > > > > > On 09/26/2012 12:45 AM, Jeff Pyle wrote: > > Joegen, > > In my case all the SIP-speaking components are directly routable to each > other with no firewalls and therefore no NAT in between. I don't understand > what you mean by "sipX being behind a firewall". Is that relevant to the > NAT traversal issue you mentioned? > > > - Jeff > > > On Tue, Sep 25, 2012 at 12:42 PM, Joegen Baclor <[email protected]> wrote: >> >> >> In my configuration there is no NAT whatsoever. Is there a way to >> >> disable NAT traversal completely, thereby working around this issue for >> >> the >> >> time being? >> >> I should also add sipX being behind a firewall. >> >> >> >> On 09/26/2012 12:15 AM, Jeff Pyle wrote: >> >> Joegen, >> >> Yes, exactly. INVITE with no SDP. I'll open a tracker shortly. >> >> In my configuration there is no NAT whatsoever. Is there a way to disable >> NAT traversal completely, thereby working around this issue for the time >> being? >> >> >> - Jeff >> >> >> >> On Tue, Sep 25, 2012 at 12:09 PM, Joegen Baclor <[email protected]> wrote: >>> >>> Jeff, good bug reporting! >>> >>> By late negotiation, do you mean INVITE with no SDP? There is a known >>> issue with NAT traversal plugin not being able to handle this properly. If >>> you don't mind, please open a tracker in jira and attach packet captures. >>> >>> >>> On 09/25/2012 11:57 PM, Jeff Pyle wrote: >>> >>> Hello, >>> >>> At the end of another thread Tony suggested I try attended transfers and >>> some other parking related operations against an Adtran TA900-series >>> gateway. It seemed there had been some friction here in the past. >>> >>> I was able to test attended and unattended transfers with sipX 4.6 on an >>> Adtran TA908E. The global config option "voice transfer-mode network" is >>> required to support REFERs. Without it the results will be undesirable. >>> With that line, however, unattended transfers worked just fine >>> >>> Attended transfers yielded no audio when the transfer completed if the >>> Adtran is the C-leg of the transfer. Here's why: >>> >>> This is the SDP of the INVITE with Replaces that arrives at the Adtran >>> from sipX to wrap up the transfer: >>> >>>> v=0 >>>> o=- 1348230370 1348230370 IN IP4 172.21.201.60 >>>> s=Polycom IP Phone >>>> c=IN IP4 172.21.201.60 >>>> t=0 0 >>>> a=sendrecv >>>> m=audio 2250 RTP/AVP 9 0 8 18 101 >>>> a=rtpmap:9 G722/8000 >>>> a=rtpmap:0 PCMU/8000 >>>> a=rtpmap:8 PCMA/8000 >>>> a=rtpmap:18 G729/8000 >>>> a=fmtp:18 annexb=no >>>> a=rtpmap:101 telephone-event/8000 >>> >>> >>> This is correct, telling the Adtran to send audio to 172.21.201.60 (c= >>> line) on port 2250 (m= line). 172.21.201.60 is the IP address of the >>> Polycom who was the A-leg of the call. >>> >>> As part of some DSP cleanup ops the Adtran starts a reINVITE transaction >>> with late negotiation as soon as the above transaction is completed. The >>> offer SDP on sipX's 200 OK of that transaction looks like this: >>> >>>> v=0 >>>> o=- 1348230370 1348230371 IN IP4 172.21.201.60 >>>> s=Polycom IP Phone >>>> c=IN IP4 172.21.201.60 >>>> t=0 0 >>>> m=audio 30248 RTP/AVP 9 0 8 18 101 >>>> c=IN IP4 192.168.54.46 >>>> a=rtpmap:9 G722/8000 >>>> a=rtpmap:0 PCMU/8000 >>>> a=rtpmap:8 PCMA/8000 >>>> a=rtpmap:18 G729/8000 >>>> a=fmtp:18 annexb=no >>>> a=rtpmap:101 telephone-event/8000 >>>> a=x-sipx-ntap:X192.168.54.46-[PUBLIC-IP];54 >>> >>> >>> Notice the c= and m= lines have changed. sipX is now telling the Adtran >>> to send audio to 192.168.54.46, the IP address of the sipX instance itself. >>> This is why the A-leg Polycom at 172.21.201.60 doesn't receive any audio >>> after the transfer - sipX told the Adtran to send the audio elsewhere. >>> >>> Any idea why sipX might do that? >>> >>> As a bandaid, one can prevent the Adtran from sending the reINVITE by >>> adding "no prefer reinvite-without-sdp" to the voice trunk configured to >>> talk to sipX. This command is available only in prerelease code at the >>> moment. I believe it will be GA by the end of the month. >>> >>> >>> - Jeff >>> >>> >>> >>> >>> _______________________________________________ >>> sipx-users mailing list >>> [email protected] >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >>> >> >> > > > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ -- ~~~~~~~~~~~~~~~~~~ Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.465.6833 ~~~~~~~~~~~~~~~~~~ Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet Fax services! ~~~~~~~~~~~~~~~~~~ Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab 2013! -- LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
