Re: [OpenSIPS-Users] Dispatcher + Proxy + NAT question

[Satish Patel]

Thanks Razvan,

for experiment i have put dispatcher on Public Interface and second
NIC on private interface which is connected to SIP proxy server.

On dispatcher i am not handling any NAT stuff all it does (record_route)

Do you think i should put NAT module in dispatcher and what kind of
NAT function i should use?

On Tue, Apr 18, 2017 at 4:37 AM, Răzvan Crainea  wrote:
> Hi, Satish!
>
> You will probably need to have the dispatcher working as a FrontEnd, with
> two interfaces that will work in bridge mode.
> Since the dispatcher is the one facing the Public internet, he's the one
> that should take care of any NAT handling.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutions
> www.opensips-solutions.com
>
>
> On 04/16/2017 03:48 AM, Satish Patel wrote:
>>
>> Any help here?
>>
>> On Sat, Apr 15, 2017 at 10:04 AM, Satish Patel 
>> wrote:
>>>
>>> currently we have following design 1 dispatcher and 3 SIP Proxy and
>>> every server on Public IP. Dispatcher using as a load-balancer to
>>> distribute load on proxy.
>>>
>>> My dispatcher is very simple and stateless (I am not using record_route()
>>> too)
>>>
>>> Everything working fine, but now we decided to move alls SIP Proxy to
>>> Private IP address and just keep dispatcher on Public IP in that case
>>> i have to add record_route() function in dispatcher to put itself in
>>> path but question is how does NAT will work in this case? who will
>>> perform NAT function?
>>
>> ___
>> 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] codec_delete_except_re() has no effect

[Jeff Pyle]

Dragomir,

If Zoiper speaks only G.729, and SIP.js speaks only G.711, rtpengine isn't
going to help.  It doesn't transcode.  From its github page
:

*Rtpengine* does not (yet) support:


   - Repacketization or transcoding


Is iLBC an option for you in SIP.js and Zoiper?  It's license free and
sounds a little bitter.  If not, Asterisk or FreeSWITCH could perform this
task with the appropriate G.729 licenses.




Răzvan,

Is there any effect of using either the codec manipulation or rtpengine in
a branch route?  I ask this admittedly not understanding the buffers in use.




- Jeff






On Tue, Apr 18, 2017 at 12:39 PM, Dragomir Haralambiev 
wrote:

