[OpenSIPS-Users] RTP Delay when changing RTP Source port

Trevor Steyn trevor at webon.co.za
Thu Jul 23 11:31:20 CEST 2015


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-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] Namens Trevor Steyn
> Verzonden: woensdag 22 juli 2015 21:04
> Aan: users at 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-bounces at lists.opensips.org 
>> [mailto:users-bounces at lists.opensips.org] Namens Trevor Steyn
>> Verzonden: woensdag 22 juli 2015 9:52
>> Aan: users at 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 at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users




More information about the Users mailing list