Hi! On Die, 2012-10-23 at 11:05 +0200, Andreas Wehrmann wrote: > On 10/23/2012 10:59 AM, Bernd Petrovitsch wrote: [..] > > I'm working on a SIP-Client which handles account registration etc. > > against a SIP-Server but the voice streams run elsewhere. > > > > What do we do now? > > We get the information about IP address and ports from the voice side > > and rewrite the SDP in PjSUAs "on_call_sdp_created" callback. > > > > This works as long as we get the IP address and ports before we get the > > SIP-INVITE. > > > > The problem is now: What do we do if the SIP-INVITE comes before the > > voice information? > > Well, we could answer the call with "RINGING" (or not at all), but the > > SDP has been created already without knowing the data and the > > "on_call_sdp_created" callback is not called later on. > > > > Are we allowed to just rewrite it - the dirty way - via the data > > structures? > > I failed to find a useful API function to rewrite/regenerate the SDP, > > change media parameters or similar. > > > > Any hints or suggestions? > > > > FWIW, we use pjsip-2.0.1. [...] > Just a quick shot here, but how about initially answering with audio > a=recvonly and after receiving the information sending a re-invite with > the new SDP and audio a=sendrevc? Well, we normally have only "recvonly". So I tried to pjsua_call_reinvite(.., PJSUA_CALL_INCLUDE_DISABLED_MEDIA, NULL); but it fails with "Cannot re-INVITE call that is not confirmed". Hmm, is this because we are only RINGING at that time? With pjsua_call_update(_call_id, PJSUA_CALL_INCLUDE_DISABLED_MEDIA, NULL); I get "Unable to create UPDATE request: Invalid operation (PJ_EINVALIDOP)". Again, we are RINGING at the time. Hmm, accepting the call (setting all media to "inactive") doesn't seem useful though. On Die, 2012-10-23 at 09:25 +0000, JOHAN LANTZ wrote: > It might be an idea to use re-invite or update as already suggested. > Another thing to look at is the media transport adapter. > http://trac.pjsip.org/repos/wiki/Media_Transport_Adapter Thanks, that is actually the reason to use 2.0.1. Using/implementing a media transport adapter does not really help. Looking into pjsip's source confirms this IMHO: in the function pjsua_media_channel_create_sdp() in .../src/pjsua-lib/pjsua_media.c are both calls to encode_sdp() callback function of struct pjmedia_transport_op and the on_call_sdp_created callback of struct pjsua_callback. What is actually the way to go with a media transport adapter if there is a change in the media streams which must be announced via a new SDP? Should the MTA call pjsua_call_reinvite() or pjsua_call_update()? Bernd -- Bernd Petrovitsch Email : bernd at petrovitsch.priv.at LUGA : http://www.luga.at -- mobile: +43 664 4416156 http://www.sysprog.at/ Linux Software Development, Consulting and Services
