Hi Todd, Understandable.
We have a large, private WAN. Routers? Absolutely. Some are Cisco, some are Juniper, some are pure linux. But in no place are there are access lists, NAT, etc. All connectivity is completely open. None of the routers look any deeper than layer 3. In other words, they're just routers acting as routers, not routers acting as firewalls. The sipX system is 192.168.*54*.46, at the data center. The Adtran gateway is 192.168.*53*.11, at the business office half an hour away. The two Polycoms involved in the test are within 172.21.201.0/24, a test lab in a different county. Each network represents different physical location. (There are test devices on two other networks in two different counties not even involved in this call flow.) As complicated as that may be, none of the complexities have any bearing on sipX. As far as SIP is concerned one can consider this to be a simple single-LAN design because there are no access restrictions among the nodes. Thanks for forcing me to clarify these details. I joke about understanding my network, and while that may be true most days, sometimes I'm not always the best at communicating it to others when necessary. - Jeff On Tue, Sep 25, 2012 at 1:50 PM, Todd Hodgen <[email protected]> wrote: > Jeff, I think the confusion is that some sip components are on the > 192.168.53.x network, while others are on 172.21.201.x network. In your > description below, you state “which routes”, which is indicating there is a > router on the network, and the IP addressing would indicate they are on > different networks. A router is required to route from one network to the > other network. **** > > ** ** > > NAT would be associated with a router – hence the reason why the questions > around where the router is.**** > > ** ** > > one Polycom extension 1821 at 172.21.201.39 calls another, 7821, at > 172.21.201.60. 7821 does an attended transfer to 2164550549, which routes > through the Adtran gateway at 192.168.53.11. The sipX system itself is at > 192.168.54.46.**** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Jeff Pyle > *Sent:* Tuesday, September 25, 2012 10:35 AM > *To:* Joegen Baclor > *Cc:* Discussion list for users of sipXecs software > *Subject:* Re: [sipx-users] Incorrect SDP from sipX after xfer completion* > *** > > ** ** > > 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 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/ >
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
