search

fpm123 / sipml5

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

BYE not received #82

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Register two SIPML5 web clients to SIP server sip2sip.info
2. User A make a call to user B
3. User B hang up

What is the expected output? What do you see instead?
User A should receive the BYE command sent by user B to notify the web client 
with a terminated event. Instead the BYE command is not received.

What version of the product are you using? On what operating system?
Windows XP
Chrome (Version 25.0.1364.172)
SIPML5 web client (SIPML5 API version = 1.2.185)

Please provide any additional information below.
If it is the same user who make the call and hang up the BYE command is well 
received.
Issue reproduced with a kamailio server too.

Original issue reported on code.google.com by emerik...@gmail.com on 22 Mar 2013 at 9:31

Attachments:

GoogleCodeExporter commented 8 years ago 
I have the same problem too..
Windows 7
Chrome 27.0.1430.0
SIPML5 web client API version 1.2.185
IMSDroid 2.544.836
opensips SIP Server
I find this in the logs of webrtc2sip : "Request for peer at(null):65535 cannot 
be delivered"
and this in logs of sipml5 : 
"__tsip_transport_ws_onmessage SIPml-api.js:1 recv=SIP/2.0 408 Request Timeout 
"... 
seems like imsdroid did n't receive "BYE" from SIMPL5

Original comment by Napoleon...@gmail.com on 28 Mar 2013 at 12:54

GoogleCodeExporter commented 8 years ago 
i have found that SIPML5 send BYE to wrong contact uri, e.g. 

ClientA IMDroid IP:10.10.132.201:44595
ClientB sipml5 IP:10.10.132.246
server webrtc2sip + opensips IP: 10.10.132.49

ClientA send INVITE to server without CONTACT Header, 
but server forward it to Client B with wrong CONTACT Header 
(like this: <sip:clientA@10.10.132.49:10060;transport=ws>)
,when ClientB send BYE to ClientA,it use wrong uri..so 408 happened.

i fix it from sipml5, when ClientB received the ACK(after ClientB accept all) 
from ClientA, it update dialog's o_uri_remote_target again. it works.
i upload the source ,hope it is helpful.

Original comment by Napoleon...@gmail.com on 1 Apr 2013 at 12:23

Attachments:

GoogleCodeExporter commented 8 years ago 
This is not an issue in SIPML5 but WebRTC2SIP: 
https://code.google.com/p/webrtc2sip/issues/detail?id=56

Original comment by boss...@yahoo.fr on 4 Aug 2013 at 1:17