Joegen, I fully understand my network so I don't see where the problem is. :)
All the details, including an adequate topology description, are now in XX-10464 <http://track.sipfoundry.org/browse/XX-10464>. - Jeff 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<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/
