Then other than ensuring the intranet subnet is listed (i'm sure it is), this is only happening on attended transfer? you can disable server behind nat and enable nat traversal, i'm not certain it would change things but I guess it would be worth a try to see if the call can complete.
On Tue, Sep 25, 2012 at 12:37 PM, Jeff Pyle <[email protected]> wrote: > Tony, > > Yes, and yes. > > > - Jeff > > > On Tue, Sep 25, 2012 at 12:26 PM, Tony Graziano > <[email protected]> wrote: >> >> 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 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/ >> >> >> 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/ > > > > _______________________________________________ > 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/
