Thanks Jeff, And Sorry for the delayed response.
The endpoints are Bria. Network :- 5 Mbps leased line which is directly connected to the server. I tried to reconfigure the RTPproxy but in vain. Thanks -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: 26 November 2013 23:05 To: [email protected] Subject: Users Digest, Vol 64, Issue 70 Send Users mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://lists.opensips.org/cgi-bin/mailman/listinfo/users or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Users digest..." Today's Topics: 1. Delay with RTPproxy (Chandra Prakash) 2. DNS SRV failover not working for B2BUA (1.10) (Jeff Pyle) 3. Re: opensips sends CANCEL (Miha) 4. Re: Delay with RTPproxy (Jeff Pyle) 5. Re: DNS SRV failover not working for B2BUA (1.10) (Jeff Pyle) ---------------------------------------------------------------------- Message: 1 Date: Tue, 26 Nov 2013 19:46:51 +0530 From: "Chandra Prakash" <[email protected]> Subject: [OpenSIPS-Users] Delay with RTPproxy To: <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" Hi, I've configured opensip 1.8 with RTPproxy 1.2. All work fine except there is delay in RTP sessions. Is there any fix for this problem ? Pls help Thanks ------------------------------ Message: 2 Date: Tue, 26 Nov 2013 09:23:01 -0500 From: Jeff Pyle <[email protected]> Subject: [OpenSIPS-Users] DNS SRV failover not working for B2BUA (1.10) To: OpenSIPS users mailling list <[email protected]> Message-ID: <cacyjg3ld_usgp10wgqu4lfemmfh5mppvgwhkcizhqxn4wef...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hello, I have an SRV name as follows: $ dig +short -tSRV _sip._udp.proxyname.domain.com 1 10 5060 host1.domain.com. 2 10 5060 host2.domain.com. If I t_relay() a request with proxyname.domain.com as the request domain, and host1 does not answer within fr_timer seconds, the request is re-relayed to host2. This is good. If I b2b_init_request("top hiding") instead of t_relay(), the 408 is forwarded back towards the UAC after host1 doesn't answer. The request is never re-relayed to host2. There is a difference in the debug output after the 408 is generated for host1. With the B2BUA it looks like is_3263_failure() never happens. t_relay: Nov 26 09:03:38 [16296] DBG:tm:timer_routine: timer routine:0,tl=0x7fbe6c7c0060 next=(nil), timeout=61 Nov 26 09:03:38 [16296] DBG:tm:final_response_handler: Cancel sent out, sending 408 (0x7fbe6c7bfe10) Nov 26 09:03:38 [16296] DBG:tm:t_should_relay_response: T_code=100, new_code=408 Nov 26 09:03:38 [16296] DBG:tm:t_pick_branch: picked branch 0, code 408 (prio=800) Nov 26 09:03:38 [16296] DBG:tm:is_3263_failure: dns-failover test: branch=0, last_recv=408, flags=1 Nov 26 09:03:38 [16296] DBG:tm:t_should_relay_response: trying DNS-based failover Nov 26 09:03:38 [16296] DBG:tm:do_dns_failover: new destination available Nov 26 09:03:38 [16296] DBG:core:check_ip_address: params 127.0.0.1, 127.0.0.1, 0 Nov 26 09:03:38 [16296] DBG:tm:set_timer: relative timeout is 500000 b2b_init_request: Nov 26 09:12:21 [16401] DBG:tm:timer_routine: timer routine:0,tl=0x7f09ddcbf7e8 next=(nil), timeout=11 Nov 26 09:12:21 [16401] DBG:tm:final_response_handler: Cancel sent out, sending 408 (0x7f09ddcbf598) Nov 26 09:12:21 [16401] DBG:tm:t_should_relay_response: T_code=0, new_code=408 Nov 26 09:12:21 [16401] DBG:tm:t_pick_branch: picked branch 0, code 408 (prio=800) Nov 26 09:12:21 [16401] DBG:tm:local_reply: branch=0, save=0, winner=0 Nov 26 09:12:21 [16401] DBG:tm:local_reply: local transaction completed Nov 26 09:12:21 [16401] DBG:tm:run_trans_callbacks: trans=0x7f09ddcbf598, callback type 256, id 0 entered Nov 26 09:12:21 [16401] DBG:b2b_entities:b2b_tm_cback: tm [0x7f09ddcbf598] notification cb for [408] reply Nov 26 09:12:21 [16401] DBG:b2b_entities:b2b_parse_key: hash_index = [472] - local_index= [2611231] Nov 26 09:12:21 [16401] DBG:b2b_entities:b2b_tm_cback: Received reply [408] for dialog [0x7f09ddcbf2b8], method [INVITE] Is there something extra that must occur in the script to get DNS failover behavior with the B2BUA? Or, is this a bug? Regards, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.opensips.org/pipermail/users/attachments/20131126/28856aa9/att achment-0001.htm> ------------------------------ Message: 3 Date: Tue, 26 Nov 2013 15:22:25 +0100 From: Miha <[email protected]> Subject: Re: [OpenSIPS-Users] opensips sends CANCEL To: OpenSIPS users mailling list <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=windows-1252; format=flowed Please ignore this email as "CANCEL" was send due to dual forking. error messages are due to empty message;) br miha Dne 11/26/2013 10:09 AM, pi?e Miha: > Hi, > > could some take a look at this error and tell me what are they about? > > You can see from I trace that opensips sends cancel. > > Tnx! > > > > > Nov 26 10:04:04 sip2 /usr/sbin/opensips[13364]: > ERROR:auth:consume_credentials: no authorized credentials found (error > in scripts) > > > Nov 26 10:04:06 sip2 /usr/sbin/opensips[13358]: > INFO:core:parse_first_line: empty or bad first line Nov 26 10:04:06 > sip2 /usr/sbin/opensips[13358]: > INFO:core:parse_first_line: bad message Nov 26 10:04:06 sip2 > /usr/sbin/opensips[13358]: ERROR:core:parse_msg: > message=<> > Nov 26 10:04:06 sip2 /usr/sbin/opensips[13358]: > ERROR:core:receive_msg: parse_msg failed Nov 26 10:04:09 sip2 > /usr/sbin/opensips[13362]: > INFO:core:parse_first_line: empty or bad first line Nov 26 10:04:09 > sip2 /usr/sbin/opensips[13362]: > INFO:core:parse_first_line: bad message Nov 26 10:04:09 sip2 > /usr/sbin/opensips[13362]: ERROR:core:parse_msg: > message=<> > Nov 26 10:04:09 sip2 /usr/sbin/opensips[13362]: > ERROR:core:receive_msg: parse_msg failed > > > Nov 26 10:04:17 sip2 /usr/sbin/opensips[13358]: rc_avpair_new: unknown > attribute 0 Nov 26 10:04:17 sip2 /usr/sbin/opensips[13358]: > ERROR:aaa_radius:rad_avp_add: failure > Nov 26 10:04:17 sip2 /usr/sbin/opensips[13358]: > ERROR:acc:acc_aaa_cdrs: failed to add Sip-Response-Code, 2 Nov 26 > 10:04:17 sip2 /usr/sbin/opensips[13358]: > ERROR:acc:acc_dlg_callback: Cannot create radius accounting > > > 5.396017 PUBLIC_IP -> opensips_domain.com SIP/SDP Request: INVITE > sip:018108753@OPENSIPS_REGISTRATION_DOMAIN, with session description > 5.396254 opensips_domain.com -> PUBLIC_IP SIP Status: 407 Proxy > Authentication Required > 5.433576 PUBLIC_IP -> opensips_domain.com SIP Request: ACK > sip:018108753@OPENSIPS_REGISTRATION_DOMAIN > 5.454962 PUBLIC_IP -> opensips_domain.com SIP/SDP Request: INVITE > sip:018108753@OPENSIPS_REGISTRATION_DOMAIN, with session description > 5.458034 opensips_domain.com -> PUBLIC_IP SIP Status: 100 Giving a try > 5.458104 opensips_domain.com -> FS_IP SIP/SDP Request: INVITE > sip:38618108753@OPENSIPS_REGISTRATION_DOMAIN, with session description > 5.459878 FS_IP -> opensips_domain.com SIP Status: 100 Trying > 5.495447 FS_IP -> opensips_domain.com SIP/SDP Request: INVITE > sip:38618108753@opensips_domain.com:5060, with session description > 5.501095 opensips_domain.com -> FS_IP SIP Status: 100 Giving a try > 5.501164 opensips_domain.com -> PUBLIC_IP SIP/SDP Request: INVITE > sip:38618108753@PUBLIC_IP:12415, with session description > 5.501184 opensips_domain.com -> PUBLIC_IP SIP/SDP Request: INVITE > sip:38618108753@PUBLIC_IP:12839, with session description > 5.501199 opensips_domain.com -> PUBLIC_IP SIP/SDP Request: INVITE > sip:38618108753@PUBLIC_IP:12825, with session description > 5.508026 PUBLIC_IP -> opensips_domain.com ICMP Destination unreachable > (Port unreachable) > 5.517724 PUBLIC_IP -> opensips_domain.com SIP Status: 100 Trying > 5.531442 PUBLIC_IP -> opensips_domain.com SIP Status: 100 Trying > 5.563314 PUBLIC_IP -> opensips_domain.com SIP Status: 180 Ringing > 5.563426 opensips_domain.com -> FS_IP SIP Status: 180 Ringing > 5.577177 FS_IP -> opensips_domain.com SIP Status: 180 Ringing > 5.577295 opensips_domain.com -> PUBLIC_IP SIP Status: 180 Ringing > 5.670741 PUBLIC_IP -> opensips_domain.com SIP Status: 180 Ringing > 5.670840 opensips_domain.com -> FS_IP SIP Status: 180 Ringing > 5.999281 opensips_domain.com -> PUBLIC_IP SIP/SDP Request: INVITE > sip:38618108753@PUBLIC_IP:12825, with session description > 6.005052 PUBLIC_IP -> opensips_domain.com ICMP Destination unreachable > (Port unreachable) > 7.000772 opensips_domain.com -> PUBLIC_IP SIP/SDP Request: INVITE > sip:38618108753@PUBLIC_IP:12825, with session description > 7.005184 PUBLIC_IP -> opensips_domain.com ICMP Destination unreachable > (Port unreachable) > 7.044043 PUBLIC_IP -> opensips_domain.com SIP/SDP Status: 200 OK, with > session description > 7.044191 opensips_domain.com -> FS_IP SIP/SDP Status: 200 OK, with > session description > 7.044242 opensips_domain.com -> PUBLIC_IP SIP Request: CANCEL > sip:38618108753@PUBLIC_IP:12839 > 7.066863 FS_IP -> opensips_domain.com SIP/SDP Status: 200 OK, with > session description > 7.066981 opensips_domain.com -> PUBLIC_IP SIP/SDP Status: 200 OK, with > session description > 7.132422 PUBLIC_IP -> opensips_domain.com SIP Request: ACK > sip:018108753@FS_IP:5060;transport=udp > 7.132583 opensips_domain.com -> FS_IP SIP Request: ACK > sip:018108753@FS_IP:5060;transport=udp > 7.137809 PUBLIC_IP -> opensips_domain.com SIP Status: 200 OK > 7.143045 FS_IP -> opensips_domain.com SIP Request: ACK > sip:38618108753@PUBLIC_IP:12415 > 7.143185 opensips_domain.com -> PUBLIC_IP SIP Request: ACK > sip:38618108753@PUBLIC_IP:12415 > 7.163169 FS_IP -> opensips_domain.com SIP/SDP Request: UPDATE > sip:38618108753@PUBLIC_IP:12415, with session description > 7.163320 opensips_domain.com -> PUBLIC_IP SIP/SDP Request: UPDATE > sip:38618108753@PUBLIC_IP:12415, with session description > 7.174618 PUBLIC_IP -> opensips_domain.com SIP Status: 487 Request > Terminated > 7.174722 opensips_domain.com -> PUBLIC_IP SIP Request: ACK > sip:38618108753@PUBLIC_IP:12839 > 7.202234 PUBLIC_IP -> opensips_domain.com SIP/SDP Status: 200 OK, with > session description > 7.202322 opensips_domain.com -> FS_IP SIP/SDP Status: 200 OK, with > session description > 9.598791 PUBLIC_IP -> opensips_domain.com SIP Request: BYE > sip:mod_sofia@FS_IP:5080 > 9.599032 opensips_domain.com -> FS_IP SIP Request: BYE > sip:mod_sofia@FS_IP:5080 > 9.604072 FS_IP -> opensips_domain.com SIP Status: 200 OK > 9.604184 opensips_domain.com -> PUBLIC_IP SIP Status: 200 OK > 9.609102 FS_IP -> opensips_domain.com SIP Request: BYE > sip:38618108751@PUBLIC_IP:12824 > 9.609294 opensips_domain.com -> PUBLIC_IP SIP Request: BYE > sip:38618108751@PUBLIC_IP:12824 > 9.612840 PUBLIC_IP -> opensips_domain.com ICMP Destination unreachable > (Port unreachable) > 10.105298 opensips_domain.com -> PUBLIC_IP SIP Request: BYE > sip:38618108751@PUBLIC_IP:12824 > 10.108784 PUBLIC_IP -> opensips_domain.com ICMP Destination > unreachable (Port unreachable) > 10.609232 FS_IP -> opensips_domain.com SIP Request: BYE > sip:38618108751@PUBLIC_IP:12824 > 11.106821 opensips_domain.com -> PUBLIC_IP SIP Request: BYE > sip:38618108751@PUBLIC_IP:12824 > 11.110774 PUBLIC_IP -> opensips_domain.com ICMP Destination > unreachable (Port unreachable) > 11.307190 opensips_domain.com -> FS_IP SIP Request: INFO > sip:FS_IP:5060 > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ------------------------------ Message: 4 Date: Tue, 26 Nov 2013 10:17:23 -0500 From: Jeff Pyle <[email protected]> Subject: Re: [OpenSIPS-Users] Delay with RTPproxy To: OpenSIPS users mailling list <[email protected]> Message-ID: <cacyjg3kb1dnqk-u9azo7ntrg7kt1rnkqhhzecm19ywgqwwp...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Chandra, In my experience RTP delay is almost always the result of network latency or excessive jitter buffers on the endpoints. I doubt rtpproxy is the problem. What endpoints are you using? What is the network configuration? - Jeff On Tue, Nov 26, 2013 at 9:16 AM, Chandra Prakash < [email protected]> wrote: > > Hi, > > I've configured opensip 1.8 with RTPproxy 1.2. > > All work fine except there is delay in RTP sessions. Is there any fix > for this problem ? > > Pls help > > Thanks > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.opensips.org/pipermail/users/attachments/20131126/e2f11a7f/att achment-0001.htm> ------------------------------ Message: 5 Date: Tue, 26 Nov 2013 12:34:42 -0500 From: Jeff Pyle <[email protected]> Subject: Re: [OpenSIPS-Users] DNS SRV failover not working for B2BUA (1.10) To: OpenSIPS users mailling list <[email protected]> Message-ID: <cacyjg3k_+sxeeyc4styzbedbumjy4nkj1ejvfdds72dp_cw...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" I have same the SRV failover problem with uac_registrant-generated REGISTER requests. After little bit of digging it looks like there is no proxy structure associated with internally generated requests, and no DNS-based failover without it. Issue #140 <https://github.com/OpenSIPS/opensips/issues/140> logged. - Jeff On Tue, Nov 26, 2013 at 9:23 AM, Jeff Pyle <[email protected]> wrote: > Hello, > > I have an SRV name as follows: > > $ dig +short -tSRV _sip._udp.proxyname.domain.com > 1 10 5060 host1.domain.com. > 2 10 5060 host2.domain.com. > > If I t_relay() a request with proxyname.domain.com as the request > domain, and host1 does not answer within fr_timer seconds, the request > is re-relayed to host2. This is good. > > If I b2b_init_request("top hiding") instead of t_relay(), the 408 is > forwarded back towards the UAC after host1 doesn't answer. The > request is never re-relayed to host2. > > There is a difference in the debug output after the 408 is generated > for host1. With the B2BUA it looks like is_3263_failure() never happens. > > t_relay: > Nov 26 09:03:38 [16296] DBG:tm:timer_routine: timer > routine:0,tl=0x7fbe6c7c0060 next=(nil), timeout=61 Nov 26 09:03:38 > [16296] DBG:tm:final_response_handler: Cancel sent out, sending 408 > (0x7fbe6c7bfe10) Nov 26 09:03:38 [16296] > DBG:tm:t_should_relay_response: T_code=100, > new_code=408 > Nov 26 09:03:38 [16296] DBG:tm:t_pick_branch: picked branch 0, code > 408 > (prio=800) > Nov 26 09:03:38 [16296] DBG:tm:is_3263_failure: dns-failover test: > branch=0, last_recv=408, flags=1 > Nov 26 09:03:38 [16296] DBG:tm:t_should_relay_response: trying > DNS-based failover Nov 26 09:03:38 [16296] DBG:tm:do_dns_failover: new > destination available Nov 26 09:03:38 [16296] > DBG:core:check_ip_address: params 127.0.0.1, 127.0.0.1, 0 Nov 26 > 09:03:38 [16296] DBG:tm:set_timer: relative timeout is 500000 > > b2b_init_request: > Nov 26 09:12:21 [16401] DBG:tm:timer_routine: timer > routine:0,tl=0x7f09ddcbf7e8 next=(nil), timeout=11 Nov 26 09:12:21 > [16401] DBG:tm:final_response_handler: Cancel sent out, sending 408 > (0x7f09ddcbf598) Nov 26 09:12:21 [16401] > DBG:tm:t_should_relay_response: T_code=0, > new_code=408 > Nov 26 09:12:21 [16401] DBG:tm:t_pick_branch: picked branch 0, code > 408 > (prio=800) > Nov 26 09:12:21 [16401] DBG:tm:local_reply: branch=0, save=0, winner=0 > Nov 26 09:12:21 [16401] DBG:tm:local_reply: local transaction > completed Nov 26 09:12:21 [16401] DBG:tm:run_trans_callbacks: > trans=0x7f09ddcbf598, callback type 256, id 0 entered Nov 26 09:12:21 > [16401] DBG:b2b_entities:b2b_tm_cback: tm [0x7f09ddcbf598] > notification cb for [408] reply Nov 26 09:12:21 [16401] > DBG:b2b_entities:b2b_parse_key: hash_index = [472] > - local_index= [2611231] > Nov 26 09:12:21 [16401] DBG:b2b_entities:b2b_tm_cback: Received reply > [408] for dialog [0x7f09ddcbf2b8], method [INVITE] > > Is there something extra that must occur in the script to get DNS > failover behavior with the B2BUA? Or, is this a bug? > > > Regards, > Jeff > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.opensips.org/pipermail/users/attachments/20131126/e2d04642/att achment.htm> ------------------------------ _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users End of Users Digest, Vol 64, Issue 70 ************************************* _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
