[Blink] BLINK FOR WINDOWS - Problem when using the buttom ON HOLD

Dan Pascu dan at ag-projects.com
Wed Jan 9 15:20:19 CET 2013


On 26 Dec 2012, at 17:58, Peliza Carlos wrote:

> Hi Dan:
> According to your explanation
> 
> 1. sendrecv, sendrecv (the two sides are talking)
> 2. sendonly, inactive (Blink puts on hold the other side, Eyebeam puts its own side as inactive because he doesn´t want                                 hear mediastreams if he wishes to hear mediastreams, he should put itself as recvonly but according                             to RFC 3264 ,it is correct)
> 3. recvonly, inactive (here is the thing that i dont understand, why "Blink" suggests "recvonly" instead "sendrecv", if                                 when i press the "Blink" "on hold" and want to continue with the conversation).
> 
> I think that the correct behavior for Blink, would be, send a "sendrecv", in point 3 after and the other side (the right side) must  give response with sendrecv (to continue with talk)
> 

There is no correct behavior, as the RFC doesn't define one. The RFC only indicates a few rules and they are about what an answer to an offer needs to be or what to use to put a call on hold based on what previous state you had. So in this regard your interpretation of what Blink should send to resume from hold or what Blink actually does right now can both be considered correct because the RFC doesn't define a clear policy of how it should be done.

In this light, I will stick with Blink's behavior, as from my point of view the other device is also on hold as it keeps sending inactive. As the device says it's inactive I have no reason to attempt to send anything to it, hence the recvonly indicating I'm willing to receive, so we can resume as soon as the other device decides to resume itself.

Besides I tested this with Eyebeam and it doesn't behave the way you say. In my case Eyebeam's response to Blink's sendonly was recvonly not inactive. Maybe you have an older version of Eyebeam that behaved differently and they fixed it since. In all my testings with Eyebeam things worked just fine, except one particular case when both endpoints explicitly put the call on hold and resumed it in a certain order, where Blink had a bug which we fixed and the fix will be available in the next release.

P.S. please send your replies to the mailing list, as I will not longer reply to messages that are sent to me personally

--
Dan







More information about the Blink mailing list