[OpenSIPS-Users] Users Digest, Vol 64, Issue 70

Ali Pey alipey at gmail.com
Tue Dec 3 18:37:46 CET 2013 

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 <
chandraprakash at virtualemployee.com> 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: users-bounces at lists.opensips.org
> [mailto:users-bounces at lists.opensips.org] On Behalf Of
> users-request at lists.opensips.org
> Sent: 26 November 2013 23:05
> To: users at lists.opensips.org
> Subject: Users Digest, Vol 64, Issue 70
>
> Send Users mailing list submissions to
>         users at lists.opensips.org
>
> 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
>         users-request at lists.opensips.org
>
> You can reach the person managing the list at
>         users-owner at lists.opensips.org
>
> 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" <chandraprakash at virtualemployee.com>
> Subject: [OpenSIPS-Users] Delay with RTPproxy
> To: <users at lists.opensips.org>
> Message-ID: <000001ceeab2$29cc5ba0$7d6512e0$@virtualemployee.com>
> 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 <jpyle at fidelityvoice.com>
> Subject: [OpenSIPS-Users] DNS SRV failover not working for B2BUA
>         (1.10)
> To: OpenSIPS users mailling list <users at lists.opensips.org>
> Message-ID:
>         <
> CACYJG3Ld_usgP10WGQu4LfEMmfh5MPpVGwhKCiZHqXN4WeFdxQ at 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 <miha at softnet.si>
> Subject: Re: [OpenSIPS-Users] opensips sends CANCEL
> To: OpenSIPS users mailling list <users at lists.opensips.org>
> Message-ID: <5294AEA1.8040001 at softnet.si>
> 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 at 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 at OPENSIPS_REGISTRATION_DOMAIN
> > 5.454962 PUBLIC_IP -> opensips_domain.com SIP/SDP Request: INVITE
> > sip:018108753 at 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 at 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 at 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 at PUBLIC_IP:12415, with session description
> > 5.501184 opensips_domain.com -> PUBLIC_IP SIP/SDP Request: INVITE
> > sip:38618108753 at PUBLIC_IP:12839, with session description
> > 5.501199 opensips_domain.com -> PUBLIC_IP SIP/SDP Request: INVITE
> > sip:38618108753 at 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 at 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 at 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 at 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 at FS_IP:5060;transport=udp
> > 7.132583 opensips_domain.com -> FS_IP SIP Request: ACK
> > sip:018108753 at 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 at PUBLIC_IP:12415
> > 7.143185 opensips_domain.com -> PUBLIC_IP SIP Request: ACK
> > sip:38618108753 at PUBLIC_IP:12415
> > 7.163169 FS_IP -> opensips_domain.com SIP/SDP Request: UPDATE
> > sip:38618108753 at PUBLIC_IP:12415, with session description
> > 7.163320 opensips_domain.com -> PUBLIC_IP SIP/SDP Request: UPDATE
> > sip:38618108753 at 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 at 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 at FS_IP:5080
> > 9.599032 opensips_domain.com -> FS_IP SIP Request: BYE
> > sip:mod_sofia at 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 at PUBLIC_IP:12824
> > 9.609294 opensips_domain.com -> PUBLIC_IP SIP Request: BYE
> > sip:38618108751 at 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 at 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 at PUBLIC_IP:12824
> > 11.106821 opensips_domain.com -> PUBLIC_IP SIP Request: BYE
> > sip:38618108751 at 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
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 26 Nov 2013 10:17:23 -0500
> From: Jeff Pyle <jpyle at fidelityvoice.com>
> Subject: Re: [OpenSIPS-Users] Delay with RTPproxy
> To: OpenSIPS users mailling list <users at lists.opensips.org>
> Message-ID:
>         <
> CACYJG3Kb1DNQk-u9AZO7ntRg7Kt1rnkqhHZEcm19yWgqWwP8EQ at 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 <
> chandraprakash at virtualemployee.com> 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
> > Users at lists.opensips.org
> > 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 <jpyle at fidelityvoice.com>
> Subject: Re: [OpenSIPS-Users] DNS SRV failover not working for B2BUA
>         (1.10)
> To: OpenSIPS users mailling list <users at lists.opensips.org>
> Message-ID:
>         <
> CACYJG3K_+SXEeyc4STyzBEdBUmJY4nkj1EjvfdDS72dp_cw_Hw at 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 <jpyle at fidelityvoice.com>
> 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
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> End of Users Digest, Vol 64, Issue 70
> *************************************
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20131203/29e736d9/attachment-0001.htm>

More information about the Users mailing list