MSN Audio

[IkHiero]

After trying a lot of times, i´m desperate about msn audio with my asus wl500g, maybe someone know an answer about this:

With MSN i can make a connection to everyone with my webcam,
both ways. no problem here.

With MSN i can get invited by someone for an audio conversation, i can accept it, and hear the other one talk. but they cant hear me. The connection is established with no problem according MSN.
I´ve got trouble with inviting someone else, some times i can establish a connection some times i can´t, but even if the connection is established they can´t hear me.

The mic is working flawless, so no hardware trouble there.

I have tried with port triggering, and als the other option to bound all incoming packets to my local ip.

Specs: MSN Messenger 6.1, Windows XP Pro, Asus Wl500

PS: thanks in advance for the tips i found in the forum about the telnet daemon and the ftp server, they work great. (i will try to get a ssh daemon working on my usb disk next weekend (and will try to setup ultr@VNC)

[Technik]

Did you try to make a MSN connection locally? I don't know that piece of SW but for instance in Netmeeting you can find Audio option 'Enable full duplex audio...'. If this feature is not allowed, you can have a trouble like this...
I would check with another local workstation first (using hub or cross cable) to be absolutely sure that MSN works as expected.

[IkHiero]

There are no problems local to use msn audio. So its a problem with the router.
I mapped every port and tried every tip i found on the internet.....
Tonight, i will restore my firmware and go through every setting again... maybe i messed something up (i can´t find another reason...):confused:

[TRaNe]

Hi,

Any news on the MSN Audio problem? I got the same problem and hasn't found any solution yet. Is it a UPNP problem?

T

[njs]

Hi

I'm having similar problems.
Here the problem is not the audio, because once it is connected I can hear and be heard.
The problem is getting it to connect. Sometimes it works, and takes ages to connect until it timesout (when it connects).
I figured out that once a connection is established (which takes a lot more time than with other routers), if you disconnect and connect again 95% of the tries you can't do it. BUT if you close both MSN Clients, and restart both and then try to establish a new audio conversation 90 % of the times it works.
With ethereal I can see (when it fails) lots of destinations ports unreachable.
I think that it might be a problem with UPnP, that if the connection is not done somehow quick it closes the ports.
Why this happens, and solutions I don't have.
Does anyone has this problem? Or know how to solve it?

Hope to hear from you soon.
Nuno

[erik_bies]

This is a problem of the messenger. It just needs so many open ports (all from 5004 – 65535.) that you firewall just renders useless (>60k ports open).
This is MS idea of security :-S

Here is what Microsoft says http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/winxppro/deploy/worki01.asp
Audio and Video

When negotiating an audio-video session, dynamic ports were chosen for the audio-video (AV) stream. Dynamic ports are used to enable the application to work regardless of what other applications are running on the system and using port resources. In the .NET Messenger case the session invitation was sent by station B to the address it received for station A.

The following issues might arise if a firewall or NAT were present in these scenarios:

* The address provided by A in either the session invite for session signaling, or in the session acceptance for the UDP streams, might be an internal address that is translated by a NAT device—an invalid (or fake) address for B to use to contact A. In other scenarios with the 4.5 client, A might initiate the session, but the same or similar addressing issues will exist.
* When B sends the session invitation to A, this invitation is sent using the IP address and port passed from A to B. For this to work, this port must be enabled to pass through any firewall between A and B.
* The actual Real-time Transport Protocol (RTP) streams are sent using dynamically allocated UDP ports in the range of 5004 – 65535. Without a way to open these UDP ports on any firewall in the path dynamically, the streams will fail to reach their destination.

[njs]

Originally posted by erik_bies
This is a problem of the messenger. It just needs so many open ports (all from 5004 – 65535.) that you firewall just renders useless (>60k ports open).
This is MS idea of security :-S

Here is what Microsoft says http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/winxppro/deploy/worki01.asp
Audio and Video

When negotiating an audio-video session, dynamic ports were chosen for the audio-video (AV) stream. Dynamic ports are used to enable the application to work regardless of what other applications are running on the system and using port resources. In the .NET Messenger case the session invitation was sent by station B to the address it received for station A.

The following issues might arise if a firewall or NAT were present in these scenarios:

* The address provided by A in either the session invite for session signaling, or in the session acceptance for the UDP streams, might be an internal address that is translated by a NAT device—an invalid (or fake) address for B to use to contact A. In other scenarios with the 4.5 client, A might initiate the session, but the same or similar addressing issues will exist.
* When B sends the session invitation to A, this invitation is sent using the IP address and port passed from A to B. For this to work, this port must be enabled to pass through any firewall between A and B.
* The actual Real-time Transport Protocol (RTP) streams are sent using dynamically allocated UDP ports in the range of 5004 – 65535. Without a way to open these UDP ports on any firewall in the path dynamically, the streams will fail to reach their destination.


Well, this is really interesting... :) Security? Sure.. ehehehe.. :rolleyes:

Although, it does not explain why in other routers it works without problems but on this one it doesn't.
I never had problems with Video, the problem here is only with the audio. This is quite strange...


Any sugestions?

Thanks.
Nuno

[erik_bies]

Video seems to be using a different port. No problems with that one myself here. Just audio suxx

I noticed this while using zonealarm firewall. Video & chat works fine, audio is not working untill you completely shut off zonealarm.

You might get it to work with uPnP, I never tried that myself, as my gateway does not support it.

Suc6
Erik

[njs]

hi

I'm having some problems with the audio in msn...
Sometimes the incoming audio, better saying, the received audio is stopped... The other person gets port unreachable icmp packets, in 90% of the time.. Sometimes there's no rejected packets..
This is really strange and happens in whenever moment of the audio conversation, or in the begging or in the middle.. with no natural pattern. The only pattern I find is that this probably might happen when the other side stops talking, but this happened in the middle of a conversation..

With Video I get no problems..

Does anyone has/had the same problem??

Other thing I find is the slowlyness that it takes to establish the audio connection........
I think the uPnP for this router is still very buggy.
Is there something we can do ??

Thanks.
Nuno

[mr_prof]

Hi boyz,

I was same problem with my Dlink router, and not found enought information about it.
I tried every silly things, and my conclusion:

For working MSN audio and filetransfer, you need the follow things:

1. Enable UPnP on NAT device
2. don't need any port forwarding or triggering
3. Windows XP and enabled UPnP protocol
4. MSN 6.1
5. DirectX 9.0b (it is incredible, but true, this is the key)


good luck

Tibor

[njs]

Originally posted by mr_prof
Hi boyz,

I was same problem with my Dlink router, and not found enought information about it.
I tried every silly things, and my conclusion:

For working MSN audio and filetransfer, you need the follow things:

1. Enable UPnP on NAT device
2. don't need any port forwarding or triggering
3. Windows XP and enabled UPnP protocol
4. MSN 6.1
5. DirectX 9.0b (it is incredible, but true, this is the key)


good luck

Tibor

Hi

This is my configuration.
When not using the router, it works OK.. connection is done in 2 or 3 seconds and only happened once to lost connection in incoming voice...
If I use the router, it takes ages to connect (when it connects), everytime it is disconnected I have to restart MSN again otherwise it doesn't connect. Lots of problems..
Is there a way to upgrade uPnP or something ? cause this is really anoying. I see other routers (brands) working fine.. only this one has this problems.

Bye
Thanks.
Nuno