[sip-comm-dev] No audio playback in SIP Communicator?


#1

Hi, all!

I was told that I should contact this mailing list in hopes of
finding out why SIP Communicator doesn't work for me.

I've used SIP Communicator in multiple environments, including
Windows 2003 and Windows XP Professional. I'm a heavy user of
Java, so I almost always have the latest version of Java on all
the systems that I use. In the configurations that I've used,
the primary audio devices and secondary audio devices all appear
to work properly in other applications, but when I use
SIPCommunicator to initiate a loopback test to my SIP provider, I
don't hear any audio output on any devices.

The last version of SIP Communicator that I used was
1.0-alpha3-nightly.build.1905, but I have used previous versions
as well. None of them have worked properly for me; I wasn't able
to hear the audio from the remote party in any version.

Audio output through the Java sound libraries on at least one
system has been verified to work properly though JAMP. The audio
devices that I am using include CMedia's CMI8738, RealTek/Intel
HDA ("Azalia"), a SiS USB audio device, Microsoft LifeChat LX3000
USB audio, Microsoft LifeChat ZX6000 USB audio, and a Yamaha PCI
audio card.

Other tests that I've tried include calling my voicemail number
(the call succeeds, but no audio is played on my end) and calling
myself (the audio device rings, so playback is OK). Other SIP
UAs work fine on the same machines with the same hardware (I use
SJPhone and Xlite primarily).

I am located behind a NAT in all configurations, but my
SIP provider's proxy provides adjustments to SDP messages so that
all RTP streams are relayed through their servers. My SIP
provider is Voxalot, and I am using proxy01.us1.voxalot.com until
probelms with the other proxies are corrected.

I have tried both the DirectSoundCapture option as well as
JavaSound audio capture option without success in SIP
communicator.

It was suggested that I create a Wireshark capture to attach to
this message. The capture has been bzip2 compressed and attached
to this message. A UDP-only filter was applied in order to
reduce the noise from running a Remote Desktop for another
machine. Other information is available on request.

Please keep me in either the To or CC fields when sending a
reply. I don't monitor the SIP Communicator mailing list.

Thanks!

John

sipcommunicator.wireshark.log.pcap.bz2 (59.7 KB)


#2

John,

thanks for the detailed report.

Analysing the PCAP shows that the systems that cpatured the
network traffic does not receive any RTP packets, it only
sends RTP packets.

The SIP negotiations was OK, SC uses PCMU (G.711) as codec
which is quite normal.

Withou knowing how the SIP provider adjusts the SDP setting it is
sort of guessing what's wrong. My first guess: you are using 2
NICs on your XP system? One uses 192.168.1.38 and is connected
to the router/NAT, the other one uses the address 192.168.100.28
and connects to an internal network?

The SIP packets where send from IP address 192.168.1.38, inside
the SIP packet the VIA header shows "SIP/2.0/UDP 192.168.100.38:5060 ...",
also the SDP data show the 192.168.100.38 as RTP address. The
capture shows tha SC sends the RTP data and uses 192.168.100.38 as
sender address. In summary this looks like a network addressing
problem together with the NAT because it looks like the NAT does
not forward received RTP packets - as said is sor of guessing.

Sometimes this sort of addressing problems occur if the hosts file
is not setup correctly (I had a similar problem on my XP some time
ago, the hosts file did not contain the mapping of the system's
name to the correct address).

Regards,
Werner

jdstroy@dev.java.net schrieb:

···

Hi, all!

I was told that I should contact this mailing list in hopes of
finding out why SIP Communicator doesn't work for me.

I've used SIP Communicator in multiple environments, including
Windows 2003 and Windows XP Professional. I'm a heavy user of
Java, so I almost always have the latest version of Java on all
the systems that I use. In the configurations that I've used,
the primary audio devices and secondary audio devices all appear
to work properly in other applications, but when I use
SIPCommunicator to initiate a loopback test to my SIP provider, I
don't hear any audio output on any devices.

The last version of SIP Communicator that I used was
1.0-alpha3-nightly.build.1905, but I have used previous versions
as well. None of them have worked properly for me; I wasn't able
to hear the audio from the remote party in any version.

Audio output through the Java sound libraries on at least one
system has been verified to work properly though JAMP. The audio
devices that I am using include CMedia's CMI8738, RealTek/Intel
HDA ("Azalia"), a SiS USB audio device, Microsoft LifeChat LX3000
USB audio, Microsoft LifeChat ZX6000 USB audio, and a Yamaha PCI
audio card.

Other tests that I've tried include calling my voicemail number
(the call succeeds, but no audio is played on my end) and calling
myself (the audio device rings, so playback is OK). Other SIP
UAs work fine on the same machines with the same hardware (I use
SJPhone and Xlite primarily).

I am located behind a NAT in all configurations, but my
SIP provider's proxy provides adjustments to SDP messages so that
all RTP streams are relayed through their servers. My SIP
provider is Voxalot, and I am using proxy01.us1.voxalot.com until
probelms with the other proxies are corrected.