> Hi Razvan,
>
> How to make follow connection using rtpengine?
>
> Zoiper(g729) <-> Opensips(rtpengine) <> browser (SIP.JS with
> g711)
>
> 2017-04-18 19:10 GMT+03:00 Răzvan Crainea :
>
>> Hi, Jeff!
>>
>> Unfortunately you can't use both rtpengine and codec_delete_*, that's
>> because each change different buffers. The codec_delete_* function runs on
>> the initial SDP received, then rtpengine completely overwrites the SDP with
>> whatever rtpengine replied.
>> The only way you can do something like this (although it may be very
>> ugly) is to store the rtpengine reply in a pvar using the 3rd[1] parameter
>> of the rtpengine_* functions and perform some text replaces[2] on it, then
>> replace the body "manually".
>>
>> [1] http://www.opensips.org/html/docs/modules/2.3.x/rtpengine.ht
>> ml#rtpengine.f.rtpengine_offer
>> [2] http://www.opensips.org/html/docs/modules/2.3.x/textops#idp5907728
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutionswww.opensips-solutions.com
>>
>> On 04/18/2017 06:49 PM, Jeff Pyle wrote:
>>
>> Hello,
>>
>> This is on OpenSIPS 2.3, downloaded from git and compiled today.
>>
>> An INVITE arrives over TLS with the following SDP:
>>
>> v=0
>> o=- 1492528621 1492528621 IN IP4 172.22.202.191
>> s=Polycom IP Phone
>> c=IN IP4 172.22.202.191
>> t=0 0
>> m=audio 16852 RTP/SAVP 115 9 0 8 110 18 127
>> a=rtpmap:115 G7221/32000
>> a=fmtp:115 bitrate=48000
>> a=rtpmap:9 G722/8000
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:110 iLBC/8000
>> a=fmtp:110 mode=20
>> a=rtpmap:18 G729/8000
>> a=fmtp:18 annexb=no
>> a=rtpmap:127 telephone-event/8000
>> a=rtcp:16853
>> a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:[stripped]
>> a=setup:actpass
>> a=fingerprint:sha-1 [stripped]
>> m=audio 16888 RTP/AVP 115 9 0 8 110 18 127
>> a=rtpmap:115 G7221/32000
>> a=fmtp:115 bitrate=48000
>> a=rtpmap:9 G722/8000
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:110 iLBC/8000
>> a=fmtp:110 mode=20
>> a=rtpmap:18 G729/8000
>> a=fmtp:18 annexb=no
>> a=rtpmap:127 telephone-event/8000
>> a=rtcp:16889
>>
>> I run
>>   codec_delete_expect_re(PCMU|PCMA|telephone-event)
>> but it doesn't have any effect.  The INVITE leaving after t_relay() over
>> UDP to localhost on a different port is the same as when it came in (with
>> the exception of the c= line because of rtpengine).
>>
>> At log_level=6 the only log entry I see is
>>   DBG:sipmsgops:create_codec_lumps: creating 0 streams
>>
>> I'm not sure where to go from here.
>>
>>
>> - Jeff
>>
>>
>>
>> ___
>> Users mailing 
>> listUsers@lists.opensips.orghttp://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] codec_delete_except_re() has no effect

[Dragomir Haralambiev]

Hi Razvan,

How to make follow connection using rtpengine?

Zoiper(g729) <-> Opensips(rtpengine) <> browser (SIP.JS with
g711)

2017-04-18 19:10 GMT+03:00 Răzvan Crainea :

> Hi, Jeff!
>
> Unfortunately you can't use both rtpengine and codec_delete_*, that's
> because each change different buffers. The codec_delete_* function runs on
> the initial SDP received, then rtpengine completely overwrites the SDP with
> whatever rtpengine replied.
> The only way you can do something like this (although it may be very ugly)
> is to store the rtpengine reply in a pvar using the 3rd[1] parameter of the
> rtpengine_* functions and perform some text replaces[2] on it, then replace
> the body "manually".
>
> [1] http://www.opensips.org/html/docs/modules/2.3.x/rtpengine.
> html#rtpengine.f.rtpengine_offer
> [2] http://www.opensips.org/html/docs/modules/2.3.x/textops#idp5907728
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 04/18/2017 06:49 PM, Jeff Pyle wrote:
>
> Hello,
>
> This is on OpenSIPS 2.3, downloaded from git and compiled today.
>
> An INVITE arrives over TLS with the following SDP:
>
> v=0
> o=- 1492528621 1492528621 IN IP4 172.22.202.191
> s=Polycom IP Phone
> c=IN IP4 172.22.202.191
> t=0 0
> m=audio 16852 RTP/SAVP 115 9 0 8 110 18 127
> a=rtpmap:115 G7221/32000
> a=fmtp:115 bitrate=48000
> a=rtpmap:9 G722/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:110 iLBC/8000
> a=fmtp:110 mode=20
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=no
> a=rtpmap:127 telephone-event/8000
> a=rtcp:16853
> a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:[stripped]
> a=setup:actpass
> a=fingerprint:sha-1 [stripped]
> m=audio 16888 RTP/AVP 115 9 0 8 110 18 127
> a=rtpmap:115 G7221/32000
> a=fmtp:115 bitrate=48000
> a=rtpmap:9 G722/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:110 iLBC/8000
> a=fmtp:110 mode=20
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=no
> a=rtpmap:127 telephone-event/8000
> a=rtcp:16889
>
> I run
>   codec_delete_expect_re(PCMU|PCMA|telephone-event)
> but it doesn't have any effect.  The INVITE leaving after t_relay() over
> UDP to localhost on a different port is the same as when it came in (with
> the exception of the c= line because of rtpengine).
>
> At log_level=6 the only log entry I see is
>   DBG:sipmsgops:create_codec_lumps: creating 0 streams
>
> I'm not sure where to go from here.
>
>
> - Jeff
>
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://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] codec_delete_except_re() has no effect

