Hi,
thanks very much for your reply. That's also what i thought, first it
was just a siptrace where opensips sends to the second gw but the invite
got no Record-route header.
But later on, I was able to reproduce the problem and when adding
another record_route() the second invite is indeed
Hello
SIP SERVER public IP 61.67.128.46
SIP SERVER private ip 10.10.12.111
Client Netwok 192.168.4.x
It's my sip trace.
-- 2013-03-15 10:44:30 - Received from 61.67.128.46:5060 from
192.168.4.197:5060
INVITE sip:@192.168.4.197:5060 SIP/2.0
Hello,
I'm looking for some information about the integration of Opensips with an
MSRP Relay (like http://www.msrprelay.org/ ).
How can I configure opensips to order to pilot an MSRP relay ?
Is there somewhere some basic example ?
Regards,
Pierre-Yves
The relay is controlled by the client, not by the server. See RFC 4976 to
understand how it work.
The only thing shared with OpenSIPS is the account credentials database.
Regards,
Adrian
On Mar 15, 2013, at 10:11 AM, Pierre-Yves Marche wrote:
Hello,
I'm looking for some information about
Hi Nick,
But in the SDP-s received by the UACs, in the c line, you see the IP
of the other UAC and not the IP of OpenSIPS, right ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 03/15/2013 03:28 AM, Nick Chang wrote:
Hello Bodgan
2 UACs
Hello Nick,
As Bogdan pointed out please look at the important parts of your SDP payload:
sip:55688@61.67.128.46:5060
Contact: sip:55688@211.75.166.164:5060
c=IN IP4 211.75.166.164
sip:@61.67.128.46
Contact: sip:@192.168.4.197:5060
c=IN IP4 192.168.4.197
Kind Regards,
Nick.
On
Hello List,
Is there a way to use shared variables in modules' configuration?
For example:
modparam(cfgutils, shvset, DBURI=s:mysql//user:pass@host/accdb)
modparam(acc, db_url, $shv(DBURI))
does not work for me:
ERROR:core:db_check_api: module db_$shv(DBURI) does not export db_use_table
Greetings;
I've got a bit of an oddity. We have a TDM media convertor putting a
$00 (NUL) at the end of the Remote-Party-ID header which is killing
one of our proprietary (and unfixable) SIP stacks. For the life of me
I can't figure out how to get OpenSIPS to strip this - it appears like
the
The logic for using rtpproxy_answer/offer is the same since forever.
Regards,
Ovidiu Sas
On Wed, Mar 13, 2013 at 1:15 PM, Nick Khamis sym...@gmail.com wrote:
Before I forget, I always wanted to ask the list for an up to date
configuration file that uses RTPProxy and rtpproxy_answer/offer. This
Contact is just a SIP header that you can manipulate via
transformations and sipmsgops functions.
You can even remove the received header and build/append a new one.
Regards,
Ovidiu Sas
On Wed, Mar 13, 2013 at 1:13 PM, Nick Khamis sym...@gmail.com wrote:
Hello Ovidiu,
Thank you so much for
Dears,
While testing and reading I find out how I can change the outgoing signaling
IP using
if (!has_totag() is_method(INVITE)) {
$var(a) = udp:+$avp(termip)+:5060;
$fs = $var(a) ;
..
But that will change the signaling realm for all outgoing calls for all
trunks
sorry don't worry. There is no problem in fact in the code.
The problem was on my opensips.cfg. Problem fixed
Regards,
Pierre-Yves
On Fri, Mar 15, 2013 at 6:14 PM, Pierre-Yves Marche
pierrey.mar...@gmail.com wrote:
Hello,
We are using the topology_hiding() function from dialog module on
12 matches
Mail list logo
