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/
