search

fmwviormv / doubango

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

Call is terminated after answer #237

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Start audio or video call on device A
2. Press answer on device B

What is the expected output? What do you see instead?
Call is terminated on device A. 

What version of the product are you using? On what operating system?
Latest doubango used for ios. Server: kamailio with rtpproxy, 

Please provide any additional information below.

It works fine with revision r832.

You can find device logs in attach.

Original issue reported on code.google.com by denis.tr...@gmail.com on 8 Apr 2013 at 3:49

Attachments:

GoogleCodeExporter commented 9 years ago 
device B ends the call because it doesn't receive the ACK for the 200. Are you 
sure such request is sent to the right port/ip?
Do you have same issue with UDP?

Original comment by boss...@yahoo.fr on 8 Apr 2013 at 3:54

GoogleCodeExporter commented 9 years ago 
Call is termitated also with UDP. Why does it work fine with revision 832?

I accept log with r832.

Original comment by denis.tr...@gmail.com on 8 Apr 2013 at 4:30

Attachments:

GoogleCodeExporter commented 9 years ago 
Do not obfuscate IP addresses using same pattern *.*.*.*.
Each address must be replaced by it's own pattern (x.x.x.x, y.y.y.y, 
z.z.z.z...) otherwise, we cannot understand what's going on.

Original comment by boss...@yahoo.fr on 8 Apr 2013 at 4:42

GoogleCodeExporter commented 9 years ago 
*.*.*.* is server IP.

Original comment by denis.tr...@gmail.com on 8 Apr 2013 at 4:43

GoogleCodeExporter commented 9 years ago 
Оne clarification: we have server behind NAT.

Original comment by denis.tr...@gmail.com on 8 Apr 2013 at 4:49

GoogleCodeExporter commented 9 years ago 
Looks like the ACK is never received by your server as it continue to send the 
200 OK.
Tried with Xlite, Bria and Linphone using your network and got same issue.
The problem looks to be the "Record-Route" in the responses as it says to send 
the ACK to x.x.7.24 which is most likely not valid (or no one listening).

Original comment by boss...@yahoo.fr on 10 Jun 2013 at 11:23

GoogleCodeExporter commented 9 years ago 
Is there an explanation why revision 832 worked with the same server settings?
This may give us some clues.

Original comment by apakho...@gmail.com on 13 Jun 2013 at 8:19

GoogleCodeExporter commented 9 years ago 
There was a bug in these revisions as we always send back the response to the 
proxy address instead of the first Route.

Original comment by boss...@yahoo.fr on 13 Jun 2013 at 8:25

GoogleCodeExporter commented 9 years ago 
I idded in kamailio config:

 if (!is_method("REGISTER|MESSAGE")) 
 { 
       record_route_preset("x.x.x.x"); //external server address
 }

The call is not terminated now. But the route is lost after re-INVITE.

Original comment by denis.tr...@gmail.com on 17 Jun 2013 at 6:48

GoogleCodeExporter commented 9 years ago 
https://code.google.com/p/doubango/issues/detail?id=285

Original comment by boss...@yahoo.fr on 2 Jul 2013 at 8:00