[OpenSIPS-Users] Strange errors forwarding requests
E. Versaevel
erik at infopact.nl
Thu May 6 12:05:52 CEST 2010
Take your pick :)
opensipsctl fifo dlg_list | grep state | sort | uniq -c
1 state:: 1
4 state:: 2
14 state:: 3
78 state:: 4
5 state:: 5
I'll keep an eye on which state the stuck dialogs are in.
My routing logic uses loose route afaik:
if (has_totag()) {
if (loose_route()) {
if (is_method("INVITE")) {
record_route();
route(1);
} else {
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
t_relay();
exit;
} else {
exit;
}
}
if (is_method("CANCEL"))
{
if (t_check_trans())
t_relay();
exit;
}
sl_send_reply("404","Not here - seq no loose routing");
}
exit;
}
I could send you my complete config if that would help, but it's mostly the default config with some tweaks (to loadbalance calls to an asterisk
cluster and then send the calls from asterisk to the end users with a maximum number of concurrent calls (based on the available bandwidth on the
customers end))
Kind regards,
Erik
Op 6-5-2010 11:35, Bogdan-Andrei Iancu schreef:
> What is the state of the dialog stuck in memory? (use dlg_list MI
> command to see them).
>
> Also check that the sequential requests (ACK, re-INVITE, BYE) do go
> through your proxy (via loose_route).
>
> Regards,
> Bogdan
>
> Erik Versaevel - InfoPact Netwerkdiensten wrote:
>> That might be :)
>>
>> I'm now running into problems with the dialog module (which i use to
>> limit concurrent calls).
>> Calls seem to stick in the dialog module (thus denying additional
>> calls) while the endpoint isn't
>> listing the same amount of calls :/
>>
>> Regards,
>> Erik
>>
>>
>> Op 6-5-2010 11:02, Bogdan-Andrei Iancu schreef:
>>
>>> So, after all, it was a network layer configuration issue... :)
>>>
>>> Regards,
>>> Bogdan
>>>
>>> Erik Versaevel wrote:
>>>
>>>> The destination (in this case) is the 1st server in the loadbalancer
>>>> list (as there are no other calls).
>>>> I've upgraded this machine to ubuntu 10 (from 8) and started getting
>>>> Connection Tracking drop messages in my
>>>> syslog. I've disabled connection tracking and the issue hasn't
>>>> appeared since...
>>>>
>>>>
>>>> Op 5-5-2010 12:24, Bogdan-Andrei Iancu schreef:
>>>>
>>>>
>>>>> Hi Erik,
>>>>>
>>>>> have you tried to print the destination of the requests that fail?
>>>>>
>>>>> regards,
>>>>> Bogdan
>>>>>
>>>>> Erik Versaevel wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I attempted an migration last night (from our current environment to
>>>>>> this new setup) but i ran into this
>>>>>> problem as soon as i tried to make some test calls, funny thing is i
>>>>>> can't get it reproduced :/ Any clues
>>>>>> on how to debug this any further?
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>> Erik
>>>>>>
>>>>>> Op 27-4-2010 15:17, Erik Versaevel schreef:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I'm building a setup in which opensips is acting as registar for my
>>>>>>> endpoints and loadbalancing
>>>>>>> calls made by those endpoint over an cluster of asterisk machines.
>>>>>>> (so that if we need more asterisk
>>>>>>> power, we just have to add another destination to the loadbalancer
>>>>>>> module)
>>>>>>> Opensips is listening on multiple IP addresses and uses the
>>>>>>> loadbalancer module to poll my asterisk
>>>>>>> machines and select the destination.
>>>>>>> My problem is that every now and then opensips fails to forward an
>>>>>>> invite to my asterisk cluster and
>>>>>>> generates
>>>>>>>
>>>>>>> "ERROR:core:udp_send:
>>>>>>> sendto(sock,0x77b81280,1353,0,0x77b81b04,16): Operation not
>>>>>>> permitted(1)"
>>>>>>>
>>>>>>> there is some iptables filtering on this machine, however it is not
>>>>>>> showing drops in the logfile (and it keeps
>>>>>>> occuring even without any iptable rules).
>>>>>>> I tried stracing opensips but all i get is:
>>>>>>>
>>>>>>> opensipstrace.7423:sendto(6, "INVITE
>>>>>>> sip:E164_DST_PHONE_NR at OPENSIPS_IP_ADDRESS SIP/2.0
>>>>>>> Record-Route:
>>>>>>> <sip:OPENSIPS_IP_ADDRESS;lr=on;ftag=AI05ED431A05432EB8;nat=yes;did=fd6.e1f16fe3;vsf=AAAAAAMIBgl3AggLFgF5HAAFGhwBHzE3NC44MQ-->
>>>>>>>
>>>>>>>
>>>>>>> Via: SIP/2.0/UDP
>>>>>>> OPENSIPS_IP_ADDRESS;branch=z9hG4bK3177.1e0e38b7.0
>>>>>>> Via: SIP/2.0/UDP
>>>>>>> 192.168.178.44:5060;received=CPE_IP_ADDRESS;rport=61008;branch=z9hG4bK2010Apr222938466E164_DST_PHONE_NR
>>>>>>>
>>>>>>>
>>>>>>> To: <sip:E164_DST_PHONE_NR at OPENSIPS_IP_ADDRESS>
>>>>>>> From: \"3961\"
>>>>>>> <sip:3961 at OPENSIPS_IP_ADDRESS>;tag=AI05ED431A05432EB8
>>>>>>> Call-ID: AIF001C45E85F7921C at 192.168.178.44
>>>>>>> CSeq: 2 INVITE
>>>>>>> Max-Forwards: 69
>>>>>>> Contact:
>>>>>>> <sip:E164PHONE_NR at CPE_IP_ADDRESS:61008;line=AIF8F01E8DF866D7CB>
>>>>>>> Accept: application/sdp
>>>>>>> Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER
>>>>>>> Allow-Events: dialog,message-summary
>>>>>>> P-Preferred-Identity: <sip:E164PHONE_NR at OPENSIPS_IP_ADDRESS>
>>>>>>> Privacy: none
>>>>>>> User-Agent: SomeStrangeDude
>>>>>>> Content-Type: application/sdp
>>>>>>> Content-Length: 324
>>>>>>> I-FromDisp: <null>
>>>>>>> I-FromUri: E164PHONE_NR
>>>>>>> I-CustId: 3961
>>>>>>> v=0
>>>>>>> o=intelligate 1133701155 1133701155 IN IP4 192.168.178.44
>>>>>>> s=call
>>>>>>> c=IN IP4 CPE_IP_ADDRESS
>>>>>>> t=0 0
>>>>>>> m=audio 5004 RTP/AVP 18 8 101
>>>>>>> a=rtpmap:18 G729/8000
>>>>>>> a=fmtp:18 annexb=no
>>>>>>> a=rtpmap:8 PCMA/8000
>>>>>>> a=rtpmap:101 telephone-event/8000
>>>>>>> a=fmtp:101 0-15
>>>>>>> a=sendrecv
>>>>>>> a=ptime:20
>>>>>>> a=direction:active
>>>>>>> a=oldmediaip:192.168.178.44
>>>>>>> ", 1253, 0, {sa_family=AF_INET, sin_port=htons(5060),
>>>>>>> sin_addr=inet_addr("ASTERISK_IP_ADDRESS")}, 16) = -1 EPERM
>>>>>>> (Operation not permitted)
>>>>>>>
>>>>>>> I also use the uac_replace_from() to mangle the from header so
>>>>>>> asterisk uses the correct user/peer/client to connect the call
>>>>>>> (codec/dialplan etc).
>>>>>>> I'm having trouble reproducing the error as it's not allways
>>>>>>> occuring, the errors i straced where mainly the initial invite
>>>>>>> towards my asterisk
>>>>>>> cluster and a few 200 OK's which didn't get processed correctly.
>>>>>>>
>>>>>>> Any clues on how to debug this further?
>>>>>>>
>>>>>>> Kind regards,
>>>>>>>
>>>>>>> Erik Versaevel
>>>>>>>
>>>>>>>
>>>>>>>
Erik Versaevel
More information about the Users
mailing list