Is the adtran setup as an unmanaged gateway and on the same network as sipx? If so that would be the correct configuration.
-- ~~~~~~~~~~~~~~~~~~ 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! On Sep 25, 2012 12:16 PM, "Jeff Pyle" <[email protected]> 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<http://list.sipfoundry.org/archive/sipx-users/msg41614.html>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 [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/ > -- 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/
