Bernd

Hi! 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. Bernd -- mobile: +43 664 4416156 http://www.sysprog.at/ Linux Software Development, Consulting and Services

Bernd

On 10/23/2012 10:59 AM, Bernd Petrovitsch wrote: > Hi! > > 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. > > Bernd > 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? -- Mit freundlichen Grüßen / Best regards Andreas Wehrmann CENTER COMMUNICATION SYSTEMS GMBH Ein Unternehmen der STRABAG SE Software Development Ignaz-Köck-Str. 19 A-1210 Wien, Österreich Tel.: +43 (0) 190 199 - 3616 Fax: +43 (0) 190 199 - 2110 Mobil: +43 (0) 664 884 75916 a.wehrmann@centersystems.com FN 796 88p, Sitz in Wien Firmenbuchgericht Wien <http://www.centersystems.com/> www.centersystems.com Geschäftsführung: Ing. Gerhard Jelinek, Josef-Eduard Burger

Bernd

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@petrovitsch.priv.at LUGA : http://www.luga.at -- mobile: +43 664 4416156 http://www.sysprog.at/ Linux Software Development, Consulting and Services

Hi! Just to follow up for the archives: On Fre, 2012-11-23 at 12:41 +0100, Bernd Petrovitsch wrote: [...] > On Die, 2012-10-23 at 11:05 +0200, Andreas Wehrmann wrote: > > On 10/23/2012 10:59 AM, Bernd Petrovitsch wrote: [..] > 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()? If I understand the RFCs correctly, that's actually the only way to go. However, also working is: - do not answer the call initially in any way. pjsua-lib itself sends an answer with 100 anyways. We just copy the remote SDP away. - if we have the correct address+port, we finish the negotiation pjmedia_sdp_neg_negotiate() with the current call. We then completely redo the SDP negotiation with pjmedia_sdp_neg_create_w_remote_offer() within the current call (using pjsua-internal.h header) to get the negotiator into the same state as before. Finally answer the call. No need to change anything in pjsip's source code. Kind regards, Bernd -- mobile: +43 664 4416156 http://www.sysprog.at/ Linux Software Development, Consulting and Services