Audio/Video conversation

[kakaroto]

ah ok... well, it should have actually sent video (une fausse video, juste une image statique en fait) even if you don't have one.. so it didn't show anything, means it still doens't work...
now all my hope is with jones!

[MastaG]

I'm on Fedora 10 x64 and I have it updated
These are the latest packages in the repo's which I have installed:
gstreamer-0.10.21-2.fc10.x86_64
gstreamer-plugins-ugly-0.10.10-2.fc10.x86_64
gstreamer-plugins-flumpegdemux-0.10.15-4.fc10.x86_64
gstreamer-plugins-good-0.10.13-1.fc10.x86_64
gstreamer-plugins-good-devel-0.10.13-1.fc10.x86_64
gstreamer-plugins-base-devel-0.10.21-2.fc10.x86_64
gstreamer-tools-0.10.21-2.fc10.x86_64
gstreamer-python-0.10.12-1.fc10.x86_64
gstreamer-plugins-bad-extras-0.10.9-1.fc10.x86_64
gstreamer-plugins-farsight-0.12.9-3.fc10.x86_64
PackageKit-gstreamer-plugin-0.3.14-1.fc10.x86_64
gstreamer-plugins-base-0.10.21-2.fc10.x86_64
gstreamer-devel-0.10.21-2.fc10.x86_64
gstreamer-plugins-bad-devel-0.10.9-1.fc10.x86_64
gstreamer-ffmpeg-0.10.5-1.fc10.x86_64
gstreamer-plugins-bad-0.10.9-1.fc10.x86_64

libnice-0.0.6 compiles and installs fine with:
./configure --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc --localstatedir=/var
make && sudo make install

However farsight2-0.0.8 and 0.0.9 dont compile because they complain about my gstreamer being too old.
So I´m using 0.0.7 compiled and installed with:
./configure --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc --localstatedir=/var --disable-python
make && sudo make install

The latest svn of amsn builds fine even though I'm not using the latest version of farsight2.
Is it a big problem?
Since I don't feel like building the complete gstreamer suite just to satisfy farsight2.

The Audio/Video wizard in aMSN passes the audio conversation check.

[kakaroto]

@MastaG: if you can make a call then why complain? :p
the newest farsight needs gstreamer 0.10.22, it's always better to use the latest versions available, it makes things more stable, better, etc.. but I think you can still with farsight2 0.0.7.
I've just updated today the wiki to state the new dependencies' versions.

[kakaroto]

@jones: hellooooo, come on! I'm still waiting to see what you did, I'm still unable to get it to work!

[jones]

Hi kakaroto,
I find some diffenenecs. I create two fsrtpconference, and aMSN create two session in the same fsrtpconference, if we use the same fsrtpconference, and the foundations of ICE candidates are not similar to WLM2009 exactly. For example, foundations will be the following: audio 1 3, video 2 4, not audio 1 2, video 1 2. Is it a problem, I don't know.....
By the way,  I get the svn version aMSN, and when I do the video call with WLM2009, WLM2009 can get the successful connect message, but aMSN doesn't show any video(both self preview and remote), is it normal? or I should make some config?

[kakaroto]

ok jones, thanks, i'll try separating this into two fsrtpconference *for testing* .. but it should not be done this way, it has to be one conference with two sessions! It's necessary for audio/video synchronisation, RTCP, and it has to be the same SSRC, the concept of sessions is there for a reason... ICE processing also needs this for candidate nomination and speeding up the connection, etc...
Also the ICE foundations are just strings, they can be absolutely anything, so if it's "1" or "2" or "foobar" it doesn't make any difference.
Anyways, yes, if you try the SVN version, it will be only audio call, not video call that's why it won't show anything... You'd have to connect using MSNP18 if you want to do the video call.. open the amsn console with ctrl-shift-C from the main window and type

Code:

::config::setKey protocol 18

before connecting... then when you make an audio call it will actually be a video call too..
the preview window won't show though, only the remote video will be shown for you.

Anyways, jones, this is like the 4th time I'm asking for your work, everytime you say a little thing and it's not very helfpul.. I'm sure that even if I use two fsrtconference instead of one, it still won't work, then i'll ask you again about the code and you still will only tell me what difference you see, etc... and we'll never finish!
Jones, can you please send me the source code of what you've done, you said it's for pidgin, which is open source software anyways, so the license makes it that it has to stay open source and you must provide the source code... so it's not like you're doing it for some company who wants the code to stay closed source...
if you don't want to make your work public yet (you want it to be finished/stable/etc... before releasing it), then I can understand, no problem then, I wouldn't give the code to anyone, so if you could just send it to me directly by email, I would only use it to find what I'm doing wrong. This will make things 100 times easier/faster....
You can mail me at : kakaroto  AT users.sourceforge.net

Thanks!

[zyazhou]

Hi, kakaroto
I'm updating my own client to support MSN2009 audio. But something wrong happpens after ice connectivity check. MSN2009 side can hear my audio, but I cannot hear audio from MSN2009. Furthermore, after about 30 seconds MSN2009 hang up this call. I only send Binding Request to MSN2009 TURN candidate(not local or stun candiate, I want to make it simple first), and can receive Bindng Response from this candidate. I don't know what's going wrong. Could you give me some help? Thanks in advance.

