Thanks. It would appear (to me) that enabling nat confuses the transaction which thinks during an attended transfer that the gateway or phone is actually behind a nat endpoint, when it is not. It makes no difference that the UA and the gateway/sip server is on a different subnet, as long as it is routed and not nat'ted, which you have stated these are not behind nat, and I believe you.
Thanks for the JIRA. On Tue, Sep 25, 2012 at 1:45 PM, Jeff Pyle <[email protected]> wrote: > Tony, > > I've tried all the combinations of these two options. It's the "Enable NAT > Traversal" one that breaks the attended transfer. At this time that's the > only call flow I've seen trouble with, but I haven't tried that many either. > > I'll include this info on the jira. > > > - Jeff > > > > On Tue, Sep 25, 2012 at 12:44 PM, Tony Graziano > <[email protected]> wrote: >> >> 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/ > > > > _______________________________________________ > 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/
