IOS Sinch voip call - Failed to decode message transport - ios
My incoming calls are constantly getting disconnected while it's ringing in (at least 3 times out 10 times)
The below is the log message when this happens.
(I'm using SinchRTC 3.4.1)
(SINLogSeverityTrace log)
REQUEST 3: Request PUT
https://sandbox.sinch.com/V1/Session{"ApplicationKey”:”My
ApplicationKey”,”CallStatistics":{"AudioLevelsDescription":["Timestamp","AudioInputLevel","AudioOutputLevel"],"AudioLevelsSamples":[],"Codecs":[],"RTCPDescription":["Timestamp","PacketsSent","PacketsReceived","PacketsLost","RTTMs","JitterReceivedMs"],"RTCPSamples":[],"RTCPTimestampBase":"1425452945396","RTCPTimestampNormalization":true,"ReportVersion":"2"},"CallTime":"/Date(1425452945396)/","ConnectionInfo":{"Host":"","Port":0,"Protocol":"","Type":""},"DeviceInformation":{"ModelId":"iPhone5,2","ModelName":"","OSName":"iOS","OSVersion":"8.3","PerformanceCharacteristics":"highend","SDKPlatform":"iOS","SDKPlatformVersion":"3.4.1"},"Domain":"","Duration":"0","FromId”:”MyFromId”,”Headers":{"ph":"{\"SIN\":\"Test
SIN call
header\"}\n"},"InstanceId":"98f61bf2-4439-41a5-ac78-a286f3d3eed4","MXPEventLog":{"Events":[["OUT","SENDING","2DE4D14E-5470-41C5-9309-BF942B948405","1425452945479","0","ACK","","{\"channel\":\"0b1ca3d2-94e6-4e65-9834-6d260abb310dS\"}"],["OUT","SENDING","2DE4D14E-5470-41C5-9309-BF942B948405","1425452945494","0","PEEREVENT","","{\"channel\":\"0b1ca3d2-94e6-4e65-9834-6d260abb310dS\"}"],["OUT","SENDING","2DE4D14E-5470-41C5-9309-BF942B948405","1425452945616","0","PEEREVENT","","{\"channel\":\"0b1ca3d2-94e6-4e65-9834-6d260abb310dS\"}"],["ERROR","","2DE4D14E-5470-41C5-9309-BF942B948405","1425452945662","{\"reason\":\"Failed
to decode message
transport\"}"],["ERROR","","2DE4D14E-5470-41C5-9309-BF942B948405","1425452945662","{\"reason\":\"Failed
to decode message
transport\"}"],["OUT","SENDING","2DE4D14E-5470-41C5-9309-BF942B948405","1425452945662","0","ERROR","{\"error\":\"Failed
to decode message
transport\"}","{\"channel\":\"0b1ca3d2-94e6-4e65-9834-6d260abb310dS\"}"]],"Version":"2"},"Outbound":false,"Result":"4","SessionId":"2DE4D14E-5470-41C5-9309-BF942B948405","SetupDuration":"0","Signature":"3+cqz4D6N9dpwS8w9mxAz7gW3oQ=","ToId”:”My
ToId”,”UserId”:”MyUserId”}
(SINLogSeverityCritical log)
Failed to decode message transport
Failed to decode message transport
I wonder what situation causes this kind of problem.
Anyone with a similar problem?
Have you been using an older version of the Sinch SDK (iOS or Android) during testing? This problem might result from creating many instances for the same user id on multiple SDK versions. One way to test this hypothesis would be to start your Sinch client with a new unused user id using the latest SDK for iOS and Android (https://www.sinch.com/downloads/) - you should not be getting this error in that case. Meanwhile we will continue investigating on our side why those rare cases (as described above) are failing to connect.
Related
Twilio Device Cannot Be Connected : Twilio Js
I have an issue regarding Twilio Javascript SDK and stuck in a situation where the issue directly involve IOS and RTC support. Right now, i cannot connect the twilio device after device is ready. There is no error or anything to track/debug. Constantly, running the connection.status() return back connecting always. I think the signaling system works when there is an incoming call but again, connection.accept() and status remain connecting like forever. Application Overview Cordova/Phonegap app https://media.twiliocdn.com/sdk/js/client/releases/1.6.9/twilio.min.js shim:https://webrtc.github.io/adapter/adapter-1.0.2.js https://github.com/BasqueVoIPMafia/cordova-plugin-iosrtc Possible reasons: Can this be directly CSP issue? or I have you setup configuration using STUN/TURN? Let me know if you need any information. It's not going to resolve because there is no error just "connecting" status.
Unable to get firebase token on DP6.1
I have my RPi 3 connected to the internet through an ethernet connection. But I keep receiving these messages on the LogCat. W/GooglePlayServicesUtil: Google Play services out of date. Requires 11910000 but found 11745330 W/FA: Service connection failed: ConnectionResult{statusCode=SERVICE_VERSION_UPDATE_REQUIRED, resolution=null, message=null} E/FA: Discarding data. Failed to send event to service W/FirebaseInstanceId: No response E/FirebaseInstanceId: Token retrieval failed: TIMEOUT W/FirebaseInstanceId: No response E/FirebaseInstanceId: Token retrieval failed: TIMEOUT W/FirebaseInstanceId: No response E/FirebaseInstanceId: Token retrieval failed: TIMEOUT However, firebase cloud messaging works perfectly fine on DP6. Please advice.
The release notes page for Android Things indicates the version of Play Services available for each release of the OS. Developer Preview 6 (and 6.1) includes Play Services version 11.6.0, however it looks like you might be trying to use the latest (11.8.0) client library in your app. The client library version(s) in your build.gradle file must be equal to or lower than the version on the system you are using.
HTTP request times out. Weak wifi or slow server?
I have a client/server application where the client is an iOS app and the server is a RESTful api. I have received complaints of requests timing out and I know that some/most of the time, this is due to poor wifi connectivity. In these situations I would like to display an error message on the client which indicates whether the request was received by the server. Is it possible in iOS to tell the difference between a HTTP request that never reaches the intended destination and one that makes it all the way to the intended destination but never receives a response?
API Call only after you check whether your internet connectivity is reachable or not .show error message if not connected to internet(this is due to poor wifi connectivity) Example : Check for internet connection availability in Swift When its checked make api call handle error code 404(never reaches the intended destination) and 504(timeout error code never receives a response) and let user make it success only when status code is 200.But its good to handle 401(authorization error) also. I don't know which library you are using that why can't provide any code example right now Try Alamofire Library in swift I suggest handled error codes very well.
Secure Signals between iOS and PC
I have a PC and an iOS device. the iOS device is using alljoyn 15.04 and the PC is using alljoyn 15.09. Both implement the same secure interface. We have secure signals as a part of this. Our strategy includes joining a peer's session as soon as we discover them, then forcing authentication by calling a method on the remote device - using auth mechamism: ALLJOYN_ECDHE_PSK This all works great! Now, I can send a secure signal just fine from one ios device from another. I can also send a secure signal from the iOS device to the PC just fine. The PC can send a secure signal to another PC, but it cannot send a secure signal to the iOS client We've compared everything - session options, interface names/options, bus connection options, etc. and everything is the same. Then I found this error in the alljoyn log on the iOS side: 145.449 ****** ERROR ALLJOYN iodisp2_2 .../src/Message_Parse.cc:1078 | Failed to read message on :wYxt8HAP.73: ER_OS_ERROR I have no idea what to do about this. Can someone help? I was hoping to not run into any lower level bugs like this with alljoyn. Dang. Thanks for any help!
This error can occur if you are trying to send a secure signal out on session 0 (sessionless) instead of a valid hosted session. This is because the other end cannot decrypt the signal with your group key for the session. If you are hosting the session then try sending the signal out on ajn::SESSION_ID_ALL_HOSTED and see if that works.
What would be the best way to handle APNS 0 - Byte response - Technical Note tn2265
In the technical note, tn2265 apple describes how to handle errors while attempting to send batch push notifications: (direct quote) Here's how to check for errors when using the enhanced notification format. Keep writing until a write fails. If the stream is ready for writing again, resend the notification and keep going. If the stream isn't ready for writing, see if the stream is available for reading. If it is, read everything available from the stream. If you get zero bytes back, the connection was closed because of an error such as an invalid command byte or other parsing error. If you get six bytes back, that's an error response that you can check for the response code and the ID of the notification that caused the error. You'll need to send every notification following that one again. My question relates to the text I have highlighted in bold. For the record, I am using the Enhanced Notification Format, and I am passing in my unique ID for each recipient in the my list, so as the APNS service can return this id in case of errors. In case we receive 0 bytes back, i.e. Apple has closed the connection without sending an error code back, we cannot know after which attempted device token the error occurred. I.e. we cannot resume sending from that or the next token. In this case, is it acceptable to attempt re-sending to all the devices again? Is this not going to result in devices being "spammed" by the same notification multiple times? For example: Assume I have a list of 5000 devices to send to. The 0-byte response problem occurs after I have successfully sent to a random part of my list, and I do not know how many devices AND which ones have actually received my notification. Not having an error code returned with the device id of the last successful device, or the device at which the error occurred, does not allow me to resume sending from the next token, which was the whole purpose behind using the Enhanced Notification Format in the first place. How have others handled this issue? I would appreciate any thoughts or suggestions. Thanks in advance for your assistance.