Please always respond on a proper thread with a proper subject line. No one can tell what you are talking about and to what thread you are responding when you reply to a Users Digest email.
Regards, Ali Pey On Tue, Dec 3, 2013 at 4:47 AM, Chandra Prakash < [email protected]> wrote: > 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 >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