I have tried both the DirectSoundCapture option as well as
JavaSound audio capture option without success in SIP
communicator.

It was suggested that I create a Wireshark capture to attach to
this message. The capture has been bzip2 compressed and attached
to this message. A UDP-only filter was applied in order to
reduce the noise from running a Remote Desktop for another
machine. Other information is available on request.

Please keep me in either the To or CC fields when sending a
reply. I don't monitor the SIP Communicator mailing list.

Thanks!

John

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Werner,

Thanks for the analysis and response!

Withou knowing how the SIP provider adjusts the SDP setting it is
sort of guessing what's wrong.

Yes, I agree. I can, however, obtain Wireshark dumps of a call that
properly goes through on the same machine, but with a different SIP UA
(namely, SJPhone; attached). I might be able to obtain a capture of a
call to this machine from another machine, too, if needed.

My first guess: you are using 2
NICs on your XP system? One uses 192.168.1.38 and is connected
to the router/NAT, the other one uses the address 192.168.100.28
and connects to an internal network?

Close. More precisely, I have a bunch of NICs configured; there are
three physical NICs (Realtek RTL8168C(P)/8111C(P) PCI; SAGEM Wi-Fi 11g
USB; 1394), and multiple virtual (Hexago IPv6 tunnel; MS Loopback; Cisco
Systems VPN; Hamachi) adapters and network overlays. In the SIP
Communicator pcap, there was only one physical interface that was
enabled with TCP/IP (Realtek wired Ethernet), but it had two overlays --
one connected to a NAT [192.168.1.0/24], and the other connected to an
internal-only network [192.168.100.0/24]. Only the NAT-connected
network has a default gateway; none of the other adapters are configured
with a default gateway. This system is running Windows 2003.

The SIP packets where send from IP address 192.168.1.38, inside
the SIP packet the VIA header shows "SIP/2.0/UDP 192.168.100.38:5060
...",
also the SDP data show the 192.168.100.38 as RTP address. The
capture shows tha SC sends the RTP data and uses 192.168.100.38 as
sender address. In summary this looks like a network addressing
problem together with the NAT because it looks like the NAT does
not forward received RTP packets - as said is sor of guessing.

That does sound like an issue. Is there a way to make SIP Communicator
choose 192.168.1.38 over 192.168.100.38 instead? It's sending it
through the right address, but it's providing the wrong address in the
headers. I'm content with how my network is configured currently
(192.168.100.0/24 is used for SMB and static host addresses), but I'm
willing to adjust it for diagnostics.

Sometimes this sort of addressing problems occur if the hosts file
is not setup correctly (I had a similar problem on my XP some time
ago, the hosts file did not contain the mapping of the system's
name to the correct address).

There's a single non-comment line in there that reads:

127.0.0.1 localhost

I've set up DNS entries for all hosts on my network, which may be
affecting this as well; the highest priority A entry of this node on the
default domain search order points to 192.168.100.38, which is
intentional.

John

sjphone.wireshark.log.pcap.bz2 (309 KB)


#4

John,

see some comments inline. Emil, do you have an idea what could be
wrong here?

Regards,
Werner

jdstroy@dev.java.net schrieb:

Werner,

Thanks for the analysis and response!

Withou knowing how the SIP provider adjusts the SDP setting it is
sort of guessing what's wrong.

Yes, I agree. I can, however, obtain Wireshark dumps of a call that
properly goes through on the same machine, but with a different SIP UA
(namely, SJPhone; attached). I might be able to obtain a capture of a
call to this machine from another machine, too, if needed.

.....

Close. More precisely, I have a bunch of NICs configured; there are
three physical NICs (Realtek RTL8168C(P)/8111C(P) PCI; SAGEM Wi-Fi 11g
USB; 1394), and multiple virtual (Hexago IPv6 tunnel; MS Loopback; Cisco
Systems VPN; Hamachi) adapters and network overlays. In the SIP
Communicator pcap, there was only one physical interface that was
enabled with TCP/IP (Realtek wired Ethernet), but it had two overlays --
one connected to a NAT [192.168.1.0/24], and the other connected to an
internal-only network [192.168.100.0/24]. Only the NAT-connected
network has a default gateway; none of the other adapters are configured
with a default gateway. This system is running Windows 2003.

....

That does sound like an issue. Is there a way to make SIP Communicator
choose 192.168.1.38 over 192.168.100.38 instead? It's sending it
through the right address, but it's providing the wrong address in the
headers. I'm content with how my network is configured currently
(192.168.100.0/24 is used for SMB and static host addresses), but I'm
willing to adjust it for diagnostics.

....

I've set up DNS entries for all hosts on my network, which may be
affecting this as well; the highest priority A entry of this node on the
default domain search order points to 192.168.100.38, which is
intentional.

According to your info: the default gateway is in the network
192.168.1.0/24 and thus the system sends all packet to the NIC that belongs
to this network. We can see this in Wireshark as the sender address.

