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/
