[Blink] BLINK FOR WINDOWS - Problem when using the buttom ON HOLD in calls, with another softphone

[Dan Pascu]

I see nothing wrong in the traces you sent me. Blink's behavior is correct. The reason you get recvonly is because the other side is still on hold (it hasn't changed it's status from inactive).

In the trace you sent:

1. sendrecv, sendrecv
2. sendonly, inactive
3. recvonly, inactive

At step 1 conversation starts. At step 2, is put on hold from the left side. The right side's answer is a bit unusual here (inactive) which indicates the right side also considers itself being on hold. Normally it should have responded with recvonly. At step 3, the left side returns from hold but because the right side is inactive (i.e. still on hold on its own) it sends recvonly. The phone on the right side is also a bit weird at step 3 as it should reply with sendonly. Inactive is not incorrect, but it results in the behavior you see. 

In conclusion the reason why the call doesn't resume from hold is not blink, but the other device which is still on hold.

On 10 Dec 2012, at 15:56, Peliza Carlos wrote:

> Hello my name is Carlos and I'm trying to obtain my graduation as an engineer.doing my thesis, which is to test the interaction between
> free softphones in calls against Eyebeam.
>  
> One of the tests to be performed, is a call from "Blink" to  Eyebeam.
> Pressing the HOLD ON button on Blink, waiting a while and re-press the HOLD ON to continue the call.
> In this test, I have observed:
>  
> The RFC 2543 is obsolete and there is not used by Blink.
>  
> According to RFC 3264  the procedure should be:
>  
> 1) Who puts ON HOLD (Side A) sends an invite with "sendonly" attribute in SDP
> 1.a) If the media stream was the result of a prior "sendrecv", side B  responds "recvonly"
> 1.b) Side B send an "inactive" attribute after "sendonly" receive, if the media stream  was the result of a prior "recvonly"
> 2) To re-press "ON HOLD", the A side sends the attribute "sendrecv"  or empty  (due to sendrecv is the default value)
> 3)Conversation is restarted .
>  
> However, in my tests, BLINK sends recvonly instead of sendrecv, to resume the conversation therefore never occurs again.
>  
> Please tell me  you found if this problem in tests, and let me know your opinion.
>  
> Thank you and happy to help
>  
> <image003.jpg>
>  
> 
> 
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
> 
> The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
> 
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
> _______________________________________________
> Blink mailing list
> Blink at lists.ag-projects.com
> http://lists.ag-projects.com/mailman/listinfo/blink


--
Dan