SC uses DatagramSocket.connect(remoteAddress) and a following
getLocalAddress on that socket to get the system's IP address to use. This
should result in in 192.168.1.38 because the "connect(..)" should use
this NIC to send data to the SIP proxy.

I'm not sure if the entries in the DNS modify the result of this and thus
the "getLocalAddress(..) returns 192.168.100.38.

What would be interessting to see: a wireshark protocol of one of the other
SIP clients

···

John

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hey folks,

Werner Dittmann wrote:

I've set up DNS entries for all hosts on my network, which may be
affecting this as well;

Could be.

the highest priority A entry of this node on the

default domain search order points to 192.168.100.38, which is
intentional.

According to your info: the default gateway is in the network
192.168.1.0/24 and thus the system sends all packet to the NIC that belongs
to this network. We can see this in Wireshark as the sender address.

SC uses DatagramSocket.connect(remoteAddress) and a following
getLocalAddress on that socket to get the system's IP address to use. This
should result in in 192.168.1.38 because the "connect(..)" should use
this NIC to send data to the SIP proxy.

Unfortunately the DatagramSocket.connect() hack only works on Linux (and
possibly Mac OS X as well) and returns 0.0.0.0 on Windows. Whenever this
happens and we are not trying to reach an IPv6 destination, we fall back
to InetAddress.getLocalHost(). This works better on Windows than it does
on Linux but remains, by design, quite unpredictable for multihomed hosts.

John, in your case I think that using the 192.168.100.138 (100)
interface for DNS might somehow be contributing to it being returned by
getLocalHost(). I may be wrong though. Could you give it a try with a
DNS server located on the public Internet? Anyways, whatever the reason,
this is probably what's happening and why your SDP offer contains that
address.

We then force the RTP manager to bind on that address which also
explains the fact that your outgoing RTP traffic leaves from the 100
interface. In other words this is not a routing problem since we pick
the source address.

The best way to fix this would be to implement a reliable local host
address retriever for windows, but that would probably require some
effort (and possibly some native code) ... ideas anyone?

Either way, I guess we should schedule an issue for this.

Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hey folks,

Werner Dittmann wrote:

I've set up DNS entries for all hosts on my network, which may be
affecting this as well;

Could be.

the highest priority A entry of this node on the

default domain search order points to 192.168.100.38, which is
intentional.

According to your info: the default gateway is in the network
192.168.1.0/24 and thus the system sends all packet to the NIC that belongs
to this network. We can see this in Wireshark as the sender address.

SC uses DatagramSocket.connect(remoteAddress) and a following
getLocalAddress on that socket to get the system's IP address to use. This
should result in in 192.168.1.38 because the "connect(..)" should use
this NIC to send data to the SIP proxy.

Unfortunately the DatagramSocket.connect() hack only works on Linux (and
possibly Mac OS X as well) and returns 0.0.0.0 on Windows. Whenever this
happens and we are not trying to reach an IPv6 destination, we fall back
to InetAddress.getLocalHost(). This works better on Windows than it does
on Linux but remains, by design, quite unpredictable for multihomed hosts.

John, in your case I think that using the 192.168.100.138 (100)
interface for DNS might somehow be contributing to it being returned by
getLocalHost(). I may be wrong though. Could you give it a try with a
DNS server located on the public Internet? Anyways, whatever the reason,
this is probably what's happening and why your SDP offer contains that
address.

We then force the RTP manager to bind on that address which also
explains the fact that your outgoing RTP traffic leaves from the 100
interface. In other words this is not a routing problem since we pick
the source address.

The best way to fix this would be to implement a reliable local host
address retriever for windows, but that would probably require some
effort (and possibly some native code) ... ideas anyone?

Either way, I guess we should schedule an issue for this.

Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

== snip! ==

What would be interessting to see: a wireshark protocol of one of the
other
SIP clients

Please see the attachment at
https://sip-communicator.dev.java.net/servlets/ReadMsg?list=dev&msgNo=6463.
:slight_smile:

On Tue, 23 Jun 2009 16:51:28 +0200, "Emil Ivov"
== snip ==

John, in your case I think that using the 192.168.100.138 (100)
interface for DNS might somehow be contributing to it being returned by
getLocalHost(). I may be wrong though. Could you give it a try with a
DNS server located on the public Internet? Anyways, whatever the reason,
this is probably what's happening and why your SDP offer contains that
address.

I would be happy to give it a try; could you be a little bit more
specific as for what I'm trying?

We then force the RTP manager to bind on that address which also
explains the fact that your outgoing RTP traffic leaves from the 100
interface. In other words this is not a routing problem since we pick
the source address.

The best way to fix this would be to implement a reliable local host
address retriever for windows, but that would probably require some
effort (and possibly some native code) ... ideas anyone?

I wouldn't mind contributing source for a way to get this via a Java
property. I'm not sure how to approach it in a less intrusive way...
without resorting to native code, though, it might be possible to use
InetAddress.isReachable, but that works on a best-effort basis and might
require ICMP echo or a server with TCP port 7.