[Răzvan Crainea]

Hi, Jeff!

Unfortunately you can't use both rtpengine and codec_delete_*, that's 
because each change different buffers. The codec_delete_* function runs 
on the initial SDP received, then rtpengine completely overwrites the 
SDP with whatever rtpengine replied.
The only way you can do something like this (although it may be very 
ugly) is to store the rtpengine reply in a pvar using the 3rd[1] 
parameter of the rtpengine_* functions and perform some text replaces[2] 
on it, then replace the body "manually".


[1] 
http://www.opensips.org/html/docs/modules/2.3.x/rtpengine.html#rtpengine.f.rtpengine_offer

[2] http://www.opensips.org/html/docs/modules/2.3.x/textops#idp5907728

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 04/18/2017 06:49 PM, Jeff Pyle wrote:

Hello,

This is on OpenSIPS 2.3, downloaded from git and compiled today.

An INVITE arrives over TLS with the following SDP:

v=0
o=- 1492528621 1492528621 IN IP4 172.22.202.191
s=Polycom IP Phone
c=IN IP4 172.22.202.191
t=0 0
m=audio 16852 RTP/SAVP 115 9 0 8 110 18 127
a=rtpmap:115 G7221/32000
a=fmtp:115 bitrate=48000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:110 iLBC/8000
a=fmtp:110 mode=20
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:127 telephone-event/8000
a=rtcp:16853
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:[stripped]
a=setup:actpass
a=fingerprint:sha-1 [stripped]
m=audio 16888 RTP/AVP 115 9 0 8 110 18 127
a=rtpmap:115 G7221/32000
a=fmtp:115 bitrate=48000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:110 iLBC/8000
a=fmtp:110 mode=20
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:127 telephone-event/8000
a=rtcp:16889

I run
  codec_delete_expect_re(PCMU|PCMA|telephone-event)
but it doesn't have any effect.  The INVITE leaving after t_relay() 
over UDP to localhost on a different port is the same as when it came 
in (with the exception of the c= line because of rtpengine).


At log_level=6 the only log entry I see is
  DBG:sipmsgops:create_codec_lumps: creating 0 streams

I'm not sure where to go from here.


- Jeff



___
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] DRouting in v2.2.3 is not overwriting the R-URI

[John Quick]

Update - problem solved.

It was bad data.  I had a value of 1 in the dr_rules.routeid field which caused 
do_routing to call route[1] which contained a t_relay statement.

This mistake was made after following the example for adding a new rule shown 
in opensipsctl help:
dr addrule '10,20' '+1' '20040101T083000' 0 0 '1,2' 'NA_RULE' 'NA routing'

...but this is a bad example because it will put a value of 0 in the routeid 
field.

I suggest the example be updated and shown like this:
dr addrule '10,20' '+1' '20040101T083000' 0 '' '1,2' 'NA_RULE' 'NA routing'

John Quick
Smartvox Limited

Thanks to Răzvan Crainea for trying to help.


