Server rejection

[Robert]

FYI: in the example you have, if you send a bad userid/password/cert, the the program will crash with a segment fault; looks like it comes from around line 380 in Transport.cpp.

[Michał Słomkowski]

If login credentials are invalid, the intended behavior is to throw TransportException. Do you experience anything else, like segfault?

[Robert]

Yes, I was getting a segfault. I think there was nothing to catch the exception.

Have you written any code to play audio after it has been received? Same question for capturing microphone input.

Nice little program, really gets me started. Thanks.

From: Michał Słomkowski [mailto:[e-mail]]
Sent: Monday, March 21, 2016 4:16 PM
To: slomkowski/mumlib [e-mail]
Cc: Robert [e-mail]
Subject: Re: [mumlib] Server rejection (#10)

If login credentials are invalid, the intended behavior is to throw TransportException. Do you experience anything else, like segfault?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub #10 (comment) https://github.com/notifications/beacon/AKUG1ETiqhKswS9s-3n0xvs8dysIUsfZks5pvya4gaJpZM4H0xuk.gif

[Michał Słomkowski]

I fail to replicate segfault, I become something like this:

terminate called after throwing an instance of 'mumlib::TransportException'
  what():  failed to authenticate: wrong server password, reason: Invalid server password
Aborted

Can you wrap ioService.run() with try..catch(TransportException &e) to make to make sure it's not the default exception handler?

I don't have any code which communicates with audio device. This library was primarily written as a basis to https://github.com/slomkowski/mumsi - Mumble to SIP gateway.

[Robert]

When I get a chance I will give it a try.

I haven’t looked deeply, but is it possible that when the example receives an audio packet the code sends the same packet back to the sender?

I am trying to make a really simple non-gui mumble client. Very limited in functionality.

From: Michał Słomkowski [mailto:[e-mail]]
Sent: Monday, March 21, 2016 4:44 PM
To: slomkowski/mumlib [e-mail]
Cc: Robert [e-mail]
Subject: Re: [mumlib] Server rejection (#10)

I fail to replicate segfault, I become something like this:

terminate called after throwing an instance of 'mumlib::TransportException'
what(): failed to authenticate: wrong server password, reason: Invalid server password
Aborted

Can you wrap ioService.run() with try..catch(TransportException &e) to make to make sure it's not the default exception handler?

I don't have any code which communicates with audio device. This library was primarily written as a basis to https://github.com/slomkowski/mumsi - Mumble to SIP gateway.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub #10 (comment) https://github.com/notifications/beacon/AKUG1AGeQhxDpe2lVWEDSoKtGdqf-GLbks5pvy04gaJpZM4H0xuk.gif

[Michał Słomkowski]

I haven’t looked deeply, but is it possible that when the example receives an audio packet the code sends the same packet back to the sender?

That is exactly what example code is doing:

virtual void audio(int target,
                       int sessionId,
                       int sequenceNumber,
                       int16_t *pcm_data,
                       uint32_t pcm_data_size) override {
        mum->sendAudioData(pcm_data, pcm_data_size);
    }

It also echoes back the text messages:

virtual void textMessage(
            uint32_t actor,
            std::vector<uint32_t> session,
            std::vector<uint32_t> channel_id,
            std::vector<uint32_t> tree_id,
            std::string message) override {
        mumlib::BasicCallback::textMessage(actor, session, channel_id, tree_id, message);
        mum->sendTextMessage("someone said: " + message);
    }

[Robert]

That is what I thought it did with that code.

Of course, I can’t get the segfault now. Probably have changed too many things. Right now the catch works fine and loops with appropriate error.

From: Michał Słomkowski [mailto:[e-mail]]
Sent: Monday, March 21, 2016 5:45 PM
To: slomkowski/mumlib [e-mail]
Cc: Robert [e-mail]
Subject: Re: [mumlib] Server rejection (#10)

I haven’t looked deeply, but is it possible that when the example receives an audio packet the code sends the same packet back to the sender?

That is exactly what example code is doing:

virtual void audio(int target,
int sessionId,
int sequenceNumber,
int16_t *pcm_data,
uint32_t pcm_data_size) override {
mum->sendAudioData(pcm_data, pcm_data_size);
}

It also echoes back the text messages:

virtual void textMessage(
uint32_t actor,
std::vector<uint32_t> session,
std::vector<uint32_t> channel_id,
std::vector<uint32_t> tree_id,
std::string message) override {
mumlib::BasicCallback::textMessage(actor, session, channel_id, tree_id, message);
mum->sendTextMessage("someone said: " + message);
}

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub #10 (comment) https://github.com/notifications/beacon/AKUG1Mjzsjejyxmrzmheq3hqNlNAQqeIks5pvzuUgaJpZM4H0xuk.gif

[Robert]

I am having a really hard time to get audio to play, but that is just my lack of knowledge with audio tools in Linux.

From: Michał Słomkowski [mailto:[e-mail]]
Sent: Monday, March 21, 2016 5:45 PM
To: slomkowski/mumlib [e-mail]
Cc: Robert [e-mail]
Subject: Re: [mumlib] Server rejection (#10)

I haven’t looked deeply, but is it possible that when the example receives an audio packet the code sends the same packet back to the sender?

That is exactly what example code is doing:

virtual void audio(int target,
int sessionId,
int sequenceNumber,
int16_t *pcm_data,
uint32_t pcm_data_size) override {
mum->sendAudioData(pcm_data, pcm_data_size);
}

It also echoes back the text messages:

virtual void textMessage(
uint32_t actor,
std::vector<uint32_t> session,
std::vector<uint32_t> channel_id,
std::vector<uint32_t> tree_id,
std::string message) override {
mumlib::BasicCallback::textMessage(actor, session, channel_id, tree_id, message);
mum->sendTextMessage("someone said: " + message);
}

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub #10 (comment) https://github.com/notifications/beacon/AKUG1Mjzsjejyxmrzmheq3hqNlNAQqeIks5pvzuUgaJpZM4H0xuk.gif

[Robert]

I have been playing with it and I seem to be missing something in my
understanding.

If I want to automatically switch my user to a channel or send a text
message, where do I actually put the call in the code. I figured out that
since I am in a run, I can't put it in the main program. I just don't see
where I have control that isn't blocked that I can add such calls. Can you
please give me a pointer or two?

Thanks in advance.

Robert Grimes

[Michał Słomkowski]

Ideally, your program architecture should be event-driven. Take a look at Boost Asio library. I use it under the hood.

Another approach is to use threads. The mumlib library is more or less thread-safe. Look at Mumsi. One thread, created by pjlib, calls functions from my library.

[Robert]

Perfect, thanks for the insights.

From: Michał Słomkowski [mailto:[e-mail]]
Sent: Sunday, March 27, 2016 1:31 PM
To: slomkowski/mumlib [e-mail]
Cc: Robert [e-mail]
Subject: Re: [mumlib] Server rejection (#10)

Ideally, your program architecture should be event-driven. Take a look at Boost Asio library. I use it under the hood.

Another approach is to use threads. The mumlib library is more or less thread-safe. Look at Mumsi. One thread, created by pjlib, calls functions from my library.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub #10 (comment) https://github.com/notifications/beacon/AKUG1K84Qi-hSRzQQDN7NEEJoqjT4PRnks5pxukegaJpZM4H0xuk.gif

[Robert]

I hate to ask, but can you give me a link or idea how to find the documentation for all the mumble API classes? I found it several times but I never can remember what to look up. If you don’t know or don’t understand, no big deal. Thanks. (I am just getting to old to remember to bookmark it).

From: Michał Słomkowski [mailto:[e-mail]]
Sent: Sunday, March 27, 2016 1:31 PM
To: slomkowski/mumlib [e-mail]
Cc: Robert [e-mail]
Subject: Re: [mumlib] Server rejection (#10)

Ideally, your program architecture should be event-driven. Take a look at Boost Asio library. I use it under the hood.

Another approach is to use threads. The mumlib library is more or less thread-safe. Look at Mumsi. One thread, created by pjlib, calls functions from my library.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub #10 (comment) https://github.com/notifications/beacon/AKUG1K84Qi-hSRzQQDN7NEEJoqjT4PRnks5pxukegaJpZM4H0xuk.gif

[Robert]

grimes would like to recall the message, "[mumlib] Server rejection (#10)".