John

···

On Mon, 22 Jun 2009 19:37:47 +0200, "Werner Dittmann" <Werner.Dittmann@t-online.de> said:


#8

John,

the SJPhone trace shows two major differences compaared with the SC trace:

- SJPhone uses STUN to detect an address. The traces contains exactly
  one STUN response (line 20) that matches to a STUN request sent from
  address 192.168.1.38. IMHO the STUN response information is not used
  in the following SIP and RTP handshakes (I'm not very familiar with
  STUN though - Emil may shed some more light onto this)

- The SIP REGISTER and the SIP INVITE use the address 192.168.99.1 in
  all relevant headers and fields. Even with this setup SJPhone sends
  and receives the RTP data at address 192.168.1.38. Is there any other
  address mapping in between? Different setup of SJPhone?

Regards,
Werner

John Stroy schrieb:

···

On Mon, 22 Jun 2009 19:37:47 +0200, "Werner Dittmann" > <Werner.Dittmann@t-online.de> said:
== snip! ==

What would be interessting to see: a wireshark protocol of one of the
other
SIP clients

Please see the attachment at
https://sip-communicator.dev.java.net/servlets/ReadMsg?list=dev&msgNo=6463.
:slight_smile:

On Tue, 23 Jun 2009 16:51:28 +0200, "Emil Ivov"
== snip ==

John, in your case I think that using the 192.168.100.138 (100)
interface for DNS might somehow be contributing to it being returned by
getLocalHost(). I may be wrong though. Could you give it a try with a
DNS server located on the public Internet? Anyways, whatever the reason,
this is probably what's happening and why your SDP offer contains that
address.

I would be happy to give it a try; could you be a little bit more
specific as for what I'm trying?

We then force the RTP manager to bind on that address which also
explains the fact that your outgoing RTP traffic leaves from the 100
interface. In other words this is not a routing problem since we pick
the source address.

The best way to fix this would be to implement a reliable local host
address retriever for windows, but that would probably require some
effort (and possibly some native code) ... ideas anyone?

I wouldn't mind contributing source for a way to get this via a Java
property. I'm not sure how to approach it in a less intrusive way...
without resorting to native code, though, it might be possible to use
InetAddress.isReachable, but that works on a best-effort basis and might
require ICMP echo or a server with TCP port 7.

John


#9

Hey John,

John Stroy wrote:

John, in your case I think that using the 192.168.100.138 (100)
interface for DNS might somehow be contributing to it being returned by
getLocalHost(). I may be wrong though. Could you give it a try with a
DNS server located on the public Internet? Anyways, whatever the reason,
this is probably what's happening and why your SDP offer contains that
address.

I would be happy to give it a try; could you be a little bit more
specific as for what I'm trying?

I mean replacing your internal DNS with one on the Internet (like for
example 208.67.222.222 and 208.67.220.220) and then trying a call again.
This would confirm that the you are obtaining a local address for your
local 100 network because of routes/priorities that have been set
because of the DNS.

We then force the RTP manager to bind on that address which also
explains the fact that your outgoing RTP traffic leaves from the 100
interface. In other words this is not a routing problem since we pick
the source address.

The best way to fix this would be to implement a reliable local host
address retriever for windows, but that would probably require some
effort (and possibly some native code) ... ideas anyone?

I wouldn't mind contributing source for a way to get this via a Java
property.

A configuration property might be an option so we'll probably implement
it as a temporary solution. Could you please open an issue on our
tracker and describe this scenario? This kind of solution would require
more than the average user expertise though so eventually resolving the
issue without requiring human intervention would be better.

I'm not sure how to approach it in a less intrusive way...
without resorting to native code, though, it might be possible to use
InetAddress.isReachable, but that works on a best-effort basis and might
require ICMP echo or a server with TCP port 7.

The InetAddress.isReachable() method does, in a way, more than we need
which actually makes it unsuitable for this kind of use. What we need
here is simply a way to consult the OS routing table and get the local
address for an intended destination. We don't need to check reachability
at this point. We shouldn't be taking too much time to return a result
either as the method is used in time sensitive scenarios like taking and
establishing calls for example. Besides, more often than not, the method
would return false so it is not that reliable either. Public servers for
example often have ICMP and most ports firewalled while they do accept
connections/packets on 5060 and possibly on a range of ports reserved
for media.

We need an alternative for that would give us the same as the
DatagramSocket.connect() hack on linux. We need something that would
query the routing table. I really think that implementing a native
helper is the only way to go.

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Hey Werner,

Werner Dittmann wrote:

John,

the SJPhone trace shows two major differences compaared with the SC trace:

- SJPhone uses STUN to detect an address. The traces contains exactly
  one STUN response (line 20) that matches to a STUN request sent from
  address 192.168.1.38. IMHO the STUN response information is not used
  in the following SIP and RTP handshakes (I'm not very familiar with
  STUN though - Emil may shed some more light onto this)

