Hi,
Thanks for the report, this was a bug and I've pushed the fix for it, it
should be fine now.
Regards,
Vlad Patrascu
OpenSIPS Developer
http://www.opensips-solutions.com
On 04/23/2019 01:54 PM, Konrad Malewski wrote:
Hello,
I switched to opensips3 and b2b internal scenario stopped
Hello,
I switched to opensips3 and b2b internal scenario stopped working:
Apr 23 10:33:29 [55] ERROR:b2b_logic:fixup_b2b_logic: Wrong Scenary ID. No
scenario with this ID [�Ͷ�s]
Apr 23 10:33:29 [55] ERROR:core:fix_cmd: Fixup failed for param [1]
Apr 23 10:33:29 [55] ERROR:core:fix_actions:
, does OpenSIPS send any message out (even to himself)? Can you
provide a full trace?
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
On 11/07/2016 03:20 PM, Denis wrote:
Re: [OpenSIPS-Users] B2B top hiding Hello, Razvan!
I want to make some input point to my SIP network
wrote:
Re: [OpenSIPS-Users] B2B top hiding Hello, Razvan!
I want to make some input point to my SIP network which will make
authentication and topology hiding.
Authentication works (i checked it by inserting in client SIP UA wrong
password), but b2b doesn`t.
When i try to setting port before
Hello, Razvan!
I want to make some input point to my SIP network which will make
authentication and topology hiding.
Authentication works (i checked it by inserting in client SIP UA wrong
password), but b2b doesn`t.
When i try to setting port before b2b_init_request i see in log "
Hi, Denis!
Can you please detail a bit what you are trying to achieve? In the trace
attached, all I can see is that OpenSIPS doesn't authenticate the UA - I
don't see why it should even try to send the INVITE anywhere.
However, if you are saying that you see both lines in the log, it means
at
Hello!
Opensips 2.2.2.
I want to make an installation of Opensips which will include auth and top
hiding functionality.
First of all, in the main route, i catch INVITE
"if (is_method("INVITE") && !has_totag()) {
route(1);
exit;
}"
then, in route [1], i make some auth procedure using
Hi David,
Once you put a call through B2B, topology hiding is done - that's the
nature of a B2B. So simply using the B2B module gives you TH. The TH
scenario is for case when you want B2B without any scenario , but only
passing through.
So just use your "refer" scenario and you will see
Is it possible to run both the topology hiding and refer scenarios for B2B?
I've tried and get an error when establishing an outbound call when the ACK
should be sent.
Scenarios initialized:
b2b_init_request("top hiding");
b2b_init_request("refer");
Error:
On Thu, Mar 17, 2011 at 8:38 PM, Jeff Pyle jp...@fidelityvoice.com wrote:
Ovidiu,
Acknowledged on the b2b module.
In my experience it depends on the carrier. Some cases either side
can/will send the re-invite. In other cases, the term carrier requires
that the originating side send the
Hello,
The scenario is this:
Adtran CPE
|
|
Opensips proxy 1
|
|
Opensips B2BUA
|
|
Opensips proxy 2
|
|
PSTN Gateway
Opensips is 1.6.4 installed from Debian packages in
This seems to be an issue with the b2b module, but there's also an
issue with the Adtran CPE.
If the fax is sent from the Adtran CPE to PSTN, then the PSTN GW is
the one that detects the preamble and therefore responsible for
re-negotiation. The Adtran CPE should not send a re-INVITE, instead
it
Ovidiu,
Acknowledged on the b2b module.
In my experience it depends on the carrier. Some cases either side
can/will send the re-invite. In other cases, the term carrier requires
that the originating side send the re-invite (the Adtran in this case).
The Adtran CPE can be configured to do any
Hi Jeff,
On 03/08/2011 05:08 AM, Jeff Pyle wrote:
Hello,
I noticed the To header is not contained in on the initial INVITEs
that come out of the top-hiding scenario on the b2b modules. Is there
a way to cause that for more consistent formatting? Specifically,
here's a sample output from
@lists.opensips.orgmailto:users@lists.opensips.org
users@lists.opensips.orgmailto:users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] b2b top hiding - from/to header formatting
Hi Jeff,
On 03/08/2011 05:08 AM, Jeff Pyle wrote:
Hello,
I noticed the To header is not contained in on the initial INVITEs that come
out
Hello,
I noticed the To header is not contained in on the initial INVITEs that come
out of the top-hiding scenario on the b2b modules. Is there a way to cause
that for more consistent formatting? Specifically, here's a sample output from
1.6.4:
To: sip:8005551...@domain.tld:5060
From:
Jeff,
I checked nathelper code in opensips 1.6.4 and looks like adding the
oldip header to the SDP is not there anymore.
So you shouldn't need to modify the source like I had to previously to
accomplish complete topology hiding.
Also it doesn't really matter if you use rtp_proxy or media proxy
Hello,
Since the top-hiding scenario doesn't touch the SDP, it seems some
extracurricular textops may be required to fully hide the topology of the
network. I've been trying various subst_body() functions on my b2b Opensips
instance, each failing in a new and wonderful way.
What's the point of hiding the o= line?
The c= line will still reveal the connection IP for RTP.
If you want true topology hiding, then use two servers and chain them:
- opensips with rtpproxy;
- opensips as a b2bua with top hidding.
On the rtpproxy server you will be able to mask everything
Ovidiu,
Apparently once a dialog is in b2b-land, its messages are unavailable to
scripting functions? It seems Anca has said this a time or two. Or
three. Still seems strange.
I'm close to what you have suggested. I'm using mediaproxy on my main
proxy in lieu of rtpproxy, with b2bua on a
On 2/8/11 4:39 PM, Ovidiu Sas o...@voipembedded.com wrote:
On Tue, Feb 8, 2011 at 3:59 PM, Jeff Pyle jp...@fidelityvoice.com wrote:
Ovidiu,
Apparently once a dialog is in b2b-land, its messages are unavailable to
scripting functions? It seems Anca has said this a time or two. Or
three.
In b2b routes you see the received message and therefor you cannot
apply any changes to the message that is sent (you don't have a handle
to it).
In local route, you see the INVITE that is about to be sent out and
that one is modifiable.
Regards,
Ovidiu Sas
On Tue, Feb 8, 2011 at 4:48 PM, Jeff
Got it.
Am I to believe, then, that only the initial initialized UAC INVITE hits
the local route? Everything after that for a dialog is visible in the b2b
ones only, and therefore untouchable?
- Jeff
On 2/8/11 4:58 PM, Ovidiu Sas o...@voipembedded.com wrote:
In b2b routes you see the
yup
On Tue, Feb 8, 2011 at 5:15 PM, Jeff Pyle jp...@fidelityvoice.com wrote:
Got it.
Am I to believe, then, that only the initial initialized UAC INVITE hits
the local route? Everything after that for a dialog is visible in the b2b
ones only, and therefore untouchable?
- Jeff
On
Now you now, and knowing is half the battle.
-- G.I. Joe
On 2/8/11 5:36 PM, Ovidiu Sas o...@voipembedded.com wrote:
yup
On Tue, Feb 8, 2011 at 5:15 PM, Jeff Pyle jp...@fidelityvoice.com wrote:
Got it.
Am I to believe, then, that only the initial initialized
Hi Guys,
I am testing the following call flow:
Soft Phone = opensips (configured for B2B) = third party termination SIP
proxy
Here is my config:
modparam(b2b_entities, script_req_route, b2b_request)
modparam(b2b_entities, script_reply_route, b2b_reply)
local_route {
The B2B module is operating on the received INVITE. Any changes that
you make to the received INVITE are not visible by the B2B module.
Use a proxy to perform whatever you want to do (rtpproxy, accounting,
etc.) and a separate server only for b2b (top hiding).
Regards,
Ovidiu Sas
On Wed, Feb 2,
Hi Ovidu,
I do not perform any changes on the received invite.
The top hiding does it and the problem is.. it does not change only the
media IP. Everything else goes OK.
Are you saying the top hiding does not work properly with the nathelper ?
Thanks
-- Kamen
On 2 February 2011 19:41,
The nathelper module is performing changes on the received INVITE
(changing the SDP).
Those changes are not visible by the b2b module and therefor discarded.
As a result, the nathelper module (and any module that is changing the
initial INVITE) doesn't work with the b2b module.
The only change
yes!
On Wed, Feb 2, 2011 at 1:12 PM, Kamen Petrov kamen.pet...@gmail.com wrote:
Ok, that brings some clarification. Thanks.
So the correct scenario is:
1) softphone --registered to-- opensips A (pure)
2) call is relayed from opensips A to opensips B (the B2B one)
3) the opensips B connects
Hi Anca,
Thanks, the other end changed to use the IP address and now it works.
Regards,
Henk
On 03-01-11 14:06, Anca Vamanu wrote:
Hi Henk,
The reason is that the RURI for the first BYE does not match the contact
that OpenSIPS B2BUA put in 200Ok:
U 2011/01/02 03:23:25.592645
Hi Henk,
The reason is that the RURI for the first BYE does not match the contact
that OpenSIPS B2BUA put in 200Ok:
U 2011/01/02 03:23:25.592645 10.190.0.1:5061 - 10.135.59.244:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 10.135.59.244:5060;branch=z9hG4bK5ogp5300b81hjec9n300.1.
Hi Anton,
On 12/23/2010 06:41 PM, Anton Zagorskiy wrote:
Hi.
Could you some explain about interaction between original INVITE transaction
and b2b top hiding's transaction?
They are different transactions. The first one is not forwarded and is
replied by the server. And the second one is
I'm using the example b2b script from the tutorial with top hiding
instead of prepaid. On hangup the BYE is not being processed by b2b
and the original is sent instead.
I've spent hours trying to see why b2b doesn't handle the BYE, but I
just can't see it. Can anyone explain?
The config file
Hi.
Could you some explain about interaction between original INVITE transaction
and b2b top hiding's transaction?
As I see that b2b transmits all sip packets to the original INVITE
transaction via loopback interface.
And in the failure situation in the B2B transaction my failure route was
Hello,
I am having trouble understanding exactly how the top-hiding scenario does a
call compared to one that simply uses the tm module to relay it. Because of
this lack of understanding I can't even begin to understand the impact it would
have on accounting.
I'm okay with tm-based
Hello Jeff,
The flag based accounting works only for relayed transactions.
With b2b, none of the transactions are relayed and therefor flag based
accounting will not work.
If you use the local_route and b2b_request/reply routes, you can
invoke some manual accounting:
Ovidiu,
I understand the separate server idea. That indeed would be the simplest
with the existing configuration.
The manual accounting option does pique my curiosity. I see the the
accounting functions you referenced in the documentation. In the
flag-based accounting I'm used to, the radius
Try to play with manual syslog accounting. If that works ok for you,
then I'm pretty sure that radius accounting can be adjusted to work.
I don't remember exactly if manual radius acc sent proper accounting
types (e.g. START, STOP, FAILED). It has been a long time since I
setup a server with
Hi Ancu,
No more problems with the buffer size! Excellent.
P-Asserted-Identity still doesn't make it through even though it's defined in
the custom_headers list. Everything else seems to. Any thoughts?
I'm going to need more than 10 headers in the list. But when I try, I see:
Hi Jeff,
I increased the number of extra hdrs to 32 - please update from SVN.
Regards,
Bogdan
Jeff Pyle wrote:
Hi Ancu,
No more problems with the buffer size! Excellent.
P-Asserted-Identity still doesn't make it through even though it's defined in
the custom_headers list. Everything
Hello,
During my first adventure into topology hiding it seemed the b2b modules
weren't bringing all my custom_headers from one side to the other. During my
testing I encountered this problem:
ERROR:b2b_entities:client_new: Buffer too small
ERROR:b2b_logic:create_top_hiding_entities: failed
Hi Jeff,
This error is generated when when constructing extra headers to be added
to the message that will be sent outside. Indeed the size might be too
little - 256. I will fix this.
Regards,
--
Anca Vamanu
www.voice-system.ro
Jeff Pyle wrote:
Hello,
During my first adventure into
Hi Jeff,
Jeff Pyle wrote:
I found the BUF_LEN value in the b2b_entities/client.c and b2b_entities/dlg.c
value, and increased it from 256 to 512. This seems to have taken care of
the errors. I wonder what else I've broken by changing this.
That was indeed the right place for the
44 matches
Mail list logo
