HI Rik, I removed the all flags and it worked i got audio straight away i then re-added flags one by one to find the culprit seems the re-packetization was the issue when i add "z20" there is that delay in audio,
The debugs dont show much see below The issue is i really need RTP going to UAS to be at 20ms payload due to a vendor restriction, at least know i know where to look at i will dig into the re-packetization flag to see if i can learn more on why it would do this if you have any ideas please let me know. DBUG:get_command: received command "16653_6 UIEZ20c18,4,8,100,118 SDurfbb02-1ceee8fa17f07cf66cdcc9b4c851f49c-ctvvfv3 UAC_IP 53266 SDurfbb02-55B0B333-1D600C7-0ADE2C1B;1" INFO:handle_command: new session SDurfbb02-1ceee8fa17f07cf66cdcc9b4c851f49c-ctvvfv3, tag SDurfbb02-55B0B333-1D600C7-0ADE2C1B;1 requested, type strong INFO:handle_command: new session on a port 57596 created, tag SDurfbb02-55B0B333-1D600C7-0ADE2C1B;1 INFO:handle_command: pre-filling caller's address with 10.10.16.34:53266 INFO:handle_command: RTP packets from caller will be resized to 20 milliseconds DBUG:doreply: sending reply "16653_6 57596 EXT_IP " DBUG:get_command: received command "16663_8 LEIZ20c18 SDurfbb02-1ceee8fa17f07cf66cdcc9b4c851f49c-ctvvfv3 UAS_IP 54274 SDurfbb02-55B0B333-1D600C7-0ADE2C1B;1 g56jcvtppqn2wxef.i;1" INFO:handle_command: lookup on ports 57596/33858, session timer restarted INFO:handle_command: pre-filling callee's address with 196.2.126.52:54274 INFO:handle_command: RTP packets from callee will be resized to 20 milliseconds DBUG:doreply: sending reply "16663_8 33858 INT_IP " DBUG:get_command: received command "16660_5 LEIZ20c18,100 SDurfbb02-1ceee8fa17f07cf66cdcc9b4c851f49c-ctvvfv3 UAS_IP 53680 SDurfbb02-55B0B333-1D600C7-0ADE2C1B;1 g56jcvtppqn2wxef.i;1" INFO:handle_command: lookup on ports 57596/33858, session timer restarted INFO:handle_command: pre-filling callee's address with 196.2.126.52:53680 INFO:handle_command: RTP packets from callee will be resized to 20 milliseconds DBUG:doreply: sending reply "16660_5 33858 INT_IP " DBUG:get_command: received command "16663_9 LEIZ20c18,8,100 SDurfbb02-1ceee8fa17f07cf66cdcc9b4c851f49c-ctvvfv3 UAS_IP 36606 SDurfbb02-55B0B333-1D600C7-0ADE2C1B;1 g56jcvtppqn2wxef.i;1" INFO:handle_command: lookup on ports 57596/33858, session timer restarted INFO:handle_command: pre-filling callee's address with 196.2.126.52:36606 INFO:handle_command: RTP packets from callee will be resized to 20 milliseconds DBUG:doreply: sending reply "16663_9 33858 INT_IP " DBUG:get_command: received command "16658_5 D SDurfbb02-1ceee8fa17f07cf66cdcc9b4c851f49c-ctvvfv3 SDurfbb02-55B0B333-1D600C7-0ADE2C1B g56jcvtppqn2wxef.i" INFO:handle_delete: forcefully deleting session 1 on ports 57596/33858 INFO:remove_session: RTP stats: 991 in from callee, 388 in from caller, 1781 relayed, 0 dropped INFO:remove_session: RTCP stats: 2 in from callee, 5 in from caller, 7 relayed, 0 dropped INFO:remove_session: session on ports 57596/33858 is cleaned up DBUG:doreply: sending reply "16658_5 0 Regards Trevor Steyn On 23/07/2015 10:28, Rik Broers wrote: > Try it with only the ie flags, wz20 only adds more complexity in > troubleshooting. > What do the rtpproxy logs tell you? > > > -----Oorspronkelijk bericht----- > Van: users-boun...@lists.opensips.org > [mailto:users-boun...@lists.opensips.org] Namens Trevor Steyn > Verzonden: woensdag 22 juli 2015 21:04 > Aan: users@lists.opensips.org > Onderwerp: Re: [OpenSIPS-Users] RTP Delay when changing RTP Source port > > Hi Rik > > I have tried using rtpproxy_offer/answer functions with the same results, > > if (has_body("application/sdp")) { > if (rtpproxy_offer('iewz20')) { > t_on_reply("1"); > } else { > t_on_reply("2"); > } > } > > t_on_failure("GW_FAILOVER"); > route(RELAY); > } > > onreply_route[1] > { > if (has_body("application/sdp")) > rtpproxy_answer('eiwz20'); > } > > onreply_route[2] > { > if (has_body("application/sdp")) > rtpproxy_offer('iewz20'); > } > > below you can see that Signalling and RTP flows. > > You will see rtpproxy only starts relaying packets ~10seconds later after the > 200OK even though Callee is sending RTP > > http://salamander.iburst.co.za:8000/personal/signalling.txt > > Seems the issue here is when RTP stream is already established (183 with > SDP) and the 200OK comes along with different source port it takes some time > before RTP proxy relays the packets to caller. > > Regards > Trevor > > On 22/07/2015 13:30, Rik Broers wrote: >> I think rtpproxy_engage doesnt work correct with the fact that you bridge >> internal to external. Also says in docs: >> "... Note that when used in bridge mode, this function might advertise wrong >> interfaces in SDP (due to the fact that OpenSIPS is not aware of the >> RTPProxy configuration), so you might face an undefined behavior." >> >> You could try and use the rtpproxy_offer and answer functions. put in the >> reply route an if (has_body("application/sdp")) to also catch the 183 with >> sdp .The docs have examples on how to use them and how to trigger on reply >> routes. >> >> Regards, >> Rik >> >> -----Oorspronkelijk bericht----- >> Van: users-boun...@lists.opensips.org >> [mailto:users-boun...@lists.opensips.org] Namens Trevor Steyn >> Verzonden: woensdag 22 juli 2015 9:52 >> Aan: users@lists.opensips.org >> Onderwerp: [OpenSIPS-Users] RTP Delay when changing RTP Source port >> >> Hi, All >> >> Still quite new to opensips I have the following configuration running >> on >> >> version: opensips 2.1.0 (x86_64/linux) >> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, >> FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE >> 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method >> support: poll, epoll_lt, epoll_et, sigio_rt, select. >> main.c compiled on 06:22:03 May 8 2015 with gcc 4.4.7 >> >> >> (Topology Hiding) >> UAC -------> Opensips(Internal) Opensips(External) ----> UAS >> (RTP PROXY BRIDGE) >> >> >> >> what i am experiencing is the following call is setup between UAC and UAS >> through opensips UAS sets up RTP with a 183 Session Progress message with >> SDP Shortly after we get a 180 ringing (i understand this is not correct but >> cannot be changed), When a 200OK is eventually sent the Source Port is >> different to what was in the SDP on the 183 message. >> >> Media starts flowing from UAS to opensips External from the new source port >> but for the first 7 seconds or so opensips/rtpproxy does not pass on this >> media to UAC from Internal. >> >> I run rtp proxy as follows >> >> rtpproxy -l <Internal IP>/<External IP> -s udp:127.0.0.1:12221 -m >> 25000 -M 65000 -F -d DBUG:LOCAL1 >> >> route{ >> #script_trace( 3, "$rm from $si, ruri=$ru", "me"); >> >> if (!mf_process_maxfwd_header("10")) { >> sl_send_reply("483","Too Many Hops"); >> exit; >> } >> >> if ( check_source_address("1","$avp(trunk_attrs)") ) { >> # request comes from trunks >> setflag(IS_TRUNK); >> } else if ( is_from_gw() ) { >> # request comes from GWs >> } else { >> send_reply("403","Forbidden"); >> exit; >> } >> >> if (has_totag()) { >> # sequential request withing a dialog should >> # take the path determined by record-routing >> if(topology_hiding_match()) { >> # validate the sequential request against dialog >> if ( $DLG_status!=NULL && !validate_dialog() ) { >> xlog("In-Dialog $rm from $si (callid=$ci) is not valid >> according to dialog\n"); >> ## exit; >> } >> >> if (is_method("BYE")) { >> setflag(ACC_DO); # do accounting ... >> setflag(ACC_FAILED); # ... even if the transaction fails >> } else if (is_method("INVITE")) { >> # even if in most of the cases is useless, do RR for >> # re-INVITEs alos, as some buggy clients do change route set >> # during the dialog. >> record_route(); >> } >> route(RELAY); >> } else { >> if ( is_method("ACK") ) { >> if ( t_check_trans() ) { >> # non loose-route, but stateful ACK; must be an ACK after >> # a 487 or e.g. 404 from upstream server >> t_relay(); >> exit; >> } else { >> # ACK without matching transaction -> >> # ignore and discard >> exit; >> } >> } >> sl_send_reply("404","Not here"); >> } >> exit; >> } >> >> #### INITIAL REQUESTS >> >> if ( !isflagset(IS_TRUNK) ) { >> ## accept new calls only from trunks >> send_reply("403","Not from trunk"); >> exit; >> } >> >> # CANCEL processing >> if (is_method("CANCEL")) { >> if (t_check_trans()) >> t_relay(); >> exit; >> } else if (!is_method("INVITE")) { >> send_reply("405","Method Not Allowed"); >> exit; >> } >> >> if ($rU==NULL) { >> # request with no Username in RURI >> sl_send_reply("484","Address Incomplete"); >> exit; >> } >> >> t_check_trans(); >> >> # preloaded route checking >> if (loose_route()) { >> xlog("L_ERR", >> "Attempt to route with preloaded Route's [$fu/$tu/$ru/$ci]"); >> if (!is_method("ACK")) >> sl_send_reply("403","Preload Route denied"); >> exit; >> } >> >> # record routing >> record_route(); >> >> setflag(ACC_DO); # do accounting >> >> >> # create dialog with timeout >> if ( !create_dialog("B") ) { >> send_reply("500","Internal Server Error"); >> exit; >> } >> >> >> dp_translate("1","$rU/$rU"); >> >> # route calls based on prefix >> if ( !do_routing("1",,,,"$var(gw_attributes)") ) { >> send_reply("404","No Route found"); >> exit; >> } >> if (is_method("INVITE")) { >> force_send_socket(udp:<EXternal IP:5060); >> rtpproxy_engage('ierz20'); >> #rtpproxy_engage(); >> topology_hiding(); >> } >> >> >> t_on_failure("GW_FAILOVER"); >> route(RELAY); >> } >> >> >> route[RELAY] { >> if (!t_relay()) { >> sl_reply_error(); >> }; >> exit; >> } >> >> >> failure_route[GW_FAILOVER] { >> if (t_was_cancelled()) { >> exit; >> } >> >> # detect failure and redirect to next available GW >> if (t_check_status("(408)|([56][0-9][0-9])")) { >> xlog("Failed GW $rd detected \n"); >> >> if ( use_next_gw() ) { >> t_on_failure("GW_FAILOVER"); >> t_relay(); >> exit; >> } >> >> send_reply("500","All GW are down"); >> } >> } >> >> >> local_route { >> if (is_method("BYE") && $DLG_dir=="UPSTREAM") { >> >> acc_log_request("200 Dialog Timeout"); >> >> } >> } >> >> >> Below you can see the call flow >> >> http://salamander.iburst.co.za:8000/personal/signalling.txt >> >> I have tried a most of the options on rtpproxy_engage with no luck >> >> Regards >> Trevor Steyn >> >> >> _______________________________________________ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
