Mr. Gecko, thanks again for your response! After thinking about it some more, I can actually see a few (significant?) differences: a) pjsua_call_set_hold() and pjsua_call_reinvite() actually inform the remote caller about being on hold/re-invited b) on_call_media_state() is called with the respective status as a response/(confirmation?) of a) c) with "pjsua_conf_disconnect() and pjsua_conf_adjust_rx_level()" the call is not really "on-hold" but only connected to different media-ports... It dawns on me that "on-hold" (as produced by pjsua_call_set_hold()) is a well defined state that a particular call can have; this state then might even conceptually contradict the idea to play music to the caller while he experiences that state. --- Now, if this assumption is correct, music-on-hold (as in pjsua_call_set_hold()) cannot even be implemented, and a "work-around" implementation with pjsua_conf_disconnect() and pjsua_conf_adjust_rx_level() is the only way? - Maybe, someone can confirm this? Thanks & Cheers, Thomas On Jan 31, 2011, at 14:34 , Mr. Gecko wrote: > > On Jan 31, 2011, at 9:59 AM, Thomas Martin wrote: > >> Hello Mr. Gecko, >> >> first of all, thank you very much for your prompt response. >> >> I had the suspicion that something like that (https://github.com/GRMrGecko/VoiceMac/blob/master/Classes/VoiceBase/SIP/MGMSIPCall.m) needs to be done. - I was (and still am) not sure about the exact semantics of pjsua_call_set_hold(), though. >> >> The reference manual is not very verbose on this either. - Do you have any insight with respect to the semantics and overall effects of >> >> pjsua_call_set_hold() - respectively: pjsua_call_reinvite() >> >> versus: >> >> pjsua_conf_disconnect(0, conf_port); >> pjsua_conf_adjust_rx_level(conf_port, 0); >> >> respectively: >> >> pjsua_conf_connect(0, conf_port); >> pjsua_conf_adjust_rx_level(conf_port, previousValue); > For some reason pjsua_call_set_hold() doesn't work on every SIP provider, so I had to do it with muting anyway. > >> Also: 1) why do you mute the microphone instead of just disconnecting it as well? > Well, if you disconnect it, the music won't play as there is no connection (That is what I remembered. There might have also be the issue of the provider disconnecting me.). > >> 2) I noticed that you do not disconnect the player's conf-port to stop the music - you just pjsua_player_destroy() it. Is this sufficient ? > I never had any luck with disconnecting it as it ended up crashing the application, so I ended up just destroying it hoping it won't cause problems. > >> Thank you very much in advance for helping me learn a bit! >> >> Cheers, >> >> Thomas >> >> ps: (The typical scenario for all of this would be, where a second call (either incoming or outgoing) becomes involved and the currently active ("first") call shall be temporarily put on hold.) > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
