Thanks Jeff. Will look at it the soonest.
On 09/26/2012 01:34 AM, Jeff Pyle wrote:
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]
<mailto:[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] <mailto:[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] <mailto:[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]
<mailto:[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/