By the way, MSN2009 is behind a symmetric NAT, and my client is on a public IP. As my understanding, if I only use TURN candidate, there should be no any deprived candidate for symmetric NAT reason. That's why I want to make it simple first.

[jones]

Hi kakaroto,
Sorry about the source code, there are some reasons....so.....
But I find a mistake of the UUN command that aMSN sent.
The UUN command need to carry the machine guid except the first sip invite message if the role is inviter. Because the MPOP  feature, we should assign the machine guid.
Example: "UUN TrID xxx@mail;{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX} 12 length"
But aMSN always not carry the machine guid, but after I add the machine guid, it still won't work.

And I find out that you mean it won't work is the WLï¼­ shows the no webcam picture not the gray frame...
so I think it may have some problems in sip messages not in pipeline,
I assume that WLM get the gray video at all times.....because when I don't set the do-timestamp and rtp-payload-size, the WLM will show the gray frame not the no webcam..

Anyways, I will keep to find the issue of aMSN...

[kakaroto]

@zyazhou: Make sure that the ICE connectivity checks worked correctly and that both amsn and WLM say that it was connected. Also make sure that the volume is correctly set so you can hear stuff and try testing the microphone on WLM...
About the 30 seconds timeout, it was a bug in libnice at some point, so make sure you are using the 0.0.6 release.

@jones: Ok, thanks for the help! I understand your issue about the source code, but if you could be nice enough to send me the source code in private by email, I'll make sure to keep it for myself and I won't release it to anyone, I'll only use it to test and fix aMSN. But thanks anyway for trying to find the issue with aMSN and helping in fixing it!
Yes, I've noticed that it shows the no webcam icon.. I thought it was because it couldn't decode the h263 and showed it, but I also tried without sending any video at all and it still showed that icon so it's not be the stream itself.. I'm pretty sure it's the SIP signaling that is wrong somewhere but I couldn't find any differences... I'll try to fix the UUN too and see if it changes anything. I also tried sending the UUN 11 stuff too (where it sends "5 1 1" with "11" instead of "12" in the UUN line) once the INVITE/200 is sent, but it didn't help.. do you send that stuff too ?
I noticed that if I try with a WLM that doesn't have a webcam, it shows the same icon, so I'm thinking maybe my signaling is telling WLM somehow that I don't have a webcam... but I wasn't able to see any difference between the signaling when WLM has or when it doesn't have a webcam plugged in, but there's obviously something there to tell it "I have no webcam".
I'll continue looking at this tomorrow, hopefully, I'll find something.. otherwise, I'll be waiting for your code...
If you really *really* can't send me the source code, even though I'll keep it private, then maybe try emailing me both the protocol log and a wireshark dump, so at least I can compare with that!
Thank you again!

[kakaroto]

Hey Jones! Thanks for all the help, in the end, I found out what the problem was.. I just wasted weeks on this... the solution was SO simple...
The clientid needed the 'HasWebcam' capability enabled... So if you actually had aMSN configured to show your webcam (so others can see a little 'webcam' icon next to your name), then the video conference with H263 would have worked.. if you didn't have it, then the 'no webcam' icon would be shown...

[MastaG]

Hi kakarot, nice work man:)
I've updated my fedora to rawhide and now ships with libnice-0.0.6 and farsight2-0.0.9.
I'll give the video-chat a try and report here as soon as possible.
BTW: Why isnt msnp18 the default protocol for aMSN?

[kakaroto]

You're welcome!
MSNP18 isn't enabled by default because MPOP support is not stable and more importantly, it's because the P2P stack is completely different and not yet reverse engineered... so all MSNP2P stuff won't work (display picture, custom emoticons, file transfer, etc..)

[flomar34]

Hello,

I still have no webcam

With revision 11138
amsn call wlm 9
amsn recieve webcam and audio
wlm9 don't recieve audio

With revision 11143
amsn call wlm 9
amsn don't recieve audio, recieve an video screen with something like a "mire" : some colors like if it can't decode it. But The video screen appear before wlm9 accept the video call
amsn don't recieve sound
wlm9 don't recieve audio


I've made the tests with libnice 6 and farsight 9.

[MastaG]

You're welcome!
MSNP18 isn't enabled by default because MPOP support is not stable and more importantly, it's because the P2P stack is completely different and not yet reverse engineered... so all MSNP2P stuff won't work (display picture, custom emoticons, file transfer, etc..)

I always thought MS were forced to give the specs of their protocol.
Doesn't the European law state something like that?
So they can't have a monopoly position on their messenger.

[jones]

Oh...I just want to check the clientid and than you found it, both we forget the clientid....
But congratulation, it works eventually.
By the way, the new p2p protocol is not so friendly......

Hey Jones! Thanks for all the help, in the end, I found out what the problem was.. I just wasted weeks on this... the solution was SO simple...
The clientid needed the 'HasWebcam' capability enabled... So if you actually had aMSN configured to show your webcam (so others can see a little 'webcam' icon next to your name), then the video conference with H263 would have worked.. if you didn't have it, then the 'no webcam' icon would be shown...