>> Something quite strange is happening here. My initial assumption was 
>> wrong – this is not new behaviour in release v2.2.3.
>>
>> I have two servers, both running v2.2.3 and both using DRouting. I 
>> only get this problem on one of them.
>>
>> I added debug to show the number of branches just after calling 
>> do_routing(), like this:
>>  set_count("$branch(uri)", "$var(brcnt)");
>>  xlog("L_WARN", "BRANCH-COUNT=> $var(brcnt)\n");
>>
>> …Both servers report branch count = 0.
>>
>> Also added the following xlog statement in a new branch route (and 
>> added a call to t_on_branch(2) to trigger the new branch route):
>>
>>  xlog("L_WARN", "  Branch[2]: Branch ID $T_branch_idx  R-URI=$ru   
>> Call-ID=$ci\n");
>>
>> …On the server with the problem, it reports Branch ID 1, but on the 
>> server without the problem it reports Branch ID 0
>>
>> On the server with the problem, the SIP packet capture shows the 
>> INVITE sent to itself first then the INVITE sent to the DR gateway second.
>>
>> *John Quick
>> *Systems Consultant
>> SmartvoxLimited
>>

>>> /Hello,/
>>> / /
>>> /While testing with v2.2.3 it looks like the behaviour of the 
>>> do_routing()/ /function in the DROUTING module has changed./ /  From 
>>> packet captures, I can see the call is parallel forking to the
>> original/
>>
>>> /R-URI *and* to the first choice gateway destination from DRouting./ 
>>> /OpenSIPS sends two INVITE's - one to itself and the other to the DR
>> gateway./
>>
>>> /The gateway seems to be added as a branch./ / / /I think this is a 
>>> bug. I don't believe this happened on earlier versions of/ 
>>> /OpenSIPS./ / / /John Quick/ /Smartvox Limited/
>>> /Web: www.smartvox.co.uk/
>>> / /
>>> /___/
>>> /Users mailing list/
>>> /Users at lists.opensips.org


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] codec_delete_except_re() has no effect

[Jeff Pyle]

Hello,

This is on OpenSIPS 2.3, downloaded from git and compiled today.

An INVITE arrives over TLS with the following SDP:

v=0
o=- 1492528621 1492528621 IN IP4 172.22.202.191
s=Polycom IP Phone
c=IN IP4 172.22.202.191
t=0 0
m=audio 16852 RTP/SAVP 115 9 0 8 110 18 127
a=rtpmap:115 G7221/32000
a=fmtp:115 bitrate=48000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:110 iLBC/8000
a=fmtp:110 mode=20
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:127 telephone-event/8000
a=rtcp:16853
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:[stripped]
a=setup:actpass
a=fingerprint:sha-1 [stripped]
m=audio 16888 RTP/AVP 115 9 0 8 110 18 127
a=rtpmap:115 G7221/32000
a=fmtp:115 bitrate=48000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:110 iLBC/8000
a=fmtp:110 mode=20
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:127 telephone-event/8000
a=rtcp:16889

I run
  codec_delete_expect_re(PCMU|PCMA|telephone-event)
but it doesn't have any effect.  The INVITE leaving after t_relay() over
UDP to localhost on a different port is the same as when it came in (with
the exception of the c= line because of rtpengine).

At log_level=6 the only log entry I see is
  DBG:sipmsgops:create_codec_lumps: creating 0 streams

I'm not sure where to go from here.


- Jeff
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Dispatcher + Proxy + NAT question

[Răzvan Crainea]

Hi, Satish!

You will probably need to have the dispatcher working as a FrontEnd, 
with two interfaces that will work in bridge mode.
Since the dispatcher is the one facing the Public internet, he's the one 
that should take care of any NAT handling.


Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 04/16/2017 03:48 AM, Satish Patel wrote:

Any help here?

On Sat, Apr 15, 2017 at 10:04 AM, Satish Patel  wrote:

currently we have following design 1 dispatcher and 3 SIP Proxy and
every server on Public IP. Dispatcher using as a load-balancer to
distribute load on proxy.

My dispatcher is very simple and stateless (I am not using record_route() too)

Everything working fine, but now we decided to move alls SIP Proxy to
Private IP address and just keep dispatcher on Public IP in that case
i have to add record_route() function in dispatcher to put itself in
path but question is how does NAT will work in this case? who will
perform NAT function?

___
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