A
Ari
I have an ADSL connection and two PCs running XP Professional SP2. One
PC is configured as an ICS host, and the other one is a client. I
cannot make a voice conversation from the client PC to the ICS host
using Windows Messenger 5.1.0639. The other way it works.
I have done some packet sniffing with ethereal, and below is a
simplified diagram of the messenger traffic between the clients (steps
1 - 3 are connected via a messenger server, which is not shown here)
1. A -> B INVITE
2. B -> A ACCEPT
3. A -> B ACCEPT IP-Address IP1ORT1
4. B -> IP1ORT1 SIP/SD Request: INVITE IP1ORT1
contact IP2ORT2
5. A -> IP2ORT2 SIP Status: 100 Trying
....
....
Case 1:
Voice conversation is initiated from the ICS host,
i.e. A = ICS host, B = client
IP1 = 192.168.0.1
IP2 = 192.168.0.97
Both clients are using private addresses and the voice conversation is
connected.
Case 2:
Voice conversation is initiated from the ICS client,
i.e. A = client, B = ICS host
IP1 = 180.xx.xx.xx:58087
So, in the 3rd step in the diagram above, the messenger client finds
that it is behind a NAT device (ICS). By using upnp it finds the public
address (180.xx.xx.xx) and configures the ICS host to forward to the
client PC any incoming traffic on a dynamically allocated port 58087.
Next, in the 4th step, the ICS host tries to send its SIP request
directly to its peer using the address 180.xx.xx.xx:58087. The ICS host
has an entry in its routing table that delivers the request directly to
the address 127.0.0.1, i.e. localhost. Hence the request bypasses any
redirection rules for incoming packets and wont be routed to the client
PC.
Are there any known issues for this kind of setup running windows
messenger locally on the ICS host?
Or is there a bug in XP's NAT traversal API?
Ari Jasberg
PC is configured as an ICS host, and the other one is a client. I
cannot make a voice conversation from the client PC to the ICS host
using Windows Messenger 5.1.0639. The other way it works.
I have done some packet sniffing with ethereal, and below is a
simplified diagram of the messenger traffic between the clients (steps
1 - 3 are connected via a messenger server, which is not shown here)
1. A -> B INVITE
2. B -> A ACCEPT
3. A -> B ACCEPT IP-Address IP1ORT1
4. B -> IP1ORT1 SIP/SD Request: INVITE IP1ORT1
contact IP2ORT2
5. A -> IP2ORT2 SIP Status: 100 Trying
....
....
Case 1:
Voice conversation is initiated from the ICS host,
i.e. A = ICS host, B = client
IP1 = 192.168.0.1
IP2 = 192.168.0.97
Both clients are using private addresses and the voice conversation is
connected.
Case 2:
Voice conversation is initiated from the ICS client,
i.e. A = client, B = ICS host
IP1 = 180.xx.xx.xx:58087
So, in the 3rd step in the diagram above, the messenger client finds
that it is behind a NAT device (ICS). By using upnp it finds the public
address (180.xx.xx.xx) and configures the ICS host to forward to the
client PC any incoming traffic on a dynamically allocated port 58087.
Next, in the 4th step, the ICS host tries to send its SIP request
directly to its peer using the address 180.xx.xx.xx:58087. The ICS host
has an entry in its routing table that delivers the request directly to
the address 127.0.0.1, i.e. localhost. Hence the request bypasses any
redirection rules for incoming packets and wont be routed to the client
PC.
Are there any known issues for this kind of setup running windows
messenger locally on the ICS host?
Or is there a bug in XP's NAT traversal API?
Ari Jasberg