;
t_relay();
$du = sip:pstn2.lab.sld.tld;
t_relay();
In the tcpdump I see that the register is relayed to both pstn server.
But one pstn server ignores the register.
Thank you for your help.
Best Regards,
Julian Santer
___
Users mailing
Hi,
we used OpenSips 1.8.2 not 1.8.4 (which doesn't exists ;-) ).
I did an update do 1.8.3 and no if I relay the register to both server,
both server handle it correct.
So for me the problem is solved.
Best regards,
Julian Santer
Am 03.09.2013 19:30, schrieb Julian Santer:
Hi,
we
.
At the moment we are using 1.8 and I can planning an update to 1.11 LTS
entire the next year.
Kind regards,
Julian Santer
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
ate("sip:REGISTRAR_SLAVE", "0x04");
t_on_branch("BR_DROP");
}
if ($(hdr(Contact)) == null)
{
xlog("L_INFO", "Retrieving locations - LF_BASE");
} else {
xlog("L_INFO", "Registration successful - LF_B
the username in the TO header?
AVM said, if we sent OPTIONS with username, the DOS mechanism should not be
triggered anymore.
Best regards and merry christmas,
Julian Santer
Raiffeisen OnLine
___
Users mailing list
Users@lists.opensips.org
http
|
| |
|>>| 1 PF:26 15:08:23.4061
======
Kind regards,
Julian Santer
Raiffeisen OnLine
Am 18.11.2015 um 23:25 schrieb Bogdan-Andrei Ia
2f6fd55.0
From: <sip:+396789@domain>;tag=E3AE5C5C-1A42
Call-ID: GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE
To: <sip:12345@domain>
CSeq: 101 CANCEL
Max-Forwards: 70
Route: <sip:IP_GW-CONSUMER;lr>
Reason: SIP;cause=480;text="NO_ANSWER"
User-Agent: Op
Hi Bogdan,
thank you for your time. If you need further informations (config files etc.)
let me know.
Kind regards,
Julian Santer
Raiffeisen OnLine
Am 11.02.2016 um 10:26 schrieb Bogdan-Andrei Iancu:
Hi Julian,
I will have to test this and come back to you.
Regards,
Bogdan-Andrei Iancu
Bogdan,
we tried now the latest GIT release and it works like a charm ;-)
Thank you for quick fix.
Kind regards,
Julian Santer
Raiffeisen OnLine
Am 11.02.2016 um 14:02 schrieb Bogdan-Andrei Iancu:
Julian,
Please update from GIT repo and give it a new try. It should work now (at least
quest-Line: INVITE sip:michael@10.97.174.161:43097;transport=udp SIP/2.0
Why the received param is not set as Request-Line? Not on REGISTRAR and not on
EDGE server.
How can I tell the REGISTRAR or EDGE to use the IP from the received column?
Kind regards,
Julian Santer
the 200 OK package the private
ip and port
Have we to call fix_contact on the 200 OK? And this will fix the misbehaviour?
Kind regards,
Julian Santer
Raiffeisen OnLine
Am 15.03.2016 um 14:14 schrieb Julian Santer:
Hi guys,
we use OpenSip 2.1.2.
We have a registrar/core (1.2.3.5) and a edge
in.it>;tag=F8155FD8-19F9
Call-ID:
Edge2_BgsVAAAaIR8SdQYTJgZ5FgcINkV9ESUCXmovIw4ABDUmCnUBXB0mVSYULR8LKiAfAmUBCh8fdD0HCjJVdS83IXwOByQOAAQ8MixzEVxXPGoIKCocYHQmNBJeBjEyAnwQLQAtRWhJ
Content-Length: 0
CSeq: 1 BYE
Here the edge server enters the prublic IP in the via header as received param.
Why he don't to this for the ACK package?
Kind regards,
Julian Santer
Raiffeisen OnLine
__
Hi guys,
it was my mistake.
We now call nat_uac_test and fix_nated_contact and it works like expected.
Thank you for your time
Kind regards,
Julian Santer
Raiffeisen OnLine
Am 15.03.2016 um 20:24 schrieb Julian Santer:
Hi guys,
sometimes the ACK works.
I have to calls:
1) Call from PSTN
, "bytes": 28, "errors": 0 }, "RTCP": {
"packets": 1, "bytes": 48, "errors": 0 } }, "result": "ok" ...
Mar 8 11:14:33 ... }
Established call 1. branch
Mar 8 11:14:37 Confirmed peer address as 2.3.4.6:59482
Mar 8 11:14:37 Confirmed peer address as 3.4.5.6:51372
Mar 8 11:14:37 Kernelizing media stream: 3.4.5.6:51372
Mar 8 11:14:37 Kernelizing media stream: 2.3.4.6:59482
Mar 8 11:14:38 Confirmed peer address as 3.4.5.6:51373
Mar 8 11:14:40 Confirmed peer address as 2.3.4.6:59483
Garbage collector removes also the established and working 1. branch
Mar 8 11:15:03 Call branch 'D40356B0-22E3' (via-branch '') deleted, no more
branches remaining
Mar 8 11:15:03 Final packet stats:
Mar 8 11:15:03 --- Tag 'D40356B0-22E3', created 0:38 ago for branch '', in
dialogue with 'b8nbyduymv'
Mar 8 11:15:03 -- Media #1 (audio over RTP/AVP) using G729/8000
Mar 8 11:15:03 - Port 50018 <> 2.3.4.6:59482, 1417 p, 45344 b, 0 e,
1457432102 last_packet
Mar 8 11:15:03 - Port 50019 <> 2.3.4.6:59483 (RTCP), 6 p, 792 b, 0
e, 1457432101 last_packet
Mar 8 11:15:03 --- Tag 'b8nbyduymv', created 0:38 ago for branch 'ZzJFVwVlR0BDd2RHMF8DFUZZLAQUQjBcBWReR1ZzEUFHWgQQS0dAAGFCWlwcYUE-0', in dialogue
with 'D40356B0-22E3'
Mar 8 11:15:03 -- Media #1 (audio over RTP/AVP) using G729/8000
Mar 8 11:15:03 - Port 5 <> 3.4.5.6:51372, 1560 p, 41746 b, 0 e,
1457432102 last_packet
Mar 8 11:15:03 - Port 50001 <> 3.4.5.6:51373 (RTCP), 6 p, 388 b, 0
e, 1457432098 last_packet
Mar 8 11:15:03 --- Tag '', created 0:38 ago for branch 'ZzJFVwVlR0BDd2RHMF8DFUZZLAQUQjBcBWReR1ZzEUFHWgQQS0dAAGFCWlwcYUE-1', in dialogue with
'D40356B0-22E3'
Mar 8 11:15:03 -- Media #1 (audio over RTP/AVP) using unknown codec
Mar 8 11:15:03 - Port 50040 <> (null):0, 0 p, 0 b, 0 e,
1457432065 last_packet
Mar 8 11:15:03 - Port 50041 <> (null):0 (RTCP), 0 p, 0
b, 0 e, 1457432065 last_packet
It seems, that the VIA-branch is been ignored and only the to-tag is been
recognized by the garbage collector.
But I'm sure that RTPEngine can handle multiple branches. So maybe you could
give me a hint, where my error is?
Kind regards,
Julian Santer
Raiffeisen OnLine
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
OpenSIPS[10256]: INFO:core:handle_sigs: core was generated
Mar 8 11:02:08 OpenSIPS[10256]: INFO:core:handle_sigs: terminating due to
SIGCHLD
Kind regards,
Julian Santer
Raiffeisen OnLine
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
", 0)
For the test, in the register route I tried to set always the sipping_bflag:
if (proto == UDP)
{
setbflag(SIP_PING_FLAG);
xlog("L_INFO", "Nat keepalive sip_ping_flag - LF_BASE");
}
But in my traces I can't find any OPTIONS send by the nathelper module.
Could you give me a hint?
Kind regards,
Julian Santer
Raiffeisen OnLine
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Hi Johan,
as the asterisk is not administrated by us, I have to ask the customer.
As I understand you think the problem should be the private IP in the VIA header
and this should be fixed with STUN, right?
Kind regards,
Julian Santer
Raiffeisen OnLine
Am 29.04.2016 um 09:17 schrieb Johan De
registrar/core, when we got a Re-Invite?
You can find the trace under http://siptrace.rolbox.net/siptrace.html
Kind regards,
Julian Santer
Raiffeisen OnLine
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
be ignored, right?
At the moment we call force_rport() in all our instances.
I think, we should call force_rport() only on the edge server where we make the
nat_handling, right?
Kind regards,
Julian Santer
Raiffeisen OnLIne
Am 29.04.2016 um 10:10 schrieb Johan De Clercq:
Indeed.
2016-04-29 9:49
We are using 2.1.2
So we made a "huge" version update and also changed the kind of working
Am 29.04.2016 um 14:27 schrieb Johan De Clercq:
What version do you use in your new install ?
2016-04-29 13:12 GMT+02:00 Julian Santer <julian.san...@rolmail.net
<mailto:julian.sa
um 15:56 schrieb Johan De Clercq:
I don;t think so : force_rport just adds the port on which you receive to the
first via header.
2016-04-29 15:36 GMT+02:00 Julian Santer <julian.san...@rolmail.net
<mailto:julian.san...@rolmail.net>>:
We are using 2.1.2
So we made a "
, so all clients should receive a
keepalive.
I hoped that the core sends now:
- OPTIONS with data from usrloc
- uses the path from usrloc to send the OPTIONS to the edge server, and then I
could relay to the client
But the core sends now the 4 bytes (zero filled) UDP packages to the edge
se
Santer
Raiffeisen OnLine
Am 29.04.2016 um 15:56 schrieb Johan De Clercq:
I don;t think so : force_rport just adds the port on which you receive to the
first via header.
2016-04-29 15:36 GMT+02:00 Julian Santer <julian.san...@rolmail.net
<mailto:julian.san...@rolmail.net>>:
t over the cancel_branch() function (in the timeout handler) so the TH callbacks can
reach back the dialog and do the TH related changes.
Reported by Julian Santer on mailing list.
Kind regards,
Julian Santer
Raiffeisen OnLine
Am 18.04.2016 um 22:35 schrieb John Nash:
which revision this was fixed?.
;L_INFO", "Removing G.729");
codec_delete("G729");
}
The codec_exists works, but the codec is not been deleted:
Sep 30 21:51:00 core2 OpenSIPS[29371]: Removing G.729
Please let me know if you need more information.
Kind regards,
Julian Santer
__
Hi Bogdan,
if I exec "subnet_dump", I receive the records in grp "52", but the records in grp
"54" are missing.
Kind regards,
Julian Santer
Am 14.11.18 um 15:20 schrieb Bogdan-Andrei Iancu:
Hi Julian,
If you do a "subnet_dump" (see
http://
ep 11
2018) ID=5DC1E7DC326043BA@192.168.1.215 B=
I already did a opensipsctl address reload and several times restarted the
whole opensips service.
Have you maybe some hint for me?
Kind regards,
Julian Santer
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Hi Bogdan,
yes we got the following critical errors:
CRITICAL:permissions:subnet_table_insert: subnet table is full
How many records could be stored and is there a way to increase the limit?
Kind regards,
Julian Santer
Am 16.11.18 um 17:12 schrieb Bogdan-Andrei Iancu:
Hi Julian,
When you
Thank you again
Am 12.12.18 um 17:36 schrieb Liviu Chircu:
Then you can just do:
...
$ru = $(hdr(Path){nameaddr.uri}{param.value,received});
...
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 12.12.2018 18:33, Julian Santer wrote:
Hi Liviu,
thank you, but I have
);
}
As you can see, I also needed to add the contact uri params to the
received AVP. Without this params I get a 404 from the UAC.
To be sure, if this workaround works, I have to publish it on the
production server. I will do this tomorrow morning and I hope it works
also with the other,
emove I get >
Kind regards,
Julian Santer
Am 12.12.18 um 16:58 schrieb Liviu Chircu:
Hi Julian,
Good catch on the Contact URI params - will have to remember to
incorporate them into the fix when the time comes for it.
You can rid OpenSIPS of all those regex substitution operations with
thi
;db_url", "DBURL")
modparam("usrloc", "db_mode", 2)
modparam("usrloc", "matching_mode", 0)
modparam("usrloc", "cseq_delay", 20)
modparam("usrloc", "nat_bflag
, registration not stored");
xlog("L_ERR", "Adding PATH (with received) failed - LF_BASE");
exit;
}
Is this the right way or could I break something else with this change?
Kind regards,
Julian Santer
Am 19.11.18 um 18:41 schrieb Julian Santer:
Hi guys,
we need to
,
Julian Santer
Am 20.11.18 um 15:51 schrieb Julian Santer:
Hi guys,
if I don't use the received column on the edge server, but I call
fix_nated_contact instead, it seems to work.
if (nat_uac_test("127"))
{
fix_nated_contact();
}
consume_credentials();
if (! add_path())
{
34 matches
Mail list logo