No, indeed, SJPhone doesn't seem to be using the STUN information.

- The SIP REGISTER and the SIP INVITE use the address 192.168.99.1 in
  all relevant headers and fields. Even with this setup SJPhone sends
  and receives the RTP data at address 192.168.1.38. Is there any other
  address mapping in between? Different setup of SJPhone?

My bet is that SJPhone are simply using a different means of acquiring
the local address which is working better than InetAddress.getLocalHost()

Cheers
Emil

···

Regards,
Werner

John Stroy schrieb:

On Mon, 22 Jun 2009 19:37:47 +0200, "Werner Dittmann" >> <Werner.Dittmann@t-online.de> said:
== snip! ==

What would be interessting to see: a wireshark protocol of one of the
other
SIP clients

Please see the attachment at
https://sip-communicator.dev.java.net/servlets/ReadMsg?list=dev&msgNo=6463.
:slight_smile:

On Tue, 23 Jun 2009 16:51:28 +0200, "Emil Ivov"
== snip ==

John, in your case I think that using the 192.168.100.138 (100)
interface for DNS might somehow be contributing to it being returned by
getLocalHost(). I may be wrong though. Could you give it a try with a
DNS server located on the public Internet? Anyways, whatever the reason,
this is probably what's happening and why your SDP offer contains that
address.

I would be happy to give it a try; could you be a little bit more
specific as for what I'm trying?

We then force the RTP manager to bind on that address which also
explains the fact that your outgoing RTP traffic leaves from the 100
interface. In other words this is not a routing problem since we pick
the source address.

The best way to fix this would be to implement a reliable local host
address retriever for windows, but that would probably require some
effort (and possibly some native code) ... ideas anyone?

I wouldn't mind contributing source for a way to get this via a Java
property. I'm not sure how to approach it in a less intrusive way...
without resorting to native code, though, it might be possible to use
InetAddress.isReachable, but that works on a best-effort basis and might
require ICMP echo or a server with TCP port 7.

John

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#11

Hi Emil, hi Warner,

I apologize for not getting back to you sooner.

I tried changing the DNS server to 208.67.222.222, and that didn't have
an effect. It's probably worth noting that the FQDN of my machine still
forward resolves on public DNS servers...

I also tried changing the DNS suffix on my machine so that it wouldn't
resolve (by adding .local to the name); however, this didn't affect my
call either. I made a wireshark capture for this session, figuring it
might be useful (attached).

I'll open an issue on the SC tracker soon.

Indeed, SJPhone is configured with a STUN server. However, I've elected
to disable the usage of STUN discovered addresses in SJPhone since it
(supposedly) interferes with Voxalot's media relay. As for other
address mappings or different setups of SJPhone, I'm not aware of any.
192.168.99.1 is not an address that I manually configured, but it is
used by virtualization services (VirtualBox, I think?)

John

sipcommunicator.wireshark.log.pcap.bz2 (21.6 KB)


#12

John, Emil,

my tests here show a similar behaviour now: using SC to connect
to iptel.org (sip:music@iptel.org) works but I cannot hear the
music. Using twinkle this workss. My system is directly connect
to the Internet using a DSL modem, not a router, thus not NAT or
any other "bad stuff".

The SIP INVITE looks ok to me, also in comparison with the INVITE
that twinkle sends. As a matter of fact: the wireshark protocol
shows that in case of the SC call to iptel.org my system does not
receive any RTP packets from iptel.org, SC sends RTP data.

