Re: Users Digest, Vol 64, Issue 70

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Users Digest, Vol 64, Issue 70

Chandra Prakash
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: [hidden email]
[mailto:[hidden email]] On Behalf Of
[hidden email]
Sent: 26 November 2013 23:05
To: [hidden email]
Subject: Users Digest, Vol 64, Issue 70

Send Users mailing list submissions to
        [hidden email]

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
        [hidden email]

You can reach the person managing the list at
        [hidden email]

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" <[hidden email]>
Subject: [OpenSIPS-Users] Delay with RTPproxy
To: <[hidden email]>
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 <[hidden email]>
Subject: [OpenSIPS-Users] DNS SRV failover not working for B2BUA
        (1.10)
To: OpenSIPS users mailling list <[hidden email]>
Message-ID:
        <[hidden email]>
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 <[hidden email]>
Subject: Re: [OpenSIPS-Users] opensips sends CANCEL
To: OpenSIPS users mailling list <[hidden email]>
Message-ID: <[hidden email]>
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:[hidden email]: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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>




------------------------------

Message: 4
Date: Tue, 26 Nov 2013 10:17:23 -0500
From: Jeff Pyle <[hidden email]>
Subject: Re: [OpenSIPS-Users] Delay with RTPproxy
To: OpenSIPS users mailling list <[hidden email]>
Message-ID:
        <[hidden email]>
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 <
[hidden email]> 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
> [hidden email]
> 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 <[hidden email]>
Subject: Re: [OpenSIPS-Users] DNS SRV failover not working for B2BUA
        (1.10)
To: OpenSIPS users mailling list <[hidden email]>
Message-ID:
        <[hidden email]>
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 <[hidden email]> 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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


End of Users Digest, Vol 64, Issue 70
*************************************


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Users Digest, Vol 64, Issue 70

Ali Pey
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 <[hidden email]> 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: [hidden email]
[mailto:[hidden email]] On Behalf Of
[hidden email]
Sent: 26 November 2013 23:05
To: [hidden email]
Subject: Users Digest, Vol 64, Issue 70

Send Users mailing list submissions to
        [hidden email]

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
        [hidden email]

You can reach the person managing the list at
        [hidden email]

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" <[hidden email]>
Subject: [OpenSIPS-Users] Delay with RTPproxy
To: <[hidden email]>
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 <[hidden email]>
Subject: [OpenSIPS-Users] DNS SRV failover not working for B2BUA
        (1.10)
To: OpenSIPS users mailling list <[hidden email]>
Message-ID:
        <[hidden email]>
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:
<<a href="http://lists.opensips.org/pipermail/users/attachments/20131126/28856aa9/att achment-0001.htm" target="_blank">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 <[hidden email]>
Subject: Re: [OpenSIPS-Users] opensips sends CANCEL
To: OpenSIPS users mailling list <[hidden email]>
Message-ID: <[hidden email]>
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@...: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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>




------------------------------

Message: 4
Date: Tue, 26 Nov 2013 10:17:23 -0500
From: Jeff Pyle <[hidden email]>
Subject: Re: [OpenSIPS-Users] Delay with RTPproxy
To: OpenSIPS users mailling list <[hidden email]>
Message-ID:
        <[hidden email]>
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 <
[hidden email]> 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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<<a href="http://lists.opensips.org/pipermail/users/attachments/20131126/e2f11a7f/att achment-0001.htm" target="_blank">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 <[hidden email]>
Subject: Re: [OpenSIPS-Users] DNS SRV failover not working for B2BUA
        (1.10)
To: OpenSIPS users mailling list <[hidden email]>
Message-ID:
        <[hidden email]>
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 <[hidden email]> 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:
<<a href="http://lists.opensips.org/pipermail/users/attachments/20131126/e2d04642/att achment.htm" target="_blank">http://lists.opensips.org/pipermail/users/attachments/20131126/e2d04642/att
achment.htm>

------------------------------

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


End of Users Digest, Vol 64, Issue 70
*************************************


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Users Digest, Vol 64, Issue 70

Ali Pey
In reply to this post by Chandra Prakash
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 <[hidden email]> 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: [hidden email]
[mailto:[hidden email]] On Behalf Of
[hidden email]
Sent: 26 November 2013 23:05
To: [hidden email]
Subject: Users Digest, Vol 64, Issue 70

Send Users mailing list submissions to
        [hidden email]

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
        [hidden email]

You can reach the person managing the list at
        [hidden email]

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)





_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users