[OpenSIPS-Users] Mediaproxy 2.1.0: dispatcher - relay problems
Having some troubles getting Mediaproxy 2.1.0 working. I'm on a VPS with a fresh Debian Etch, running OpenSips 1.4.3 (which log below is for, also tried Kamailio 1.4.1 earlier [separate debian installation], log was pretty much identical). The log is from a 'tail -f /var/log/syslog | grep media' when making a call from a sip ua over a sip trunk via pstn gw to a cell phone. The same setup works well if engage_media_proxy is removed, except for CANCEL:s where the 487 is never sent (and it thus keeps ringing). I'm all out of ideas of what to test next and could really need a pointer to where the fault could be. Is it my config or some software dependencies missing / being faulty? I'm sorry for the long email, but I wanted to get as much info as I could in here. The routing, unless I'm missing something, goes through down to REGISTER-clause, hops to route[3], hops to route[10], hops to route[4] which rewrites it to the sip trunk and hops to route[1]. All IP:s are public. Many thanks to anyone willing to have a quick look; all suggestions are much welcomed! Best Regards, Magnus --- syslog --- Dec 9 01:28:24 ada-bcn-sips001 media-dispatcher[14252]: [-] Log opened. Dec 9 01:28:24 ada-bcn-sips001 media-dispatcher[14252]: [-] Starting MediaProxy Dispatcher 2.1.0 Dec 9 01:28:24 ada-bcn-sips001 media-dispatcher[14252]: [-] Twisted is using epollreactor Dec 9 01:28:24 ada-bcn-sips001 media-dispatcher[14252]: [-] mediaproxy.dispatcher.RelayFactory starting on 25060 Dec 9 01:28:24 ada-bcn-sips001 media-dispatcher[14252]: [-] mediaproxy.dispatcher.OpenSIPSControlFactory starting on "'/var/run/mediaproxy/dispatcher.sock'" Dec 9 01:28:24 ada-bcn-sips001 media-dispatcher[14252]: [-] mediaproxy.dispatcher.ManagementControlFactory starting on 25061 Dec 9 01:28:30 ada-bcn-sips001 media-relay[14266]: [-] Log opened. Dec 9 01:28:30 ada-bcn-sips001 media-relay[14266]: [-] Starting MediaProxy Relay 2.1.0 Dec 9 01:28:30 ada-bcn-sips001 media-relay[14266]: [-] Set resource limit for maximum open file descriptors to 11000 Dec 9 01:28:30 ada-bcn-sips001 media-relay[14266]: [-] Adding new dispatcher at :25060 Dec 9 01:28:30 ada-bcn-sips001 media-dispatcher[14252]: [mediaproxy.dispatcher.RelayFactory] Connection from relay at Dec 9 01:28:30 ada-bcn-sips001 media-dispatcher[14252]: [RelayServerProtocol,0,] Issuing "sessions" command to relay at Dec 9 01:28:31 ada-bcn-sips001 media-relay[14266]: [Uninitialized] Connected to dispatcher at :25060 ... Dec 9 01:01:28 host001 media-dispatcher[2466]: [OpenSIPSControlProtocol,33,] Issuing "update" command to relay at Dec 9 01:01:28 host001 media-relay[2492]: [RelayClientProtocol,client] Received new SDP offer Dec 9 01:01:28 host001 media-relay[2492]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 50004 Dec 9 01:01:28 host001 media-relay[2492]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 50005 Dec 9 01:01:28 host001 media-relay[2492]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 50006 Dec 9 01:01:28 host001 media-relay[2492]: [RelayClientProtocol,client] mediaproxy.mediacontrol.StreamListenerProtocol starting on 50007 Dec 9 01:01:28 host001 media-relay[2492]: [RelayClientProtocol,client] Added new stream: (audio) :1 (RTP: Unknown, RTCP: Unknown) <-> :50004 <-> :50006 <-> Unknown (RTP: Unknown, RTCP: Unknown) Dec 9 01:01:28 host001 media-relay[2492]: [RelayClientProtocol,client] created new session 6C8F-F261-420242003-D5889592E170-0007@: @ (XG6525p2-186fd447-658964802) --> @ Dec 9 01:01:28 host001 media-relay[2492]: [mediaproxy.mediacontrol.StreamListenerProtocol (UDP)] Got traffic information for stream: (audio) :1 (RTP: Unknown, RTCP: Unknown) <-> :50004 <-> :50006 <-> Unknown (RTP: Unknown, RTCP: :21189) Dec 9 01:01:28 host001 media-relay[2492]: [mediaproxy.mediacontrol.StreamListenerProtocol (UDP)] Got traffic information for stream: (audio) :1 (RTP: Unknown, RTCP: Unknown) <-> :50004 <-> :50006 <-> Unknown (RTP: :21188, RTCP: :21189) Dec 9 01:01:30 host001 media-dispatcher[2466]: [OpenSIPSControlProtocol,46,] Issuing "update" command to relay at Dec 9 01:01:30 host001 media-relay[2492]: [RelayClientProtocol,client] error: Required header "from_tag" for command "update" not found Dec 9 01:01:32 host001 /usr/local/sbin/opensips[10729]: ERROR:mediaproxy:send_command: did timeout waiting for an answer Dec 9 01:01:32 host001 media-dispatcher[2466]: [OpenSIPSControlProtocol,46,] Connection to OpenSIPS lost: Connection was closed cleanly. Dec 9 01:01:32 host001 media-relay[2492]: [mediaproxy.mediacontrol.StreamListenerProtocol (UDP)] Got traffic information for stream: (audio) :1 (RTP: Unknown, RTCP: :10001) <-> :50004 <-> :50006 <-> Unknown (RTP: :21188, RTCP: :21189) Dec 9 01:01:35 host001 media-dispatcher[2466]: [-] error: Error processing request: Relay at tim
Re: [OpenSIPS-Users] Mediaproxy 2.1.0: dispatcher - relay problems
Found the error... my modification of the from-header must be faulty,
cut out the if-clause below and everything works!
Note to self, get some sleep before asking stupid questions... ;)
Best Regards,
Magnus
Magnus Burman wrote:
> Having some troubles getting Mediaproxy 2.1.0 working. I'm on a VPS
> with a fresh Debian Etch, running OpenSips 1.4.3 (which log below is
> for, also tried Kamailio 1.4.1 earlier [separate debian installation],
> log was pretty much identical).
>
> Best Regards,
> Magnus
>
> --- syslog ---
> Dec 9 01:01:30 host001 media-relay[2492]:
> [RelayClientProtocol,client] error: Required header "from_tag" for
> command "update" not found
> route[1] {
>## Forward statefully
># Find users caller-id
>if(avp_db_query("select call_id from subscriber_extras where
> username = '$fU'", "$avp(s:cid)")) {
>remove_hf("From");
>append_hf("From: >\r\n", "To");
>}
>setflag(1);
>if (!t_relay()) {
>sl_reply_error();
>};
>exit;
> }
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Mediaproxy 2.1.0: dispatcher - relay problems
Glad my groggy brain could help. ;)
I did remove the from_tag, but inserted a new one. Reason for this was
to get caller id to work. Been trying all kinds of PAI och
Remote-Party-ID now, but nothing works. They tell me the E.164-number
must be the user-part of the uri, ie sip:123456...@domain.
In my route I rewrite the from_tag as late as possible, right before the
t_relay(). Would mediaproxy be happier if I did this some other place,
say at the very beginning of the routes?
It also boggles me that it says that "from_tag" not found... because
it's clearly present. Would it say the same if it didn't understand the
from_tag? If I remove mediaproxy (which I for my life don't want to do,
much love your way for this product!), my calls are setup fine,
caller-id is working and the rtp-data is sent correctly. So with my
limited knowledge I don't understand why mediaproxy would object...
Again, thanks for a lovely product!
//Magnus
Dan Pascu wrote:
> Thanks for the report. The problem is indeed that you removed the from_tag
> which is mandatory. However there was also some inaccurate handling in
> this case which I had to fix (which become obvious thanks to the trace
> you provided). I will make a new release in the next days as I still have
> to wait for another bugfix to become available first.
>
> On Tuesday 09 December 2008, Magnus Burman wrote:
>
>> Found the error... my modification of the from-header must be faulty,
>> cut out the if-clause below and everything works!
>>
>> Note to self, get some sleep before asking stupid questions... ;)
>>
>> Best Regards,
>> Magnus
>>
>> Magnus Burman wrote:
>>
>>> Having some troubles getting Mediaproxy 2.1.0 working. I'm on a VPS
>>> with a fresh Debian Etch, running OpenSips 1.4.3 (which log below is
>>> for, also tried Kamailio 1.4.1 earlier [separate debian
>>> installation], log was pretty much identical).
>>>
>>> Best Regards,
>>> Magnus
>>>
>>> --- syslog ---
>>> Dec 9 01:01:30 host001 media-relay[2492]:
>>> [RelayClientProtocol,client] error: Required header "from_tag" for
>>> command "update" not found
>>>
>>> route[1] {
>>>## Forward statefully
>>># Find users caller-id
>>>if(avp_db_query("select call_id from subscriber_extras where
>>> username = '$fU'", "$avp(s:cid)")) {
>>>remove_hf("From");
>>>append_hf("From: >\r\n", "To");
>>>}
>>>setflag(1);
>>>if (!t_relay()) {
>>>sl_reply_error();
>>>};
>>>exit;
>>> }
>>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips-cp: Sip Trace Tool
Hi Matteo, I ran into the same problem, OpenSips 1.4.3 and Mediaproxy 2.1.0 with CDRtool 6.6.10. In the file /var/www/CDRTool/library/cdr_openser.php I changed time_stamp to date on lines 2943 and 3015. That's the only places I found it and the siptrace in CDRTool works wonderfully now. Hope you'll find the same success. //Magnus > Hi all. > I have added the bug on the opensips-cp tracker. > I hope that the problem be resolved soon. > I'm trying to understand how the sip trace tool search by date of records in > the sip_trace table, > > >> Hi Matteo , >> > > >> looks like a mismatching of naming (in opensips and opensips-cp) :( >> "date" and "time_stamp" are the same... >> > > >> Please report the bug on the opensips-cp tracker. >> > > >> Regards, >> Bogdan >> > > mmarzu...@interfree.it wrote: > >> Hi. >> In the table of the Sip Trace tool the Date Time column is blank for each >> sip message stored and if I try to do a search by date, I get the error: >> >> Unknown column 'date' in 'where clause' >> >> In the sip_trace table the values in the time_stamp column are present. >> >> There is a problem of mismatch between the names of columns or a problem of >> date formats? >> >> Thanks. >> >> Marzuola Matteo >> >> >> >> >> >> ___ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] High load average due to mi_datagram's sockets
I noticed a strange load average on my system. When the system was idle, I
had a load of 4.00. It turns out that it's directly related to mi_datagram:s
children_count. I had 5, and the load was 4. Lowering to 2 I got load 1.00,
lowering to 1 I get 0.00, increasing to 20 I get 19.
This is on an idle system (no calls), with nothing but a "regular" setup of
Opensips + Mediaproxy (w/ radius and cdrtool).
What could possible cause this?
--
modparam("mi_datagram", "socket_name", "/var/run/opensips/mi_datagram.sock")
modparam("mi_datagram", "children_count", 20)
modparam("mi_datagram", "unix_socket_mode", 0666) # same without this row
modparam("mi_datagram", "socket_timeout", 2000) # same without this row
--
top - 16:35:46 up 2 days, 20:19, 4 users, load average: 19.00, 18.99,
18.22
Tasks: 141 total, 1 running, 140 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si,
0.0%st
Mem: 3060736k total, 1198600k used, 1862136k free, 123576k buffers
Swap: 9896000k total,0k used, 9896000k free, 559468k cached
--
Best Regards,
Magnus
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Mediaproxy python errors (AlreadyCalled)
I see this in the syslog every 5 seconds. It's not constant, so I'm guessing
it only occurs for a subset of the calls. When it does occur thou, it's once
every 5 seconds.
Could anyone shed some light on what is causing this?
Dec 9 12:44:51 sbc1 media-relay[4335]: Traceback (most recent call last):
Dec 9 12:44:51 sbc1 media-relay[4335]: File
"/usr/lib/python2.5/site-packages/twisted/python/log.py", line 69, in
callWithContext
Dec 9 12:44:51 sbc1 media-relay[4335]: return
context.call({ILogContext: newCtx}, func, *args, **kw)
Dec 9 12:44:51 sbc1 media-relay[4335]: File
"/usr/lib/python2.5/site-packages/twisted/python/context.py", line 59, in
callWithContext
Dec 9 12:44:51 sbc1 media-relay[4335]: return
self.currentContext().callWithContext(ctx, func, *args, **kw)
Dec 9 12:44:51 sbc1 media-relay[4335]: File
"/usr/lib/python2.5/site-packages/twisted/python/context.py", line 37, in
callWithContext
Dec 9 12:44:51 sbc1 media-relay[4335]: return func(*args,**kw)
Dec 9 12:44:51 sbc1 media-relay[4335]: File
"/usr/lib/python2.5/site-packages/twisted/internet/epollreactor.py", line
231, in _doReadOrWrite
Dec 9 12:44:51 sbc1 media-relay[4335]: why = selectable.doRead()
Dec 9 12:44:51 sbc1 media-relay[4335]: --- ---
Dec 9 12:44:51 sbc1 media-relay[4335]: File
"/usr/lib/python2.5/site-packages/twisted/internet/udp.py", line 126, in
doRead
Dec 9 12:44:51 sbc1 media-relay[4335]:
self.protocol.datagramReceived(data, addr)
Dec 9 12:44:51 sbc1 media-relay[4335]: File
"/usr/lib/pymodules/python2.5/mediaproxy/mediacontrol.py", line 127, in
datagramReceived
Dec 9 12:44:51 sbc1 media-relay[4335]: self.cb_func(host, port, data)
Dec 9 12:44:51 sbc1 media-relay[4335]: File
"/usr/lib/pymodules/python2.5/mediaproxy/mediacontrol.py", line 186, in
got_data
Dec 9 12:44:51 sbc1 media-relay[4335]: self.timer.cancel()
Dec 9 12:44:51 sbc1 media-relay[4335]: File
"/usr/lib/python2.5/site-packages/twisted/internet/base.py", line 95, in
cancel
Dec 9 12:44:51 sbc1 media-relay[4335]: raise error.AlreadyCalled
Dec 9 12:44:51 sbc1 media-relay[4335]:
twisted.internet.error.AlreadyCalled: Tried to cancel an already-called
event.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] do_routing() sending several invites per call
Hi,
I'm moving from Opensips 1.4 to 1.6.1 currently and I'm getting some strange
behavior from droute. After it sends the INVITE, it resends it, and again,
for a total of 8 times, each time adding the opensips ip to record-route and
Via. Each invite gets its own record in radacct.
Anyone with an idea where I'm going wrong?
Below is the "relevant" part of my config:
route[1] {
setflag(1);
$avp(s:can_uri) = $ru;
if (!t_relay()) {
sl_reply_error();
};
exit;
}
route[10] {
# pre-processing with strips/prefixes etc
...
if(do_routing("0")) {
xlog("Regular routing");
route(1);
exit;
}
exit;
}
Below is the first INVITE sent out by Opensips. IP:s have been changed to
protect the innocent; they're all public, no NAT:
U 2010/01/19 17:29:19.825093 111.111.114.120:5060 -> 222.222.222.222:5060
INVITE sip:34610100...@222.222.222.222
SIP/2.0.
Record-Route:
.
Via: SIP/2.0/UDP 111.111.114.120;branch=z9hG4bK3eea.5d650714.1.
Via: SIP/2.0/UDP 111.111.115.122:5060;branch=z9hG4bK-4fddec66.
From: "34620200200"
>;tag=fd1f3a1d6bcfabebo0.
To: >.
Call-ID: 6bf71385-64676...@111.111.115.122.
CSeq: 101 INVITE.
Max-Forwards: 69.
Contact: "Magnus" .
Expires: 240.
User-Agent: Linksys/SPA921-5.1.8.
Content-Length: 208.
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER.
Supported: replaces.
Content-Type: application/sdp.
P-hint: inbound->inbound .
.
v=0.
o=- 13541 13541 IN IP4 111.111.115.122.
s=-.
c=IN IP4 111.111.115.122.
t=0 0.
m=audio 16408 RTP/AVP 8 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=ptime:30.
a=sendrecv.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] do_routing() sending several invites per call
What happend was that do_routing in secret makes a call to route[1] before
overwriting RURI. I changed all references to route[1] to route[111] instead
(%s/route(1)/route(111)/g) and modified route[1] to do in essence nothing.
Below is the new code as well as the syslog. Calls are now forwarded
correctly, but it worries me that route[1] is still called somehow, without
*any* references to it anywhere in the config file.
route[1] {
xlog("route-1: ru=$ru; du=$du; rd=$rd");
exit;
}
route[10] {
# pre-processing with strips/prefixes etc
...
xlog("Before routing: ru=$ru; du=$du; rd=$rd");
if(do_routing("0")) {
xlog("After routing: ru=$ru; du=$du; rd=$rd");
route(111);
exit;
}
exit;
}
route[111] {
setflag(1);
$avp(s:can_uri) = $ru;
xlog("route-111: ru=$ru; du=$du; rd=$rd");
if (!t_relay()) {
sl_reply_error();
};
exit;
}
SYSLOG:
Jan 20 16:24:19 sbc2 /usr/sbin/opensips[1109]: Before routing:
ru=sip:34615122...@opensips; du=; rd=opensips
Jan 20 16:24:19 sbc2 /usr/sbin/opensips[1109]: route-1:
ru=sip:34615122...@opensips; du=; rd=opensips
Jan 20 16:24:19 sbc2 /usr/sbin/opensips[1109]: After routing:
ru=sip:34615122...@trunk; du=; rd=TRUNK
Jan 20 16:24:19 sbc2 /usr/sbin/opensips[1109]: route-111:
ru=sip:34615122...@trunk; du=; rd=TRUNK
2010/1/19 Magnus Burman
> Hi,
>
> I'm moving from Opensips 1.4 to 1.6.1 currently and I'm getting some
> strange behavior from droute. After it sends the INVITE, it resends it, and
> again, for a total of 8 times, each time adding the opensips ip to
> record-route and Via. Each invite gets its own record in radacct.
>
> Anyone with an idea where I'm going wrong?
>
> Below is the "relevant" part of my config:
>
> route[1] {
> setflag(1);
> $avp(s:can_uri) = $ru;
> if (!t_relay()) {
> sl_reply_error();
> };
> exit;
> }
>
> route[10] {
> # pre-processing with strips/prefixes etc
> ...
> if(do_routing("0")) {
> xlog("Regular routing");
> route(1);
> exit;
> }
> exit;
> }
>
> Below is the first INVITE sent out by Opensips. IP:s have been changed to
> protect the innocent; they're all public, no NAT:
>
> U 2010/01/19 17:29:19.825093 111.111.114.120:5060 -> 222.222.222.222:5060
> INVITE sip:34610100...@222.222.222.222
> SIP/2.0.
> Record-Route:
> .
> Via: SIP/2.0/UDP 111.111.114.120;branch=z9hG4bK3eea.5d650714.1.
> Via: SIP/2.0/UDP 111.111.115.122:5060;branch=z9hG4bK-4fddec66.
> From: "34620200200"
>
> >;tag=fd1f3a1d6bcfabebo0.
> To: >.
> Call-ID: 6bf71385-64676...@111.111.115.122.
> CSeq: 101 INVITE.
> Max-Forwards: 69.
> Contact: "Magnus" .
> Expires: 240.
> User-Agent: Linksys/SPA921-5.1.8.
> Content-Length: 208.
> Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER.
> Supported: replaces.
> Content-Type: application/sdp.
> P-hint: inbound->inbound .
> .
> v=0.
> o=- 13541 13541 IN IP4 111.111.115.122.
> s=-.
> c=IN IP4 111.111.115.122.
> t=0 0.
> m=audio 16408 RTP/AVP 8 101.
> a=rtpmap:8 PCMA/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-15.
> a=ptime:30.
> a=sendrecv.
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
Hi guys, I've got a problem with "sporadic" one-way audio, using latest stable Opensips 1.4 and Mediaproxy 2. The problem occurs at re-invites, thou not every time. When it does happen, the media port is changed towards the callee. Example: First invite: INVITE Trunk:40518 --> Proxy:50358 INVITE Proxy:58928 --> UA:5206 Re-invite: INVITE Trunk:40518 --> Proxy:50358 INVITE Proxy:40518 --> UA:5206 Notice how the Proxy port on the UA side (callee local) changed to the same port that Trunk uses (caller remote). One way audio now occurs and naturally the call is soon hung up. Mediaproxy now dumps some useful statistics showing: 'callee_remote': 'UA:5206' 'caller_remote': 'TRUNK:40518' 'callee_local': 'PROXY:58928' 'caller_local': 'PROXY:50358' Notice here how the callee_local is the original port used. Where should I start looking to be able to solve this problem? Is it most likely my config, something weird with the re-invite or have I stumbled upon a bug? Thankful for every and all suggestions, as I lay sleepless at night thinking about this! :-P Cheers, Magnus ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
Hi,
I did a wireshark export, 2461 lines, so it's in the pastebin:
http://pastebin.ca/1775584
syslog below:
11.11.X.Y - Trunk subnet
22.22.X.Y - Proxy subnet
98400 - UA DID
X.voip.url.es - UA sip subscriber
Jan 11 22:28:07 sbc1 media-relay[4335]: debug: Got traffic information for
stream: (audio) 11.11.6.144:40518 (RTP: Unknown, RTCP: Unknown) <->
22.22.224.9:50358 <-> 22.22.224.9:58928 <-> Unknown (RTP: 22.22.198.159:5206,
RTCP: Unknown)
Jan 11 22:28:07 sbc1 media-relay[4335]: debug: Got traffic information for
stream: (audio) 11.11.6.144:40518 (RTP: Unknown, RTCP: Unknown) <->
22.22.224.9:50358 <-> 22.22.224.9:58928 <-> Unknown (RTP: 22.22.198.159:5206,
RTCP: 22.22.198.159:5207)
Jan 11 22:28:07 sbc1 media-relay[4335]: debug: Got initial answer from
callee for stream: (audio) 11.11.6.144:40518 (RTP: Unknown, RTCP: Unknown)
<-> 22.22.224.9:50358 <-> 22.22.224.9:58928 <-> 22.22.198.159:5206 (RTP:
22.22.198.159:5206, RTCP: 22.22.198.159:5207)
Jan 11 22:28:07 sbc1 media-relay[4335]: debug: Got traffic information for
stream: (audio) 11.11.6.144:40518 (RTP: 11.11.6.144:40518, RTCP: Unknown)
<-> 22.22.224.9:50358 <-> 22.22.224.9:58928 <-> 22.22.198.159:5206 (RTP:
22.22.198.159:5206, RTCP: 22.22.198.159:5207)
Jan 11 22:29:26 sbc1 media-relay[4335]: debug: Got traffic information for
stream: (audio) 11.11.6.144:40518 (RTP: 11.11.6.144:40518, RTCP: Unknown)
<-> 22.22.224.9:50358 <-> 22.22.224.9:58928 <-> 22.22.198.159:5206 (RTP:
22.22.198.159:5206, RTCP: 22.22.198.159:5207)
Jan 11 22:54:20 sbc1 media-dispatcher[4324]: debug: Got statistics:
{'from_tag': 'e-13c4-10b392b-75e19db4-10b392b', 'dialog_id':
'1305:480665684', 'start_time': 1263245287.181, 'timed_out': False,
'call_id': 'a27f94c89e3e13c410b392b13d753bdb84e00e2147f91b8-0266-6714',
'to_tag': 'ICF_197662497-514', 'streams': [{'status': 'closed',
'caller_codec': 'G711a', 'post_dial_delay': 10.76835417749,
'callee_codec': 'G711a', 'start_time': 0, 'caller_bytes': 15733000,
'callee_bytes': 15328600, 'caller_packets': 78665, 'end_time': 1573,
'callee_remote': '22.22.198.159:5206', 'caller_remote': '11.11.6.144:40518',
'media_type': 'audio', 'callee_local': '22.22.224.9:58928', 'timeout_wait':
0, 'caller_local': '22.22.224.9:50358', 'callee_packets': 76643}, {'status':
'rejected', 'caller_codec': 'Unknown', 'post_dial_delay': None,
'callee_codec': 'Unknown', 'start_time': 0, 'caller_bytes': 0,
'callee_bytes': 0, 'caller_packets': 0, 'end_time': 0, 'callee_remote':
'Unknown', 'caller_remote': 'Unknown', 'media_type': 'image',
'callee_local': '22.22.224.9:59676', 'timeout_wait': 0, 'caller_local': '
22.22.224.9:58930', 'callee_packets': 0}], 'duration': 1573, 'to_uri': '
984000...@22.22.224.9:5060', 'from_uri': '34963555...@11.11.0.144:5060',
'callee_ua': 'unknown agent', 'caller_ua': 'CS2000_NGSS/9.0'}
Cheers,
Magnus
2010/2/2 Saúl Ibarra Corretgé
> Hi,
>
> El 02/02/10 11:54, Magnus Burman escribió:
> > Hi guys,
> >
> > I've got a problem with "sporadic" one-way audio, using latest stable
> > Opensips 1.4 and Mediaproxy 2.
> >
> > The problem occurs at re-invites, thou not every time. When it does
> > happen, the media port is changed towards the callee. Example:
> >
> > First invite:
> > INVITE Trunk:40518 --> Proxy:50358
> > INVITE Proxy:58928 --> UA:5206
> >
> > Re-invite:
> > INVITE Trunk:40518 --> Proxy:50358
> > INVITE Proxy:40518 --> UA:5206
> >
> > Notice how the Proxy port on the UA side (callee local) changed to the
> > same port that Trunk uses (caller remote).
> >
> > One way audio now occurs and naturally the call is soon hung up.
> > Mediaproxy now dumps some useful statistics showing:
> >
> > 'callee_remote': 'UA:5206'
> > 'caller_remote': 'TRUNK:40518'
> > 'callee_local': 'PROXY:58928'
> > 'caller_local': 'PROXY:50358'
> >
> > Notice here how the callee_local is the original port used.
> >
> > Where should I start looking to be able to solve this problem? Is it
> > most likely my config, something weird with the re-invite or have I
> > stumbled upon a bug?
> >
> > Thankful for every and all suggestions, as I lay sleepless at night
> > thinking about this! :-P
> >
>
> It would be nice to have a full SIP trace and the syslog output of
> MediaProxy to check if it's doing something wrong. Also, which function
> are you using for starting it?
>
>
>
> Regards,
>
>
> --
> Saúl Ibarra Corretgé
> AG Projects
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
I'll start capturing like that right away, less you want the pcap-file for that specific call? Since the problem only occurs sporadically and at re-invites (ie 20+ minutes into a call) it's a bit of a mess to track down calls that fit the criteria. But I'll get right on it for sure, thanks. Cheers, Magnus 2010/2/2 Saúl Ibarra Corretgé > El 02/02/10 13:59, Magnus Burman escribió: > > Hi, > > > > I did a wireshark export, 2461 lines, so it's in the pastebin: > > > > http://pastebin.ca/1775584 > > > > It's really hard to follow a text wireshark cap, could you do a ngrep > capture? ngrep -d any -W byline -T -P '' port 5060 > > > -- > Saúl Ibarra Corretgé > AG Projects > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
Nice little utility, saves alot of time on typing. :-) Here's a pastbin with the correct format (ngrep-sip b) of the same call: http://pastebin.ca/1776903 Thanks, Magnus 2010/2/2 Iñaki Baz Castillo > El Martes, 2 de Febrero de 2010, Magnus Burman escribió: > > I'll start capturing like that right away, less you want the pcap-file > for > > that specific call? Since the problem only occurs sporadically and at > > re-invites (ie 20+ minutes into a call) it's a bit of a mess to track > down > > calls that fit the criteria. But I'll get right on it for sure, thanks. > > Try this to filter the captured data: > > http://dev.sipdoc.net/projects/sip-stuff/wiki/Ngrep-SIP > > > -- > Iñaki Baz Castillo > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
None of my users are behind NAT, they're all on public IPs (I control their
connection).
Sorry if it's a stupid question, but what do you mean with "the SDP is not
modified by mediaproxy"?
On line 276 in the re-invite (Opensips --> UA) the port used is different:
m=audio 40518 RTP/AVP 18 8 0 101'
The original invite (line 73) reads: m=audio 58928 RTP/AVP 18 8 0 101'
In the statistics dumped at the end, port says 58928.
This is my config in regards to mediaproxy. I included the loose_route above
as well, as this is all that comes before it in the route:
##Loose_route packets
if (loose_route()) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
if(method=="BYE") {
setflag(1);
$avp(s:can_uri) = $ru;
}
route(1);
};
if (method==INVITE && !has_totag()) {
if(avp_db_query("select 1 from subscriber_debug where username =
'$fU'", "$avp(s:debug)")) {
# No media proxy if in debug
} else {
engage_media_proxy();
}
}
2010/2/3 Iñaki Baz Castillo
> El Miércoles, 3 de Febrero de 2010, Magnus Burman escribió:
> > Nice little utility, saves alot of time on typing. :-)
> >
> > Here's a pastbin with the correct format (ngrep-sip b) of the same call:
> > http://pastebin.ca/1776903
>
> As you can see, the SDP in not modified by mediaproxy module for the
> re-INVITE
> and the 200 response for the re-INVITE. This means that you get
> one-way-audio
> as the caller is behind NAT.
>
> You should inspect why you are not calling mediaproxy functions when
> handling
> in-dialog INVITE and its responses.
>
>
> --
> Iñaki Baz Castillo
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
Now I see what you're saying. I thought mediaproxy used the wrong port in the re-invite, while it is in fact not engaged at all and thus the original IP and port is sent on. That makes a lot of sense, thank you. According to the docs the engage_media_proxy should only be called once on the initial invite thou and after that use the dialog module to trace the dialog. Any suggestions as how to debug where it fails? I'm not getting any output in the syslog. Cheers, Magnus 2010/2/3 Iñaki Baz Castillo > El Miércoles, 3 de Febrero de 2010, Magnus Burman escribió: > > None of my users are behind NAT, they're all on public IPs (I control > their > > connection). > > It could occur that the gateway just allows RTP from certains IP's. > > > > Sorry if it's a stupid question, but what do you mean with "the SDP is > not > > modified by mediaproxy"? > > Do you know how MediaProxy works by replacing the media IP in the SDP of > INVITE and responses? Take a look to the first (initial) INVITE. The INVITE > arrives to OpenSIPS with a media address XX.XX.XX.XX in the SDP, but when > it > leaves the proxy to go to the gateway the media is different because > opensips > has modified it to make it going through the MediaProxy server. > > But this doesn't occur for the re-INVITE as you can see in your trace. > > > > On line 276 in the re-invite (Opensips --> UA) the port used is > different: > > m=audio 40518 RTP/AVP 18 8 0 101' > > The original invite (line 73) reads: m=audio 58928 RTP/AVP 18 8 0 101' > > Not just the port but also the SDP. And this occurs because the explained > above: opensips is not replacing the ip:port in the SDP for the re-INVITE > and > its response. You should check why not. > > However I don't know mediaproxy module functions very well so I don't know > what "engage_mediaproxy" should do. I just can tell you what is happening > in > the trace. > > > -- > Iñaki Baz Castillo > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
Thank you for your help Iñaki, it's much appreciated. By asking my last question I was hoping someone else might chime in. :-) Best Regards, Magnus 2010/2/3 Iñaki Baz Castillo > El Miércoles, 3 de Febrero de 2010, Magnus Burman escribió: > > Now I see what you're saying. I thought mediaproxy used the wrong port in > > the re-invite, while it is in fact not engaged at all and thus the > original > > IP and port is sent on. That makes a lot of sense, thank you. > > Yes, that's the problem. > > > > According to the docs the engage_media_proxy should only be called once > on > > the initial invite thou and after that use the dialog module to trace the > > dialog. Any suggestions as how to debug where it fails? I'm not getting > any > > output in the syslog. > > As I said I don't know mediaproxy module very well as I just used the old > one > (some years ago). > > > > -- > Iñaki Baz Castillo > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] One way audio - media port changed (opensips / mediaproxy)
Hmm, you are right, that wasn't the full syslog for that call. Investigating further I see that I get the following: Jan 11 22:28:07 sbc1 /usr/sbin/opensips[27792]: CRITICAL:dialog:log_next_state_dlg: bogus event 6 in state 2 for dlg 0x7f5e880692a0 [1305:480665684] with clid 'a27f94c89e3e13c410b392b13d753bdb84e00e2147f91b8-0266-6714' and tags 'e-13c4-10b392b-75e19db4-10b392b' '' This is right after the call has been established; the next event in the sip trace is at 22:53:40, the re-invite. According to a year old post by Bogdan ( http://www.mail-archive.com/users@lists.opensips.org/msg00700.html) this means that ACK is received before 200 OK. Here's the sip trace up to the point of the dialog error: 22:27:56.376925 Trunk -> Proxy : INVITE 22:27:56.381153 Proxy -> Trunk : 100 TRYING 22:27:56.381215 Proxy -> UA___ : INVITE 22:27:56.437339 UA___ -> Proxy : 100 TRYING 22:27:56.552454 UA___ -> Proxy : 180 RINGING 22:27:56.552530 Proxy -> Trunk : 180 RINGING 22:28:07.179499 UA___ -> Proxy : 200 OK 22:28:07.182204 Proxy -> Trunk : 200 OK 22:28:07.197002 Trunk -> Proxy : ACK 22:28:07.197158 Proxy -> UA___ : ACK Could this be the source of the problem? Best Regards, Magnus 2010/2/3 Saúl Ibarra Corretgé > Hi, > > El 03/02/10 14:43, Magnus Burman escribió: > > Now I see what you're saying. I thought mediaproxy used the wrong port > > in the re-invite, while it is in fact not engaged at all and thus the > > original IP and port is sent on. That makes a lot of sense, thank you. > > > > According to the docs the engage_media_proxy should only be called once > > on the initial invite thou and after that use the dialog module to trace > > the dialog. Any suggestions as how to debug where it fails? I'm not > > getting any output in the syslog. > > > > You are correct, the by calling engage_mediaproxy the dialog module > should take care. However, it's surprising that this only happens > sometimes, so it's harder to debug :( Is the syslog you pasted in your > earlier mail the only output you get for that call? Any warning from the > dialog module? > > > > Regards, > > -- > Saúl Ibarra Corretgé > AG Projects > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Call control behavior at end of time limit
Hi guys, Is it possible to use call control in a way that when the time limit of the call is reached, it re-auths against the rating-engine? My goal is to use relatively short time limits in a pre-paid scenario with many concurrent calls on the same user, to limit credit risk without locking up too much of the users credit limit per call. Thanks, Magnus ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Blacklisting on prefix and domain
Hi guys,
What would be the preferred way to do user blackinglisting on domain? The
userblacklist module only seem to look at username (I can't find a reference
to domain in the mysql log), and even if it did I assume it would look for a
match on both username and module.
I would prefer to have it tied to drouting as it'd give me a single place
for my destinations, but anything "native" would be considered. I try to
stay away from avp_db_query when I can, but atm I'm using the below. While
it works, I'd really like to move away from customer queries whenever
possible.
if(avp_db_query("select whitelist from userblacklist where domain like '$fd'
and '$rU' like concat(prefix, '%') order by char_length(prefix) desc limit
1", "$avp(s:dbl)")) {
if($avp(s:dbl) == 0) {
sl_send_reply("403", "Forbidden destination");
exit;
}
}
Cheers,
Magnus
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Call control always returning 1 - Call with limit, even with rating engine down
Hi guys,
I'm having some problems with callcontrol. I always get return code 1,
even when I don't have a rating engine up. Consequently the call is
set up (bad) and it's not tore down at the end of the timer (bad).
Any hints of how I can debug this further?
syslog:
2010-06-15T12:10:04.125+02:00 /usr/sbin/opensips [11547] Before callcontrol
2010-06-15T12:10:04.128+02:00 /usr/sbin/opensips [11546]
ERROR:call_control:send_command: did timeout waiting for an answer
2010-06-15T12:10:04.128+02:00 /usr/sbin/opensips [11546] After callcontrol
2010-06-15T12:10:04.128+02:00 /usr/sbin/opensips [11546] Call control:
return code 1 - Call with limit
opensips.cfg
if((method=="INVITE" && !has_totag())) {
xlog("L_INFO", "Before callcontrol");
call_control();
xlog("L_INFO", "After callcontrol");
switch($retcode) {
case 2:
# Call with no limit
xlog("L_INFO", "Call control: return code 2 - call
with no limit");
break;
case 1:
# Call with a limit under callcontrol management
xlog("L_INFO", "Call control: return code 1 - Call with limit");
break;
case -1:
xlog("L_INFO", "Call control: not enough credit for
prepaid call\n");
acc_aaa_request("402");
sl_send_reply("402", "Not enough credit");
exit;
break;
case -2:
# Locked by call in progress (prepaid call)
xlog("L_INFO", "Call control: prepaid call locked by
another call in progress\n");
acc_aaa_request("403");
sl_send_reply("403", "Call locked by a another call in
progress");
exit;
break;
default:
# Internal error
xlog("L_INFO", "Call control: internal server error\n");
acc_aaa_request("500");
sl_send_reply("500", "Internal server error");
exit;
}
}
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Call control always returning 1 - Call with limit, even with rating engine down
So to answer my own question: xlog does of course also populate retcode...
2010/6/15 Magnus Burman :
> Hi guys,
>
> I'm having some problems with callcontrol. I always get return code 1,
> even when I don't have a rating engine up. Consequently the call is
> set up (bad) and it's not tore down at the end of the timer (bad).
>
> Any hints of how I can debug this further?
>
> syslog:
> 2010-06-15T12:10:04.125+02:00 /usr/sbin/opensips [11547] Before callcontrol
> 2010-06-15T12:10:04.128+02:00 /usr/sbin/opensips [11546]
> ERROR:call_control:send_command: did timeout waiting for an answer
> 2010-06-15T12:10:04.128+02:00 /usr/sbin/opensips [11546] After callcontrol
> 2010-06-15T12:10:04.128+02:00 /usr/sbin/opensips [11546] Call control:
> return code 1 - Call with limit
>
> opensips.cfg
> if((method=="INVITE" && !has_totag())) {
> xlog("L_INFO", "Before callcontrol");
> call_control();
> xlog("L_INFO", "After callcontrol");
> switch($retcode) {
> case 2:
> # Call with no limit
> xlog("L_INFO", "Call control: return code 2 - call
> with no limit");
> break;
> case 1:
> # Call with a limit under callcontrol management
> xlog("L_INFO", "Call control: return code 1 - Call with
> limit");
> break;
> case -1:
> xlog("L_INFO", "Call control: not enough credit for
> prepaid call\n");
> acc_aaa_request("402");
> sl_send_reply("402", "Not enough credit");
> exit;
> break;
> case -2:
> # Locked by call in progress (prepaid call)
> xlog("L_INFO", "Call control: prepaid call locked by
> another call in progress\n");
> acc_aaa_request("403");
> sl_send_reply("403", "Call locked by a another call in
> progress");
> exit;
> break;
> default:
> # Internal error
> xlog("L_INFO", "Call control: internal server error\n");
> acc_aaa_request("500");
> sl_send_reply("500", "Internal server error");
> exit;
> }
> }
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Adding functionality to call control (python)
Hi guys, To get a more flexible credit control when running several concurrent calls on the same user I'm trying to add some functionality to the call control module. Basically what I'm trying to do is set a low time limit, such as 60 seconds, and when the timer runs out send a new getCallLimit, until the call ends either by a return of 0 or by hangup. I've been trying to do this by adding a new getCallLimit in the Call.__expire method in sip.py. def __expire(self): rating = RatingEngineConnections.getConnection(self) rating.getCallLimit(self).addCallbacks(callback=self._reinit_simple_calllimit, errback=self._start_error) """ self.expired = True self.application.clean_call(self.callid) self.end(reason='call control', sendbye=True) """ In _reinit_sample_calllimit I mimic _start_finish_calllimit in a lot of ways, trying different timer combinations. I've tried with cancel followed by a new setup, I've tried delay, I've tried reset, I've tried manually doing a new ReactorTimer and all of the above! I get the MaxSessionTime call to work, but I fail with the timer somehow. __expire is never called again after the first time, and the call is never interrupted. Anyone with tips? At this point I'm about to dive into the twisted framework and reactors, but any hints are much appreciated! Cheers, Magnus ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Adding functionality to call control (python)
Hi Adrian, I struggle to figure out how the MaxSessionTime for new calls are calculated. As a simple example, have a first session ask for 3600s. Then a second session does the same directly thereafter, with the same rate (for simplicity), but credit is low and only 2000s is allowed. How does call control figure out that both calls should end after 2800 seconds? Even more importantly to me is what happens when a third call is entered into the mix. The credit is now at 0, is this call established? What I'm trying to achieve right here is handling multiple sessions without blocking the credit. By having call control re-ask for MaxSessionTime after a shorter time-period (60s), blocking will not occur to such a large degree. Is this a bad way of doing it? I'm actually trying to integrate this with a 3rd party rating engine that supports this schema as I believe it's a good way of handling multiple sessions. Cheers, Magnus 2010/6/18 Adrian Georgescu > The call control engine + rating engine already supports multiple parallel > prepaid sessions per user, all calls stop when the balance reaches zero. > > What do you try to achieve? > > Adrian > > > On Jun 18, 2010, at 4:56 PM, Magnus Burman wrote: > > Hi guys, > > To get a more flexible credit control when running several concurrent calls > on the same user I'm trying to add some functionality to the call control > module. > > Basically what I'm trying to do is set a low time limit, such as 60 > seconds, and when the timer runs out send a new getCallLimit, until the call > ends either by a return of 0 or by hangup. > > I've been trying to do this by adding a new getCallLimit in the > Call.__expire method in sip.py. > > def __expire(self): > rating = RatingEngineConnections.getConnection(self) > > > rating.getCallLimit(self).addCallbacks(callback=self._reinit_simple_calllimit, > errback=self._start_error) > """ > self.expired = True > self.application.clean_call(self.callid) > self.end(reason='call control', sendbye=True) > """ > > In _reinit_sample_calllimit I mimic _start_finish_calllimit in a lot of > ways, trying different timer combinations. I've tried with cancel followed > by a new setup, I've tried delay, I've tried reset, I've tried manually > doing a new ReactorTimer and all of the above! > > I get the MaxSessionTime call to work, but I fail with the timer somehow. > __expire is never called again after the first time, and the call is never > interrupted. > > Anyone with tips? At this point I'm about to dive into the twisted > framework and reactors, but any hints are much appreciated! > > Cheers, > Magnus > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Adding functionality to call control (python)
Thank you for the feedback Adrian, I will certainly look into doing it that way instead. Best Regards, Magnus 2010/6/21 Adrian Georgescu > > On Jun 21, 2010, at 2:32 AM, Magnus Burman wrote: > > Hi Adrian, > > I struggle to figure out how the MaxSessionTime for new calls are > calculated. As a simple example, have a first session ask for 3600s. Then a > second session does the same directly thereafter, with the same rate (for > simplicity), but credit is low and only 2000s is allowed. How does call > control figure out that both calls should end after 2800 seconds? > > > This is done by recalculating based on the remaining balance a new max > session time for each individual session. The remaining balance is > redistributed in such way that all calls end up at the same time when the > balance reaches zero. So the Rating engine does not only return to the call > control the max session time for the current call but also for previous > calls if any are ongoing. > > Check Prepaid documentation from CDRTool where this is explained in detail. > > > Even more importantly to me is what happens when a third call is entered > into the mix. The credit is now at 0, is this call established? > > What I'm trying to achieve right here is handling multiple sessions without > blocking the credit. By having call control re-ask for MaxSessionTime after > a shorter time-period (60s), blocking will not occur to such a large degree. > > > Again you are trying to solve a problem that does not exist. > > > Is this a bad way of doing it? I'm actually trying to integrate this with a > 3rd party rating engine that supports this schema as I believe it's a good > way of handling multiple sessions. > > > Read the documentation, it contains pseudo code for how to do it in other > rating engine app. > > > Cheers, > Magnus > > 2010/6/18 Adrian Georgescu > >> The call control engine + rating engine already supports multiple parallel >> prepaid sessions per user, all calls stop when the balance reaches zero. >> >> What do you try to achieve? >> >> Adrian >> >> >> On Jun 18, 2010, at 4:56 PM, Magnus Burman wrote: >> >> Hi guys, >> >> To get a more flexible credit control when running several concurrent >> calls on the same user I'm trying to add some functionality to the call >> control module. >> >> Basically what I'm trying to do is set a low time limit, such as 60 >> seconds, and when the timer runs out send a new getCallLimit, until the call >> ends either by a return of 0 or by hangup. >> >> I've been trying to do this by adding a new getCallLimit in the >> Call.__expire method in sip.py. >> >> def __expire(self): >> rating = RatingEngineConnections.getConnection(self) >> >> >> rating.getCallLimit(self).addCallbacks(callback=self._reinit_simple_calllimit, >> errback=self._start_error) >> """ >> self.expired = True >> self.application.clean_call(self.callid) >> self.end(reason='call control', sendbye=True) >> """ >> >> In _reinit_sample_calllimit I mimic _start_finish_calllimit in a lot of >> ways, trying different timer combinations. I've tried with cancel followed >> by a new setup, I've tried delay, I've tried reset, I've tried manually >> doing a new ReactorTimer and all of the above! >> >> I get the MaxSessionTime call to work, but I fail with the timer somehow. >> __expire is never called again after the first time, and the call is never >> interrupted. >> >> Anyone with tips? At this point I'm about to dive into the twisted >> framework and reactors, but any hints are much appreciated! >> >> Cheers, >> Magnus >> ___ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> ___ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Changing FROM header several times
To get outgoing caller id to work I have to change my FROM header to a
trunk-specific format. While this is ugly, it works, unless I try to do it
more then once. Using gateway lists in drouting this scenario can happen as
the routing script is run for each gateway on failure.
Is there another way for me to do this? Either by only using
uac_replace_from once, or by alternating the FROM header in another way?
With the below script I end up with duplicates:
From: "123456789""34123456789" ;tag=as0ab5e31d.
if(do_routing()) {
route(111);
exit;
}
#...
route[111] {
# Do gateway-specific processing
switch($rd) {
case "1.1.1.1":
route(callid1);
break;
case "2.2.2.2":
route(callid2);
break;
case "3.3.3.3":
route(callid3);
break;
default:
route(callid1);
}
t_on_failure("1");
if (!t_relay()) {
sl_reply_error();
};
exit;
}
route[callid1] {
if(avp_db_query("select call_id from subscriber_extras where username =
'$fU'", "$avp(s:cid)")) {
uac_replace_from("34$avp(s:cid)", "sip:34$avp(s:cid)@$td");
}
}
route[callid2] {
if(avp_db_query("select call_id from subscriber_extras where username =
'$fU'", "$avp(s:cid)")) {
uac_replace_from("+34$avp(s:cid)", "sip:+34$avp(s:cid)@$td");
}
}
route[callid3] {
if(avp_db_query("select call_id from subscriber_extras where username =
'$fU'", "$avp(s:cid)")) {
uac_replace_from("$avp(s:cid)", "sip:$avp(s:cid)@$td");
}
}
failure_route[1] {
if(use_next_gw()) {
t_on_failure("1");
route(111);
exit;
}
}
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
