rzmudzin / doubango

Automatically exported from code.google.com/p/doubango
0 stars 0 forks source link

Call transfer problem #458

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
a) Before posting your issue you MUST answer to the questions otherwise it
will be rejected (invalid status) by us
b) Please check the issue tacker to avoid duplication
c) Please provide network capture (wireshark) or Android log (DDMS output)
if you want quick response

What steps will reproduce the problem?
1. I have one Android device with Dubango (IMSDroid). I have two another SIP 
softwares (PJSIP under Linux). OpenIMS is the SIP server.
2. I begin making a call between IMSDroid and one PJSIP software. Next I ask 
for a call transfer from the PJSIP software to the other.
3. All appears to be OK. IMSdroid is asking me if I agree with the call 
transfer, a new INVITE is sent and the new call is established. But at the end 
of the transfer, I have no voice in one way (from IMSDroid to PJSIP).

What is the expected output? What do you see instead?
What I can see is that Android device send no RTP packet but understand those 
received by PJSIP.
I tried with two Android devices with the same result. I tried replacing 
Dubango with a third PJSIP software and it is working.

What version of the product are you using? On what operating system?
I am using Dubango revision r1309 (IMSDroid revision r585) and PJSIP 2.4.

Please provide any additional information below.
Please find in attachment two pcap captures one is working (RTP in both ways 
after call transfer) and the other not.

Original issue reported on code.google.com by jlenoir....@gmail.com on 6 Aug 2015 at 1:17

Attachments:

GoogleCodeExporter commented 9 years ago
maybe i have the same problem, my turn server is rfc5766-turn-server, i found 
that after create permission and binding channel success, idoubs try to send 
bind msg to the opposite relay address(the turn server),but the turn server 
never send it out. i guess the application data send to relay server is not 
followed with RFC5766.

Original comment by pengliny...@gmail.com on 14 Aug 2015 at 2:47