Hi Hakan, Since I can't access the Cisco server from here, can you forward us the log (level 5, as text attachment)? Based on your description, since app needs to overwrite callback on_call_tx_offer(), does it mean that the remote is sending re-INVITE without SDP when trying to unhold? Regards, Ming On Mon, Sep 24, 2018 at 9:03 PM Håkan Berg <hakan.berg@xxxxxxxx> wrote: > > Hi, > I believe I've found a problem in pjsua: When registered to a cisco unified call manager pbx (10.5 in my case) and calling to a video phone endpoint on that pbx, the video negotiation in pjsip fails if the endpoint phone puts pjsip on hold and then unhold again. > The SDP sent from pjsip seems to be missing vital video lines: > m=video 0 RTP/AVP 31 > c=IN IP4 127.0.0.1 > a=sendrecv > > Whereas a working video SDP might include something like this: > m=video 4006 RTP/AVP 97 > c=IN IP4 10.0.0.5 > b=TIAS:768000 > a=rtcp:4007 IN IP4 10.0.0.5 > a=sendrecv > a=rtpmap:97 H264/90000 > a=fmtp:97 profile-level-id=42000d > > I can reproduce it with pjsua-bin like so: > > git clone https://github.com/cisco/openh264.git > cd openh264 > make > sudo make install > cd .. > wget http://pjsip.org/release/2.8/pjproject-2.8.tar.bz2 > tar xvfj pjproject-2.8.tar.bz2 > cd pjproject-2.8 > ./configure > echo "#define PJMEDIA_HAS_VIDEO 1" >> pjlib/include/pj/config_site.h > make dep && make > cd pjsip-apps/bin > ./pjsua-x86_64-unknown-linux-gnu --playback-dev=1 --capture-dev=1 --id sip:1@10.0.0.1 --registrar sip:10.0.0.1 --realm "*" --username 1 --password hunter2 --app-log-level=3 --video > > press m, enter sip:2@10.0.0.1 > Cisco phone on extension 2 rings, answer and press hold. Video goes to inactive, press hold button again to unhold call, video ends up still being inactive because of SDP negotiation problem. > I can work around the problem by registering a callback function, but that should not be needed in my opinion: > > diff --git a/pjsip-apps/src/pjsua/pjsua_app.c.bak b/pjsip-apps/src/pjsua/pjsua_app.c > index 51c4537..db6066a 100644 > --- a/pjsip-apps/src/pjsua/pjsua_app.c.bak > +++ b/pjsip-apps/src/pjsua/pjsua_app.c > @@ -1226,6 +1226,12 @@ int stdout_refresh_proc(void *arg) > return 0; > } > > +static void > +ON_CALL_TX_OFFER_WORKAROUND(pjsua_call_id call_id, void *reserved, > + pjsua_call_setting *opt) > +{ > +} > + > static pj_status_t app_init() > { > pjsua_transport_id transport_id = -1; > @@ -1275,6 +1281,9 @@ static pj_status_t app_init() > app_config.cfg.cb.on_nat_detect = &on_nat_detect; > app_config.cfg.cb.on_mwi_info = &on_mwi_info; > app_config.cfg.cb.on_transport_state = &on_transport_state; > + > + app_config.cfg.cb.on_call_tx_offer = &ON_CALL_TX_OFFER_WORKAROUND; > + > app_config.cfg.cb.on_ice_transport_error = &on_ice_transport_error; > app_config.cfg.cb.on_snd_dev_operation = &on_snd_dev_operation; > app_config.cfg.cb.on_call_media_event = &on_call_media_event; > > > > This seems to be a problem because of the late offer mechanism that cisco uses, and pjsua-lib only "re-initialize media before creating SDP" if there's a on_call_tx_offer callback set (or call->med_prov_cnt is 0), see pjsua_call_on_create_offer(). > This limitation does not seem to exist for things like pjsua_call_set_hold2(). But that's why the workaround gives a successful SDP negotiation: apply_call_setting() gets called. > Let me know if you need any pcap dumps demonstrating the problem. > > Please advise. > Br, > /Håkan > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@xxxxxxxxxxxxxxx > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org _______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip@xxxxxxxxxxxxxxx http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