This used to work flawlessly because I use the music dial-in to
do a quick check after a re-build of SC. Because I didn't rebuild
during the last 4-6 weeks or so I was not aware of this problem. Only
now after I started to look at Georges code I see this problem
(both on George's branch as well as on trunk).

What is strange however: I can listen to audio if I use my internal
test systems using local IP addresses and using an own small
registrar. This is my usual test setup that I use for quite some time
now.

Frankly, I don't know what's wrong with the "external" INVITE.

Attached is a tar.gz file that contains two pcap (wireshark) files:
one that shows SC to iptel.org, the other one shows twinkle to
iptel.org.

However, I ran out of ideas currently :frowning:

Regards,
Werner

John Stroy schrieb:

pcaps.tar.gz (44.4 KB)

···

Hi Emil, hi Warner,

I apologize for not getting back to you sooner.

I tried changing the DNS server to 208.67.222.222, and that didn't have
an effect. It's probably worth noting that the FQDN of my machine still
forward resolves on public DNS servers...

I also tried changing the DNS suffix on my machine so that it wouldn't
resolve (by adding .local to the name); however, this didn't affect my
call either. I made a wireshark capture for this session, figuring it
might be useful (attached).

I'll open an issue on the SC tracker soon.

Indeed, SJPhone is configured with a STUN server. However, I've elected
to disable the usage of STUN discovered addresses in SJPhone since it
(supposedly) interferes with Voxalot's media relay. As for other
address mappings or different setups of SJPhone, I'm not aware of any.
192.168.99.1 is not an address that I manually configured, but it is
used by virtualization services (VirtualBox, I think?)

John


#13

Hey John,

John Stroy wrote:

Hi Emil, hi Warner,

I apologize for not getting back to you sooner.

No worries.

I'll open an issue on the SC tracker soon.

Just saw it. Thanks. I've changed it a bit so that it would reflect the
need of a windows specific local address selection mechanism. I've also
scheduled it for our 1.1 release but it may have to wait 1.2 if we are
short of time.

Indeed, SJPhone is configured with a STUN server. However, I've elected
to disable the usage of STUN discovered addresses in SJPhone since it
(supposedly) interferes with Voxalot's media relay. As for other
address mappings or different setups of SJPhone, I'm not aware of any.
192.168.99.1 is not an address that I manually configured, but it is
used by virtualization services (VirtualBox, I think?)

Thanks for your feedback John.

Cheers
Emil

···

John

------------------------------------------------------------------------

Subject:
Re: [sip-comm-dev] No audio playback in SIP Communicator?
From:
Emil Ivov <emcho@sip-communicator.org>
Date:
Sat, 27 Jun 2009 10:37:41 +0200
To:
John Stroy <jdstroy@dev.java.net>

To:
John Stroy <jdstroy@dev.java.net>
CC:
Werner Dittmann <Werner.Dittmann@t-online.de>,
dev@sip-communicator.dev.java.net

Hey John,

John Stroy wrote:

John, in your case I think that using the 192.168.100.138 (100)
interface for DNS might somehow be contributing to it being returned by
getLocalHost(). I may be wrong though. Could you give it a try with a
DNS server located on the public Internet? Anyways, whatever the reason,
this is probably what's happening and why your SDP offer contains that
address.

I would be happy to give it a try; could you be a little bit more
specific as for what I'm trying?

I mean replacing your internal DNS with one on the Internet (like for
example 208.67.222.222 and 208.67.220.220) and then trying a call again.
This would confirm that the you are obtaining a local address for your
local 100 network because of routes/priorities that have been set
because of the DNS.

We then force the RTP manager to bind on that address which also
explains the fact that your outgoing RTP traffic leaves from the 100
interface. In other words this is not a routing problem since we pick
the source address.

The best way to fix this would be to implement a reliable local host
address retriever for windows, but that would probably require some
effort (and possibly some native code) ... ideas anyone?

I wouldn't mind contributing source for a way to get this via a Java
property.

A configuration property might be an option so we'll probably implement
it as a temporary solution. Could you please open an issue on our
tracker and describe this scenario? This kind of solution would require
more than the average user expertise though so eventually resolving the
issue without requiring human intervention would be better.

I'm not sure how to approach it in a less intrusive way...
without resorting to native code, though, it might be possible to use
InetAddress.isReachable, but that works on a best-effort basis and might
require ICMP echo or a server with TCP port 7.

The InetAddress.isReachable() method does, in a way, more than we need
which actually makes it unsuitable for this kind of use. What we need
here is simply a way to consult the OS routing table and get the local
address for an intended destination. We don't need to check reachability
at this point. We shouldn't be taking too much time to return a result
either as the method is used in time sensitive scenarios like taking and
establishing calls for example. Besides, more often than not, the method
would return false so it is not that reliable either. Public servers for
example often have ICMP and most ports firewalled while they do accept
connections/packets on 5060 and possibly on a range of ports reserved
for media.

We need an alternative for that would give us the same as the
DatagramSocket.connect() hack on linux. We need something that would
query the routing table. I really think that implementing a native
helper is the only way to go.

Cheers
Emil

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#14

Hey Werner,

It's quite perplexing indeed. It appears that in our case the SEMS
installation on iptel.org would tell us to send media to 213.192.59.78
which is what we do. Notice however that there's an occasional ICMP -
3.3 - Port unreachable, so there doesn't seem to be anyone listening on
that port.

I get exactly the same thing here.

Twinkle on the other hand is instructed to stream to 213.192.59.75. At
first I thought that was some kind of load balancing and the two IPs get
alternated but every time I try with SIP Communicator I get 78 and every
time I try with another UA I fall on 75.

I've been staring at the dumps for about an hour now and can't see
substantial differences so I am also CCing the SEMS team. Stefan, I
wonder whether you could give us a hand with this.

I am also attaching Werner's initial dumps since they describe the
situation quite well.

Cheers
Emil

Werner Dittmann wrote:

pcaps.tar.gz (44.4 KB)

···

John, Emil,

my tests here show a similar behaviour now: using SC to connect
to iptel.org (sip:music@iptel.org) works but I cannot hear the
music. Using twinkle this workss. My system is directly connect
to the Internet using a DSL modem, not a router, thus not NAT or
any other "bad stuff".

The SIP INVITE looks ok to me, also in comparison with the INVITE
that twinkle sends. As a matter of fact: the wireshark protocol
shows that in case of the SC call to iptel.org my system does not
receive any RTP packets from iptel.org, SC sends RTP data.

This used to work flawlessly because I use the music dial-in to
do a quick check after a re-build of SC. Because I didn't rebuild
during the last 4-6 weeks or so I was not aware of this problem. Only
now after I started to look at Georges code I see this problem
(both on George's branch as well as on trunk).

What is strange however: I can listen to audio if I use my internal
test systems using local IP addresses and using an own small
registrar. This is my usual test setup that I use for quite some time
now.

Frankly, I don't know what's wrong with the "external" INVITE.

Attached is a tar.gz file that contains two pcap (wireshark) files:
one that shows SC to iptel.org, the other one shows twinkle to
iptel.org.

However, I ran out of ideas currently :frowning:

Regards,
Werner

John Stroy schrieb:

Hi Emil, hi Warner,

I apologize for not getting back to you sooner.

I tried changing the DNS server to 208.67.222.222, and that didn't have
an effect. It's probably worth noting that the FQDN of my machine still
forward resolves on public DNS servers...

I also tried changing the DNS suffix on my machine so that it wouldn't
resolve (by adding .local to the name); however, this didn't affect my
call either. I made a wireshark capture for this session, figuring it
might be useful (attached).

I'll open an issue on the SC tracker soon.

Indeed, SJPhone is configured with a STUN server. However, I've elected
to disable the usage of STUN discovered addresses in SJPhone since it
(supposedly) interferes with Voxalot's media relay. As for other
address mappings or different setups of SJPhone, I'm not aware of any.
192.168.99.1 is not an address that I manually configured, but it is
used by virtualization services (VirtualBox, I think?)

John

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31


#15

Hey Guys,

I just had successful calls with iptel.org's echo and music numbers so
they seem to have fixed the issue. Werner is it also working for you?

Cheers
Emil

Werner Dittmann wrote:

···

John, Emil,

my tests here show a similar behaviour now: using SC to connect
to iptel.org (sip:music@iptel.org) works but I cannot hear the
music. Using twinkle this workss. My system is directly connect
to the Internet using a DSL modem, not a router, thus not NAT or
any other "bad stuff".

The SIP INVITE looks ok to me, also in comparison with the INVITE
that twinkle sends. As a matter of fact: the wireshark protocol
shows that in case of the SC call to iptel.org my system does not
receive any RTP packets from iptel.org, SC sends RTP data.

This used to work flawlessly because I use the music dial-in to
do a quick check after a re-build of SC. Because I didn't rebuild
during the last 4-6 weeks or so I was not aware of this problem. Only
now after I started to look at Georges code I see this problem
(both on George's branch as well as on trunk).

What is strange however: I can listen to audio if I use my internal
test systems using local IP addresses and using an own small
registrar. This is my usual test setup that I use for quite some time
now.

Frankly, I don't know what's wrong with the "external" INVITE.

Attached is a tar.gz file that contains two pcap (wireshark) files:
one that shows SC to iptel.org, the other one shows twinkle to
iptel.org.

However, I ran out of ideas currently :frowning:

Regards,
Werner

John Stroy schrieb:

Hi Emil, hi Warner,

I apologize for not getting back to you sooner.

I tried changing the DNS server to 208.67.222.222, and that didn't have
an effect. It's probably worth noting that the FQDN of my machine still
forward resolves on public DNS servers...

I also tried changing the DNS suffix on my machine so that it wouldn't
resolve (by adding .local to the name); however, this didn't affect my
call either. I made a wireshark capture for this session, figuring it
might be useful (attached).

I'll open an issue on the SC tracker soon.

Indeed, SJPhone is configured with a STUN server. However, I've elected
to disable the usage of STUN discovered addresses in SJPhone since it
(supposedly) interferes with Voxalot's media relay. As for other
address mappings or different setups of SJPhone, I'm not aware of any.
192.168.99.1 is not an address that I manually configured, but it is
used by virtualization services (VirtualBox, I think?)

John

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#16

Emil,

it works for me as well. What did they change? Because the symptoms
were similar to the problem that John described it could be of
interest.

Regards,
Werner

Emil Ivov schrieb:

···

Hey Guys,

I just had successful calls with iptel.org's echo and music numbers so
they seem to have fixed the issue. Werner is it also working for you?

Cheers
Emil

Werner Dittmann wrote:

John, Emil,

my tests here show a similar behaviour now: using SC to connect
to iptel.org (sip:music@iptel.org) works but I cannot hear the
music. Using twinkle this workss. My system is directly connect
to the Internet using a DSL modem, not a router, thus not NAT or
any other "bad stuff".

The SIP INVITE looks ok to me, also in comparison with the INVITE
that twinkle sends. As a matter of fact: the wireshark protocol
shows that in case of the SC call to iptel.org my system does not
receive any RTP packets from iptel.org, SC sends RTP data.

This used to work flawlessly because I use the music dial-in to
do a quick check after a re-build of SC. Because I didn't rebuild
during the last 4-6 weeks or so I was not aware of this problem. Only
now after I started to look at Georges code I see this problem
(both on George's branch as well as on trunk).

What is strange however: I can listen to audio if I use my internal
test systems using local IP addresses and using an own small
registrar. This is my usual test setup that I use for quite some time
now.

Frankly, I don't know what's wrong with the "external" INVITE.

Attached is a tar.gz file that contains two pcap (wireshark) files:
one that shows SC to iptel.org, the other one shows twinkle to
iptel.org.

However, I ran out of ideas currently :frowning:

Regards,
Werner

John Stroy schrieb:

Hi Emil, hi Warner,

I apologize for not getting back to you sooner.

I tried changing the DNS server to 208.67.222.222, and that didn't have
an effect. It's probably worth noting that the FQDN of my machine still
forward resolves on public DNS servers...

I also tried changing the DNS suffix on my machine so that it wouldn't
resolve (by adding .local to the name); however, this didn't affect my
call either. I made a wireshark capture for this session, figuring it
might be useful (attached).

I'll open an issue on the SC tracker soon.

Indeed, SJPhone is configured with a STUN server. However, I've elected
to disable the usage of STUN discovered addresses in SJPhone since it
(supposedly) interferes with Voxalot's media relay. As for other
address mappings or different setups of SJPhone, I'm not aware of any.
192.168.99.1 is not an address that I manually configured, but it is
used by virtualization services (VirtualBox, I think?)

John


#17

Werner,

Werner Dittmann wrote:

Emil,

it works for me as well. What did they change?

Stefan explained that there was a bug in SEMS that (if I understood
correctly) was causing some method to freak on one of our media
descriptions and return abnormally without making the necessary
indications the rtp proxy. He fixed it by upgrading to the latest
release of SEMS.

Because the symptoms were similar to the problem that John
described it could be of interest.

I don't think it is the same problem. In the case of John we simply bind
our media socket to an interface that has no internet connectivity while
media is arriving on another one.

In order to resolve this we need a way to determine which one of the
local addresses is best suited for a specific destination. Most
applications would normally bind to 0.0.0.0 and hence receive packets
regardless of the local address they arrive on. We changed this some
time ago as it was also causing problems (I believe you were actually
the one who reported them).

The bottom line is that we need a way to consult the routing table. The
DatagramSocket.connect() method is a nice hack but it doesn't seem to
work on windows so we either need another pure java hack or a few lines
of native code (which is what I had in mind for the #704 issue that John
entered).

Cheers
Emil

···

Regards,
Werner

Emil Ivov schrieb:

Hey Guys,

I just had successful calls with iptel.org's echo and music numbers so
they seem to have fixed the issue. Werner is it also working for you?

Cheers
Emil

Werner Dittmann wrote:

John, Emil,

my tests here show a similar behaviour now: using SC to connect
to iptel.org (sip:music@iptel.org) works but I cannot hear the
music. Using twinkle this workss. My system is directly connect
to the Internet using a DSL modem, not a router, thus not NAT or
any other "bad stuff".

The SIP INVITE looks ok to me, also in comparison with the INVITE
that twinkle sends. As a matter of fact: the wireshark protocol
shows that in case of the SC call to iptel.org my system does not
receive any RTP packets from iptel.org, SC sends RTP data.

This used to work flawlessly because I use the music dial-in to
do a quick check after a re-build of SC. Because I didn't rebuild
during the last 4-6 weeks or so I was not aware of this problem. Only
now after I started to look at Georges code I see this problem
(both on George's branch as well as on trunk).

What is strange however: I can listen to audio if I use my internal
test systems using local IP addresses and using an own small
registrar. This is my usual test setup that I use for quite some time
now.

Frankly, I don't know what's wrong with the "external" INVITE.

Attached is a tar.gz file that contains two pcap (wireshark) files:
one that shows SC to iptel.org, the other one shows twinkle to
iptel.org.

However, I ran out of ideas currently :frowning:

Regards,
Werner

John Stroy schrieb:

Hi Emil, hi Warner,

I apologize for not getting back to you sooner.

I tried changing the DNS server to 208.67.222.222, and that didn't have
an effect. It's probably worth noting that the FQDN of my machine still
forward resolves on public DNS servers...

I also tried changing the DNS suffix on my machine so that it wouldn't
resolve (by adding .local to the name); however, this didn't affect my
call either. I made a wireshark capture for this session, figuring it
might be useful (attached).

I'll open an issue on the SC tracker soon.

Indeed, SJPhone is configured with a STUN server. However, I've elected
to disable the usage of STUN discovered addresses in SJPhone since it
(supposedly) interferes with Voxalot's media relay. As for other
address mappings or different setups of SJPhone, I'm not aware of any.
192.168.99.1 is not an address that I manually configured, but it is
used by virtualization services (VirtualBox, I think?)

John

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net