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

Chandra Prakash chandraprakash at virtualemployee.com
Tue Dec 3 10:47:11 CET 2013 

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
*************************************

More information about the Users mailing list