[SR-Users] Help needed to compile and install kamailio 5.1.2

[vinay kumar]

Hi All,

I want to compile kamailio 5.1.2 for debian packages amd install on ubuntu
16.04.
 And i have couple of queries.

1. can i compile and run  kamailio 5.1.2 on ubuntu 16.04(Xenial)?
2. Im currently using kamailio 4.3.6 with polaris configuration. And the
same way can i use kamailio 5.1.2 with polaris configuration files and
scripts to bringup kamailo 5.1.2?
and if yes, please share me steps and scripts to bringup kamailio 5.1 2
with Open HSS( i need to use CX and RX interface).

Please help me out.
Thanks in advance.

Regards,
vinay
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Re: Audio stops after resuming call from hold

[Arik Halperin]

I had a similar issue with RTP engine. When I got hold and called 
rtpengine_manage it had errors.

 I’m using rtpengine_manage, so doing something like this:

 if(!is_present_hf("x-purpose")) {
if(nat_uac_test("8")) {
xlog("L_ERR","NATMANAGE DBG test 8\n");

if(ds_is_from_list()){
rtpengine_manage("replace-session-connection 
replace-origin direction=priv direction=pub");
} else {
rtpengine_manage("replace-session-connection 
replace-origin direction=pub direction=priv");
}
} else {
if(ds_is_from_list()) {
rtpengine_manage("replace-session-connection 
replace-origin trust-address direction=priv direction=pub");
} else {
rtpengine_manage("replace-session-connection 
replace-origin trust-address direction=pub direction=priv");
}
}
}

The x-purpose is a header I added in my sip client whenever I do hold.

I hope that helps.

Best Regards,
Arik 


> On 23 Mar 2018, at 16:50, gerry kernan  wrote:
> 
> I’ve been testing with jitsi softphone from a different location( customer 
> was using Zoiper which fails every time) and hold/unhold works every time, 
> mightn’t  be a Kamailio or rtpengine issue. I’ll do further tests to see if 
> it local firewall/network
>  
>  
>  
> Best Regards
>  
> Gerry Kernan
>  
> From: sr-users [mailto:sr-users-boun...@lists.kamailio.org] On Behalf Of 
> Sergiu Pojoga
> Sent: 23 March 2018 12:50
> To: Kamailio (SER) - Users Mailing List 
> Subject: Re: [SR-Users]  Re: Audio stops after resuming call from 
> hold
>  
> Config code looks solid to me. Look at the 'c=' in SDP in the forward and 
> reply re-INVITEs. If it gets properly overwritten (same way as it is for the 
> dialog forming INVITE) when rtpengine is engaged, then I believe we are 
> facing some kind of bug in the 4.2 version of Kamailio, something about this 
> thread: 
> https://lists.kamailio.org/pipermail/sr-users/2012-September/074567.html 
> 
>  
> I can't upgrade Kamailio at the moment to test my theory as it's a production 
> environment, but may be you can?
>  
> On Fri, Mar 23, 2018 at 6:17 AM, gerry kernan  > wrote:
>> Hi 
>>  
>> I think my issue is related to rtpengine when the call is take off hold. Im 
>> using a private address and a public address . below is route section of our 
>> Kamailio.cfg and do I have somethimg setup incorrectly for handleing 
>> re-invites?
>>  
>>  
>> /usr/sbin/rtpengine --pidfile /var/run/rtpengine.pid --table=-1 
>> --interface=priv/192.X.X.X --interface=pub/212.X.X.X 
>> --listen-ng=127.0.0.1:7722  --tos=184 --timeout=60 
>> --log-level=7 --log-facility=local5 --homer-protocol=udp --homer-id=2011
>>  
>>  
>> request_route {
>>  
>> route(SANITY);
>>  
>> force_rport();
>>  
>> # CANCEL processing
>> if (is_method("CANCEL")) {
>> if (t_check_trans()) {
>> route(RELAY);
>> }
>> exit;
>> }
>>  
>> # handle retransmissions
>> if (!is_method("ACK")) {
>> if(t_precheck_trans()) {
>> t_check_trans();
>> exit;
>> }
>> t_check_trans();
>> }
>>  
>> # handle requests within SIP dialogs
>> route(WITHINDLG);
>>  
>> ### only initial requests (no To tag)
>>  
>> # record routing for dialog forming requests (in case they are 
>> routed)
>> if (is_method("INVITE|SUBSCRIBE")) {
>> record_route();
>> }
>>  
>> if (af==INET) {
>> route(SIPIPV4);
>> } else {
>> route(SIPIPV6);
>> }
>> }
>>  
>> # Stateful fowarding
>> route[RELAY] {
>> if (!t_relay()) {
>> sl_reply_error();
>> }
>> exit;
>> }
>>  
>> # Handle requests within SIP dialogs
>> route[WITHINDLG] {
>> if (!has_totag()) return;
>>  
>> # sequential request withing a dialog should
>> # take the path determined by record-routing
>> if (loose_route()) {
>> route(DLGURI);
>> if ( is_method("ACK") ) {
>> # ACK is forwarded statelessly
>> if (has_body("application/sdp")) {
>> rtpengine_answer();
>> }
>> } else if ( is_method("NOTIFY") ) {
>> # Add Record-Route for in-dialog NOTIFY as per 

Re: [SR-Users] Problem with resuming suspended transacation

[Arik Halperin]

I had a bug, I was resuming the wrong transaction indeed. I created a new 
transaction for the purpose of http async in a different route and this was 
causing the issue.

Actually managed to solve it after I posted this question.


> On 13 Apr 2018, at 9:55, Kjeld Flarup  wrote:
> 
> You are suspending in [6039] and resuming in [6092], does these two processes 
> share memory?
> 
>   Kjeld
> 
> 2018-04-12 11:52 GMT+02:00 Arik Halperin  >:
> Hello,
> 
>  
> 
> I’m trying to resume a suspended transaction, but keep getting this error:
> 
>  
> 
> WARNING: tm [t_suspend.c:193]: t_continue(): transaction is not suspended 
> [20608:1256194941]
> 
> WARNING: tmx [tmx_mod.c:686]: w_t_continue(): resuming the processing of 
> transaction [20608:1256194941] failed
> 
> WARNING: tm [t_lookup.c:1483]: t_unref(): script writer didn't release 
> transaction
> 
>  
> 
>  
> 
> I’m implementing push handling, in INVITE I do the following:
> 
>  
> 
> route[INVITE] {
> 
>   if (!lookup("location"))
> 
>   {
> 
>  
> 
>send_reply("100", "Trying");
> 
> record_route();
> 
> route(SUSPEND);
> 
>   }
> 
>   else
> 
>   {
> 
>  # NAT detection
> 
>  route(NATMANAGE);
> 
>  if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY");
> 
> record_route();
> 
>  t_relay();
> 
>  ts_store();
> 
>  $sht(vtp=>stored::$rU) = 1;
> 
> }
> 
> route(SENDPUSH);
> 
> }
> 
>  
> 
> # suspend the transaction
> 
> route[SUSPEND] {
> 
>  
> 
> if(!t_suspend()) //Transaction is suspended!
> 
> {
> 
>   exit;
> 
> }
> 
> $sht(vtp=>join::$rU) = "" + $T(id_index) + ":" +$T(id_label);
> 
> }
> 
>  
> 
> In Register I call the PUSHJOIN route:
> 
>  
> 
> # append branches or resume the transaction
> 
> route[PUSHJOIN] {
> 
> $var(hjoin) = 0;
> 
> lock("$tU");
> 
> $var(hjoin) = $sht(vtp=>join::$tU);
> 
> $var(hstored) = $sht(vtp=>stored::$tU);
> 
> $sht(vtp=>join::$tU) = $null;
> 
> unlock("$tU");
> 
> if ($var(hjoin)==0)
> 
> {
> 
> if ($var(hstored))
> 
> ts_append("location", "$tu");
> 
> return;
> 
> }
> 
> $var(id_index) = $(var(hjoin){s.select,0,:}{s.int });
> 
> $var(id_label) = $(var(hjoin){s.select,1,:}{s.int });
> 
> ($var(hjoin))\n");
> 
>  t_continue("$var(id_index)", "$var(id_label)", "INVRESUME");
> 
> }
> 
>  
> 
>  
> 
> For some reason I keep getting:
> 
>  
> 
> Apr 12 12:37:11 kamprod /usr/local/sbin/kamailio[6039]: ERROR: 

Re: [SR-Users] Kamailio with 2 Public and Private IPs- SIP Call flow issues

[Arik Halperin]

Thanks, Issue is solved with double rr

Arik

> On 16 Apr 2018, at 12:13, Federico Cabiddu  wrote:
> 
> Hi,
> your INVITE contains a single Record-Route, with Kamailio's Public IP 
> address. Freewitch in the following in0dialog messages, as the BYE is, will 
> have nowhere else to send them than the public IP.
> If you want FS to send in-dialog messages to the private IP you have to have 
> two Record-Route headers:
> http://www.kamailio.org/docs/modules/devel/modules/rr.html#rr.p.enable_double_rr
>  
> 
> 
> Best regards,
> 
> Federico
> 
> On Mon, Apr 16, 2018 at 11:05 AM, arik halperin  > wrote:
> Hello,
> 
>  
> 
> I have the following setup:
> 
>  
> 
> Kamailio:
> 
>   Public Interface 70.36.25.65
> 
>   Private Interface 10.168.10.227
> 
>  
> 
> Freeswitch:
> 
>Private Interface 10.168.10.200
> 
>  
> 
> I’m routing calls from kamailio to freeswitch, but when I try to hang up the 
> call the freeswitch sends the BYE to the public address(70.36.25.65) and not 
> to the private address 10.168.10.227. 200OK and ACK work correctly. It’s only 
> the BYE that has an issue.
> 
>  
> 
>  
> 
> Showing INVITES:
> 
>  
> 
> Client Invite:
> 
>  
> 
> T 82.80.164.63:53871  -> 70.36.25.65:5099 
>  [AP]
> 
> INVITE sip:+972549428460@70.36.25.65:5099 
>  SIP/2.0.
> 
> Via: SIP/2.0/TCP 
> 10.0.0.42:51619;branch=z9hG4bK-524287-1---52dcc73ec891de14;rport.
> 
> Max-Forwards: 70.
> 
> Contact:  63:51620;rinstance=1f9d21b54116df89;transport=tcp>.
> 
> To:  >.
> 
> From: "972545234585" >;tag=902c5325.
> 
>  
> 
> Kamailio to FS:
> 
>  
> 
> T 10.168.10.227:46506  -> 10.168.10.200:5080 
>  [AP]
> 
> INVITE sip:+972549428460@70.36.25.65:5099 
>  SIP/2.0.
> 
> Record-Route:  ;transport=tcp;lr=on;ftag=902c5325;nat=yes>.
> 
> Via: SIP/2.0/TCP 
> 70.36.25.65:5099;branch=z9hG4bK1117.1b91cfe0632bd6f036b308f85898e862.1;i=1.
> 
> Via: SIP/2.0/TCP 
> 10.0.0.42:51619;received=82.80.164.63;branch=z9hG4bK-524287-1---9b6758521ff0f528;rport=53871.
> 
> Max-Forwards: 69.
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org 
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> 
> 
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



smime.p7s
Description: S/MIME cryptographic signature
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Dialog module's keep-alive feature uses wrong CSeq?

[Dmitri Savolainen]

>
> Ideally I think Kamailio should send correct (i.e increasing) CSeq numbers.
>
in my mind it can't be increased by kamailio because of:
1. kamailio send OPTIONS with cseq+1
2. media server may send some  indialog reinvite with cseq+1 and then
kamailio have to remember that OPTIONS and  translate reinvite to cseq+2.

I don't know why for "ka-src" CSeq is 0 and for "ka-dst"  the one is  equal:
so may be it is possible to be fixed

 (for example BYE) to be dropped by the firewall.

this may be achieved by
1. usrloc pinging
2. short re-registration period for endpoint (60 sec for ex)
3. let's media server send options by itself via kamailio




2018-04-16 15:37 GMT+03:00 Oded Arbel :

>
>
> On Mon, Apr 16, 2018, 14:59 Dmitri Savolainen 
> wrote:
>
>> hi
>>
>> Indeed dialog  OPTIONS are send with wrong CSeq and there is no way to
>> fix it without patching source.
>>
>
>> In docs for dialog module  "If keep alive is enabled for a dialog, the
>> module will send SIP OPTIONS requests with CSeq lower or equal than last
>> request within dialog"
>>
>
> Yes, I've read this - but why?
>
>
> Usually Kamailio is used before some media server (asterisk,
>> freeswitch...):
>> endpoint1 - kamailio leg1   media_server ---leg2 kamailio -
>> endpoint2
>>
>> So if it is your case
>>
>
> This is indeed my case.
>
>
> you want to check if dialog alive, you may ping media server instead of
>> pinging remote endpoints
>>
>
> I don't want to use "keep alive" to *check* if the dialog is alive - I
> want to use "keep alive" to keep the dialog alive, or more precisely: to
> prevent the MUA's NAT from tearing down the port mappings it creates when
> the MUA starts the dialog, for as long as the call is alive.
>
> For that I need to set:
>
> For leg1: dlg_set_propery("ka-src");
> For leg2: dlg_set_property("ka-dst");
>
> And then the MUAs need to be able to respond. Even a 500 error response is
> enough for Kamailio to mark the message as received successfully and to
> keep sending OPTIONS messages, and as I described in my email, this
> sometimes works for "ka-dst", but for "ka-src" Kamailio always sends CSeq 0
> to the MUA - as a result the MUA does not respond, causing Kamailio to
> retry a few times until it gives up, stops sending keep alive messages,
> allowing the NAT to teardown the SIP port mapping causing the next server
> originated message (for example BYE) to be dropped by the firewall.
>
> Ideally I think Kamailio should send correct (i.e increasing) CSeq
> numbers. I think I can submit a patch to fix this, but as the current
> behavior is (more or less) documented I would want to understand why some
> one thought it's a good idea before attempting to change it.
>
>
>>
>> 2018-04-12 23:34 GMT+03:00 Oded Arbel :
>>
>>> Hi all.
>>>
>>> I'm trying to use the dialog module's keep alive feature (ka_interval()
>>> and dlg_set_property()), and the documentation (under dlg_set_property)
>>> says this:
>>>
>>> If keep alive is enabled for a dialog, the module will send SIP OPTIONS
>>> requests with CSeq lower or equal than last request within dialog
>>>
>>> This is seems really weird to me, but the problem is worse than that -
>>> when setting dlg_set_property("ka-src"), the OPTIONS messages sent to
>>> the caller always have CSeq set to "0", regardless of what CSeq the UA sent
>>> on its invite.
>>>
>>> The problem is that while some UAs respond to these purposefully broken
>>> messages with some kind of a 5xx reply (for example, Linphone funnily sends
>>> "500 Internal Server Error"), several UAs don't respond at all. Worse than
>>> that - some of the UAs that send back 5xx replies to OPTIONS with a
>>> non-zero but invalid CSeq will completely ignore the OPTIONS keep-alive
>>> message that is sent to the caller with a CSeq 0 - for example, PJSIP
>>> responds with "503 Invalid CSeq" to a "ka-dst" OPTIONS message but will
>>> ignore a "ka-src" OPTIONS message with CSeq 0.
>>>
>>> My questions:
>>> 1. Why are keep-alive messages sent with a wrong CSeq?
>>> 2. If we're keeping the "wrong CSeq" approach, can we at least not send
>>> CSeq "0"?
>>> 3. Is there a way to change any of the above behaviors with a
>>> configuration (i.e. without patching the sources)?
>>>
>>> Thanks in advance
>>>
>>> --
>>> Oded Arbel
>>> od...@cloudonix.io
>>>
>>>
>>>
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>
>>
>> --
>> Savolainen Dmitri
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> --
>
> Oded Arbel
> oded.ar...@greenfieldtech.net
> [image: Greenfield Tech] 
>
> ___
> Kamailio (SER) - Users Mailing List
> 

Re: [SR-Users] Dialog module's keep-alive feature uses wrong CSeq?

[Oded Arbel]

On Mon, Apr 16, 2018, 14:59 Dmitri Savolainen  wrote:

> hi
>
> Indeed dialog  OPTIONS are send with wrong CSeq and there is no way to
> fix it without patching source.
>

> In docs for dialog module  "If keep alive is enabled for a dialog, the
> module will send SIP OPTIONS requests with CSeq lower or equal than last
> request within dialog"
>

Yes, I've read this - but why?


Usually Kamailio is used before some media server (asterisk, freeswitch...):
> endpoint1 - kamailio leg1   media_server ---leg2 kamailio -
> endpoint2
>
> So if it is your case
>

This is indeed my case.


you want to check if dialog alive, you may ping media server instead of
> pinging remote endpoints
>

I don't want to use "keep alive" to *check* if the dialog is alive - I want
to use "keep alive" to keep the dialog alive, or more precisely: to prevent
the MUA's NAT from tearing down the port mappings it creates when the MUA
starts the dialog, for as long as the call is alive.

For that I need to set:

For leg1: dlg_set_propery("ka-src");
For leg2: dlg_set_property("ka-dst");

And then the MUAs need to be able to respond. Even a 500 error response is
enough for Kamailio to mark the message as received successfully and to
keep sending OPTIONS messages, and as I described in my email, this
sometimes works for "ka-dst", but for "ka-src" Kamailio always sends CSeq 0
to the MUA - as a result the MUA does not respond, causing Kamailio to
retry a few times until it gives up, stops sending keep alive messages,
allowing the NAT to teardown the SIP port mapping causing the next server
originated message (for example BYE) to be dropped by the firewall.

Ideally I think Kamailio should send correct (i.e increasing) CSeq numbers.
I think I can submit a patch to fix this, but as the current behavior is
(more or less) documented I would want to understand why some one thought
it's a good idea before attempting to change it.


>
> 2018-04-12 23:34 GMT+03:00 Oded Arbel :
>
>> Hi all.
>>
>> I'm trying to use the dialog module's keep alive feature (ka_interval()
>> and dlg_set_property()), and the documentation (under dlg_set_property)
>> says this:
>>
>> If keep alive is enabled for a dialog, the module will send SIP OPTIONS
>> requests with CSeq lower or equal than last request within dialog
>>
>> This is seems really weird to me, but the problem is worse than that -
>> when setting dlg_set_property("ka-src"), the OPTIONS messages sent to the
>> caller always have CSeq set to "0", regardless of what CSeq the UA sent on
>> its invite.
>>
>> The problem is that while some UAs respond to these purposefully broken
>> messages with some kind of a 5xx reply (for example, Linphone funnily sends
>> "500 Internal Server Error"), several UAs don't respond at all. Worse than
>> that - some of the UAs that send back 5xx replies to OPTIONS with a
>> non-zero but invalid CSeq will completely ignore the OPTIONS keep-alive
>> message that is sent to the caller with a CSeq 0 - for example, PJSIP
>> responds with "503 Invalid CSeq" to a "ka-dst" OPTIONS message but will
>> ignore a "ka-src" OPTIONS message with CSeq 0.
>>
>> My questions:
>> 1. Why are keep-alive messages sent with a wrong CSeq?
>> 2. If we're keeping the "wrong CSeq" approach, can we at least not send
>> CSeq "0"?
>> 3. Is there a way to change any of the above behaviors with a
>> configuration (i.e. without patching the sources)?
>>
>> Thanks in advance
>>
>> --
>> Oded Arbel
>> od...@cloudonix.io
>>
>>
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
>
> --
> Savolainen Dmitri
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-- 

Oded Arbel
oded.ar...@greenfieldtech.net
[image: Greenfield Tech] 
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Dialog module's keep-alive feature uses wrong CSeq?

[Dmitri Savolainen]

hi

Indeed dialog  OPTIONS are send with wrong CSeq and there is no way to fix
it without patching source.

In docs for dialog module  "If keep alive is enabled for a dialog, the
module will send SIP OPTIONS requests with CSeq lower or equal than last
request within dialog"

Usually Kamailio is used before some media server (asterisk, freeswitch...):
endpoint1 - kamailio leg1   media_server ---leg2 kamailio -
endpoint2

So if it is your case and you want to check if dialog alive, you may ping
media server instead of pinging remote endpoints:
for leg1: dlg_set_property("ka-dst");
for leg2: dlg_set_property("ka-src");

Of course your media server should support this not inaccurate CSeq
handling. I successfully use it with freeswitch for example (with some
minimal freeswitch tuning)






2018-04-12 23:34 GMT+03:00 Oded Arbel :

> Hi all.
>
> I'm trying to use the dialog module's keep alive feature (ka_interval()
> and dlg_set_property()), and the documentation (under dlg_set_property)
> says this:
>
> If keep alive is enabled for a dialog, the module will send SIP OPTIONS
> requests with CSeq lower or equal than last request within dialog
>
> This is seems really weird to me, but the problem is worse than that -
> when setting dlg_set_property("ka-src"), the OPTIONS messages sent to the
> caller always have CSeq set to "0", regardless of what CSeq the UA sent on
> its invite.
>
> The problem is that while some UAs respond to these purposefully broken
> messages with some kind of a 5xx reply (for example, Linphone funnily sends
> "500 Internal Server Error"), several UAs don't respond at all. Worse than
> that - some of the UAs that send back 5xx replies to OPTIONS with a
> non-zero but invalid CSeq will completely ignore the OPTIONS keep-alive
> message that is sent to the caller with a CSeq 0 - for example, PJSIP
> responds with "503 Invalid CSeq" to a "ka-dst" OPTIONS message but will
> ignore a "ka-src" OPTIONS message with CSeq 0.
>
> My questions:
> 1. Why are keep-alive messages sent with a wrong CSeq?
> 2. If we're keeping the "wrong CSeq" approach, can we at least not send
> CSeq "0"?
> 3. Is there a way to change any of the above behaviors with a
> configuration (i.e. without patching the sources)?
>
> Thanks in advance
>
> --
> Oded Arbel
> od...@cloudonix.io
>
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>


-- 
Savolainen Dmitri
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio with 2 Public and Private IPs- SIP Call flow issues

[Federico Cabiddu]

Hi,
your INVITE contains a single Record-Route, with Kamailio's Public IP
address. Freewitch in the following in0dialog messages, as the BYE is, will
have nowhere else to send them than the public IP.
If you want FS to send in-dialog messages to the private IP you have to
have two Record-Route headers:
http://www.kamailio.org/docs/modules/devel/modules/rr.html#rr.p.enable_double_rr

Best regards,

Federico

On Mon, Apr 16, 2018 at 11:05 AM, arik halperin 
wrote:

> Hello,
>
>
>
> I have the following setup:
>
>
>
> Kamailio:
>
>   Public Interface 70.36.25.65
>
>   Private Interface 10.168.10.227
>
>
>
> Freeswitch:
>
>Private Interface 10.168.10.200
>
>
>
> I’m routing calls from kamailio to freeswitch, but when I try to hang up
> the call the freeswitch sends the BYE to the public address(70.36.25.65)
> and not to the private address 10.168.10.227. 200OK and ACK work correctly.
> It’s only the BYE that has an issue.
>
>
>
>
>
> Showing INVITES:
>
>
>
> Client Invite:
>
>
>
> T 82.80.164.63:53871 -> 70.36.25.65:5099 [AP]
>
> INVITE sip:+972549428460@70.36.25.65:5099 SIP/2.0.
>
> Via: SIP/2.0/TCP 10.0.0.42:51619;branch=z9hG4bK-524287-1---
> 52dcc73ec891de14;rport.
>
> Max-Forwards: 70.
>
> Contact:  1f9d21b54116df89;transport=tcp>.
>
> To: .
>
> From: "972545234585";tag=902c5325.
>
>
>
> Kamailio to FS:
>
>
>
> T 10.168.10.227:46506 -> 10.168.10.200:5080 [AP]
>
> INVITE sip:+972549428460@70.36.25.65:5099 SIP/2.0.
>
> Record-Route:  902c5325;nat=yes>.
>
> Via: SIP/2.0/TCP 70.36.25.65:5099;branch=z9hG4bK1117.
> 1b91cfe0632bd6f036b308f85898e862.1;i=1.
>
> Via: SIP/2.0/TCP 10.0.0.42:51619;received=82.80.164.63;branch=z9hG4bK-
> 524287-1---9b6758521ff0f528;rport=53871.
>
> Max-Forwards: 69.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Kamailio with 2 Public and Private IPs- SIP Call flow issues

[arik halperin]

Hello,

 

I have the following setup:

 

 Kamailio:

  Public Interface 70.36.25.65

  Private Interface 10.168.10.227

 

Freeswitch:

   Private Interface 10.168.10.200

 

I’m routing calls from kamailio to freeswitch, but when I try to hang up the 
call the freeswitch sends the BYE to the public address(70.36.25.65) and not to 
the private address 10.168.10.227. 200OK and ACK work correctly. It’s only the 
BYE that has an issue.

 

 

Showing INVITES:

 

Client Invite:

 

T 82.80.164.63:53871 -> 70.36.25.65:5099 [AP]

INVITE sip:+972549428460@70.36.25.65:5099 SIP/2.0.

Via: SIP/2.0/TCP 
10.0.0.42:51619;branch=z9hG4bK-524287-1---52dcc73ec891de14;rport.

Max-Forwards: 70.

Contact: 
.

To: .

From: "972545234585";tag=902c5325.

 

Kamailio to FS:

 

T 10.168.10.227:46506 -> 10.168.10.200:5080 [AP]

INVITE sip:+972549428460@70.36.25.65:5099 SIP/2.0.

Record-Route: .

Via: SIP/2.0/TCP 
70.36.25.65:5099;branch=z9hG4bK1117.1b91cfe0632bd6f036b308f85898e862.1;i=1.

Via: SIP/2.0/TCP 
10.0.0.42:51619;received=82.80.164.63;branch=z9hG4bK-524287-1---9b6758521ff0f528;rport=53871.

Max-Forwards: 69.

 

 

 

 

 

 

 

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users