Call transfer not working with asterisk and same lan

[janno]

There seems to be a problem then using asteriks and call transfer.

If qutecom is setup to asterisk and forwards a call to another computer on the lan then it seems like qutecom is trying to send stream directly to another qutecom client which is not desired function.

What happendse then is that sometimes user hear each other, sometimes they don't. Also playing with hold function sometimes restores working situation.

By looking at tcpdump i can see that qutecom is send udp stream directly to another qutecom client (which is should not do , since calls need to go through asterisk (for call monitoring etc.).

Then 2 users are separate lan and don't have direct connection to eachother then everything works as expected.

[vadim]

This should be fixed in Asterisk config to interdict direct media streams

[janno]

Replying to vadim:

This should be fixed in Asterisk config to interdict direct media streams

The attribute "directmedia=no" has been set in asterisk what AFIK should prohibit direct media streams.

[vadim]

Please attach wireshark capture with problematic behaviour

[janno]

call log

[janno]

I have added attatchement.
192.168.5.206 calls to 192.168.5.208 using asterisk. Call is accepted and everything works as expected. If caller puts call on hold then other one hears music. If call is taken off hold, then double data streams start to flow and i can hear garbage on caller and it's all quiet on reciever.

dump was made using this cmd: tcpdump -lnni eth0 src 192.168.5.6 or dst 192.168.5.208 or src 192.168.5.208 or dst 192.168.5.208 -w call_dump

192.168.5.6 is asterisk server.

[janno]

I'm putting out 100€ reward/donation (paypal, invoice) for resolving this issue.

[vadim]

Janno,

The dump is very strange it does not contains SIP traffic FROM QuteCom...

Can you make a wireshark capture on machine runing QuteCom?

[janno]

Replying to vadim:

Janno,

The dump is very strange it does not contains SIP traffic FROM QuteCom...

Can you make a wireshark capture on machine runing QuteCom?

What do you mean. Isn't that correct?:
717 23.361724 192.168.5.208 192.168.5.206 RTP 214 PT=ITU-T G.711 PCMU, SSRC=0x32FCA792, Seq=370, Time=59200
718 23.381728 192.168.5.208 192.168.5.206 RTP 214 PT=ITU-T G.711 PCMU, SSRC=0x32FCA792, Seq=371, Time=59360
719 23.401710 192.168.5.208 192.168.5.206 RTP 214 PT=ITU-T G.711 PCMU, SSRC=0x32FCA792, Seq=372, Time=59520

Seems like this "double data stream" occurs only then forwarding a call. Nevertheless - it seems that things start to go wrong allready then I put a call on hold. So we should start with that.

[vadim]

Replying to janno:

Replying to vadim:

Janno,

The dump is very strange it does not contains SIP traffic FROM QuteCom...

Can you make a wireshark capture on machine runing QuteCom?

What do you mean. Isn't that correct?:
717 23.361724 192.168.5.208 192.168.5.206 RTP 214 PT=ITU-T G.711 PCMU, SSRC=0x32FCA792, Seq=370, Time=59200

Sure, this is RTP traffic i'm talking about SIP traffic (reply to INVITE request coming from Astreisk)

[janno]

tcpdump3_host_fixed

[janno]

Replying to vadim:

Replying to janno:

Replying to vadim:

Janno,

The dump is very strange it does not contains SIP traffic FROM QuteCom...

Can you make a wireshark capture on machine runing QuteCom?

What do you mean. Isn't that correct?:
717 23.361724 192.168.5.208 192.168.5.206 RTP 214 PT=ITU-T G.711 PCMU, SSRC=0x32FCA792, Seq=370, Time=59200

Sure, this is RTP traffic i'm talking about SIP traffic (reply to INVITE request coming from Astreisk)

You are correct. The tcpdump command was too restrictive. Now it should be fixed. I have attatched a new dump.

On this one behaviour is like this: I could put the call on hold few times and last 2 times it did not recover from it. I can hear the "repeating" sound after resuming from "hold".

[vadim]

I've examined the latest capture and don't see anything abnormal with it.
The is NO direct RTP traffic between 2 QuteComs? . The RTP is going only between QuteCom and Asterisk

There is one strange bit is that Asterisk seems to ignore rhe last HOLD request (packet 1570) and continues
to send audio to QuteCom to which QuteCom

[janno]

Replying to vadim:

I've examined the latest capture and don't see anything abnormal with it.
The is NO direct RTP traffic between 2 QuteComs? . The RTP is going only between QuteCom and Asterisk

There is one strange bit is that Asterisk seems to ignore rhe last HOLD request (packet 1570) and continues
to send audio to QuteCom to which QuteCom

Actually there will be. I will make another dump for you. Just while making a dump for you I discovered that it breaks before i even get to forwarding a call. I just wanted to know why putting on hold breaks. Because after this "hold" thing breaks i can't get the call between the 2 callers to function anymore so I even can't be sure what happends with call transfer later on.

[jako]

Same problem here. yet somehow switching on and later off the check-box of presence info (SIMPLE) in Advanced settings in login dialog changes the behaviour. Might be worth looking into.
(QuteCom 2.2 on Ubuntu 11.10)