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<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].**net<[email protected]> > > Helpdesk Customers: > http://myhelp.myitdepartment.**net<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/
