[SIPForum-discussion] Call hold scenarios

[Paul Kyzivat]

On 6/5/15 2:57 PM, Dipan Kumar wrote:
> Thanks to all for your responses ,It really helped me a lot........
>
> So, what I understood from the above mails ,Please correct me if I am wrong.
>
> sendonly ->.( in 2 possibe cases) -> MOH and normal hold (without MOH)

Yes, I believe it is relatively common to use this even when there is no 
intent to send audio. Of course in this case the other side is still 
listening for audio, and will play it if received.

> Inactive -> Only incase of UAS sending reInvite for putting UAC on hold
> ,where UAC already put UAS on hold .

It is also permissible to use this when you don't intend to send audio. 
IMO this is *better* if you don't intend to send any. It saves the other 
end from listening for it, and is a hint that the other end can do as it 
wishes. (E.g. supply local audio.)

> 1.what will happen if we put inactive in reInvite for holding a normal
> call (no MOH) ?

It should be fine. You may encounter some buggy implementations that get 
upset in some way with this.

>      Is this case feasible?

Entirely.

> 2.Also I found few contradicting points from the above mail chain
>
>     @sumedha :if UAS is responding with inactive , then UAS don't want
> to play the received media on holding call so it      intimate that do
> not send media
>
> to whom it will initimate UAC ?

If you receive inactive in an answer (regardless of what you offered) 
then you should not send any media for that stream. (But you should 
still send RTCP per specifications.)

> @Paul :in the inactive case the other end can play its own music on hold
> if it wants.
>
>
> 3. Is it mandatory that hold (inactive) also get Inactive in response ?

Yes. Inactive in an offer MUST always get inactive in the answer.

	Thanks,
	Paul

> On Fri, Jun 5, 2015 at 3:55 PM, Pravat Panda <pravat.panda42 at gmail.com
> <mailto:pravat.panda42 at gmail.com>> wrote:
>
>     Yes,
>
>     You are right ,  i am adding a scenario on this,
>
>     Lets say A put on hold B  sending sendonly mode set in attribute
>     line a=SendOnly (MOH Scenario)
>
>     B is getting Music , if B want to hod Music (want not to listen ) ,
>     in that cases B will send in attribute a=inactive , not send only......
>
>     hope you are getting my point.....
>
>     On Thu, Jun 4, 2015 at 4:45 PM, Sakharam Thorat
>     <sakharam.thorat at outlook.com <mailto:sakharam.thorat at outlook.com>>
>     wrote:
>
>         i found following,
>
>         Case 1 (a=sendonly used for putting call on hold)
>
>         =====
>         A wants to put call on Hold
>           A(INVITE a=sendonly)----------------->
>           B(200 ok a=recvonly)<------------------
>
>         Now B wants to put call on hold ..it will send inactive or sendonly...this
>         is also debatable
>           B(INVITE a=inactive) <-----------------
>           A(200 ok a=inactive) ------------------>
>
>
>         Case 2 (a=inactive used for putting call on hold)
>         =====
>         A wants to put call on Hold
>           A(INVITE a=inactive)----------------->
>           B(200 ok a=inactive)<------------------
>
>
>
>
>         Best Regards,
>         Sakharam Thorat.
>
>
>         ------------------------------------------------------------------------
>         Date: Wed, 3 Jun 2015 22:11:06 +0530
>         From: m.dipan1987 at gmail.com <mailto:m.dipan1987 at gmail.com>
>         To: discussion at sipforum.org <mailto:discussion at sipforum.org>
>         Subject: [SIPForum-discussion] Call hold scenarios
>
>
>         Hi All,
>
>         Could anyone please explain in detail some real time examples
>         for call hold scenario for attribute like
>
>         a = sendonly  [ media is still sent]
>
>         a=inactive     [ no media is sent]
>
>
>
>         --
>
>
>
>
>         Regards,
>         Dipan Kumar
>         Sr.Software Engineer | HCL technologies
>
>
>
>
>
>         _______________________________________________ This is the SIP
>         Forum discussion mailing list TO UNSUBSCRIBE, or edit your
>         delivery options, please visit
>         http://sipforum.org/mailman/listinfo/discussion Post to the list
>         at discussion at sipforum.org <mailto:discussion at sipforum.org>
>
>         _______________________________________________
>         This is the SIP Forum discussion mailing list
>         TO UNSUBSCRIBE, or edit your delivery options, please visit
>         http://sipforum.org/mailman/listinfo/discussion
>         Post to the list at discussion at sipforum.org
>         <mailto:discussion at sipforum.org>
>
>
>
>
>     --
>     ---
>     Best Regards
>     Pravat Kumar Panda
>
>
>
>
> --
>
>
>
>
> Regards,
> Dipan Kumar
> Sr.Software Engineer
>
>
>
>