Hi Shankar,
I will setup and test case and try to reproduce as soon as I can. I suspect
I will be able to get back to you early next week only
Cheers
Jason
On Thu, Jan 23, 2014 at 8:48 AM, Shankar <shankar.rk(a)plintron.com> wrote:
> Hi,
>
>
>
> From our repeated load tests what we can conclude irrespective of the
> number of simultaneous calls, there is always this error “t_continue:
> transaction not found” occurring.
>
>
>
> If I run say 20 cps, then after running 5000 calls, we observe exactly 20
> calls failing with the above error. We doubt that there is something
> happening during a particular point in time (for a second) which impacts
> the saving of those new transactions into shared memory.
>
>
>
> For 10 cps run, we observe exactly 10 call failures. We repeated with
> different cps and found that error is exactly equal to the cps being run.
>
>
>
> Any configuration we are missing. Anyone can help?
>
>
>
> Regards,
>
> Shankar
>
>
>
> *From:* Shankar [mailto:shankar.rk@plintron.com]
> *Sent:* Tuesday, January 21, 2014 3:09 PM
> *To:* 'Jason Penton'; 'SIP Router - Kamailio (OpenSER) and SIP Express
> Router (SER) - Users Mailing List'
> *Subject:* FW: [SR-Users] FW: Regd. t_suspend() and t_continue()
>
>
>
> Hi Jason,
>
>
>
> Below is our config,
>
>
>
> route[LOCATION] {
>
> if(is_method("INVITE"))
>
> {
>
> if(!route(FROMCSCF))
>
> {
>
> setflag(FLT_ACC);
>
> setflag(FLT_ACCFAILED);
>
> dlg_manage();
>
> dlg_setflag("4");
>
>
>
> async_route("RESUME", "1");
>
>
>
> exit;
>
> }
>
> }
>
> }
>
>
>
> route[RESUME]
>
> {
>
> route(TO_LOCATION); // here t_relay to REGISTRAR is
> done for user lookup.
>
> exit;
>
> }
>
>
>
> Regards,
>
> Shankar
>
>
>
>
>
> Date: Tue, 21 Jan 2014 11:14:21 +0200
>
> From: Jason Penton <jason.penton(a)smilecoms.com>
>
> To: "Kamailio (SER) - Users Mailing List"
>
> <sr-users(a)lists.sip-router.org>
>
> Subject: Re: [SR-Users] FW: Regd. t_suspend() and t_continue()
>
> Message-ID:
>
> <CAE=KcrghqJHgnGDxqS1fYvUzM=HqRAcKWfEAsNJjm8xUDCq68w(a)mail.gmail.com>
>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>
> We use it heavily, but not using the async module - we use it directly
> from the IMS code.
>
>
>
> Can you please provide your config (or a relevant snippet) file so I can
> see what exactly you are testing/trying to do
>
>
>
> Cheers
>
> jason
>
>
>
> *From:* Shankar [mailto:shankar.rk@plintron.com <shankar.rk(a)plintron.com>]
>
> *Sent:* Tuesday, January 21, 2014 2:25 PM
> *To:* 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
> Users Mailing List'
> *Subject:* RE: [SR-Users] FW: Regd. t_suspend() and t_continue()
>
>
>
> Hi,
>
>
>
> Anyone who had used t_suspend() and t_continue() can share the performance
> details?
>
>
>
> I tried async module with one sec sleep time. I tried only 5 calls per
> second but still it was not successful. After sometime I see below logs,
>
>
>
> Jan 21 13:51:55 PLT-RA-RD-W167A PCscf[16520]: ERROR: tm [t_suspend.c:128]:
> t_continue(): ERROR: t_continue: transaction not found
>
> Jan 21 13:52:49 PLT-RA-RD-W167A last message repeated 15 times
>
> Jan 21 13:59:38 PLT-RA-RD-W167A last message repeated 12 times
>
> Jan 21 14:13:03 PLT-RA-RD-W167A last message repeated 5 times
>
>
>
> Any configuration changes can help here?
>
>
>
> Regards,
>
> Shankar
>
>
>
> *From:* Shankar [mailto:shankar.rk@plintron.com <shankar.rk(a)plintron.com>]
>
> *Sent:* Wednesday, January 15, 2014 1:26 PM
> *To:* 'Jason Penton'
> *Cc:* 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
> Users Mailing List'
> *Subject:* RE: [SR-Users] FW: Regd. t_suspend() and t_continue()
>
>
>
> Hi Jason,
>
>
>
> I am using 4.0.2
>
>
>
> Regards,
>
> Shankar
>
>
>
> *From:* Jason Penton [mailto:jason.penton@smilecoms.com<jason.penton(a)smilecoms.com>]
>
> *Sent:* Wednesday, January 15, 2014 1:21 PM
> *To:* Shankar
> *Cc:* SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
> Users Mailing List
> *Subject:* Re: [SR-Users] FW: Regd. t_suspend() and t_continue()
>
>
>
> Hi Shankar,
>
>
>
> What version of Kamailio are you running? Kamailio -V
>
>
>
> Cheers
>
> Jason
>
>
>
> On Wed, Jan 15, 2014 at 6:58 AM, Shankar <shankar.rk(a)plintron.com> wrote:
>
> Hi Jason,
>
>
>
> Please find below my response inline,
>
>
>
>
>
> I have some questions for you as we have used suspend/continue quite a lot
> in the IMS code and don't have any leaks.
>
>
>
> Firstly, why are you using pkg_mem for your hash_id and label? Remember
> that you will be in 2 different processes in the suspend and continue
> portions of the code... so pkg_mem will not work - you should use shm_mem
> instead.
>
>
>
> [Shankar] We use pkg_mem because we are invoking t_continue from the same
> process ( using thread ).
>
>
>
> Secondly, how are you using top to tell that you have a leak? Kamailio's
> memory is internally managed.
>
>
>
> [Shankar] After running for say 20minutes, we get out of shared memory
> error. Also in top output we observed incremental increase in the shared
> usage of shared memory for the process.
>
>
>
> Cheers
>
> Jason
>
>
>
>
>
> On Mon, Jan 13, 2014 at 1:29 PM, Shankar <shankar.rk(a)plintron.com> wrote:
>
>
>
> > Re-sending without the attachment.
>
> >
>
> >
>
> >
>
> > *From:* Shankar [mailto:shankar.rk@plintron.com<shankar.rk(a)plintron.com>
> ]
>
> > *Sent:* Monday, January 13, 2014 4:57 PM
>
> > *To:* 'sr-users(a)lists.sip-router.org'
>
> > *Subject:* Regd. t_suspend() and t_continue()
>
> >
>
> >
>
> >
>
> > Hi,
>
> >
>
> >
>
> >
>
> > We are trying out the t_suspend() and t_continue() in our test setup.
>
> > We are facing memory leak ( both shm and pkg as per top command results).
>
> >
>
> >
>
> >
>
> > Please find below the scenario,
>
> >
>
> >
>
> >
>
> > 1) Do a t_newtran()
>
> >
>
> > 2) Allocate pkg memory for hashid and label.
>
> >
>
> > 3) Call t_suspend()
>
> >
>
> > 4) Do t_continue() when async result is available
>
> >
>
> > 5) De-allocate pkg memory reserved for hashid and label
>
> >
>
> > 6) Do a t_relay() which forwards the sip message to another sip
> node.
>
> >
>
> >
>
> >
>
> > In the step (6) above, we see t_newtran() allocates one more time
>
> > shared memory for the same transaction.
>
> >
>
> >
>
> >
>
> > We tried t_release() after step (4) to release the transaction as
>
> > t_relay() anyways allocates new shared memory. Nothing helped.
>
> >
>
> >
>
> >
>
> > Please let me know what are the logs you would require to debug the same.
>
> > I am attaching syslog for this run.
>
> >
>
> >
>
> >
>
> > Regards,
>
> >
>
> > Shankar
>
>
>
>
>
>
>
> --
>
>
>
> *Jason Penton*
>
> *Senior Manager: Applications and Services*
>
> *Smile Communications Pty (Ltd)*
>
> *Mobile:*
>
> +27 (0) 83 283 7000
>
> *Skype:*
>
> jason.barry.penton
>
> jason.penton(a)smilecoms.com <name.surname(a)smilecoms.com>
>
> www.smilecoms.com
>
>
>
> This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/disclaimer
>
>
>
>
>
>
>
>
--
*Jason Penton**Senior Manager: Applications and Services**Smile
Communications Pty (Ltd)**Mobile:*+27 (0) 83 283 7000*Skype:*
jason.barry.pentonjason.penton(a)smilecoms.com <name.surname(a)smilecoms.com>
www.smilecoms.com
This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/disclaimer
Hello,
can you give the output in gdb for:
bt full
Also, do you have 'listen' parameters or kamailio is listening on all
interfaces?
It is recommended to upgrade to latest version 4.0.x, to be sure there
is not a side effect of a fixed issues.
Cheers,
Daniel
On 17/01/14 13:50, Surendra wrote:
> Hi,
>
> We are facing a core issue in 4.0.2 version. Please find the GDB
> trace below
>
> #0 udp_rcv_loop () at udp_server.c:471
> 471 fromlen=sockaddru_len(bind_address->su);
> (gdb) bt
> #0 udp_rcv_loop () at udp_server.c:471
> #1 0x0000000000475c14 in main_loop () at main.c:1851
> #2 0x000000000047a98b in main (argc=<value optimized out>,
> argv=<value optimized out>) at main.c:2939
>
>
> We have simulated this so many times in load mode.
> Machine details: Linux PLT-RA-RD-W167A.localdomain 2.6.18-308.el5 #1
> SMP Fri Jan 27 17:17:51 EST 2012 x86_64 x86_64 x86_64 GNU/Linux
>
> Can anyone help me on this
>
>
> Regards
> Surendra
>
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hi,
Thanks for the replies so far, good news is I got it working by switching
off mhomed (mhomed=0). However this seems to have broken my dispatcher as
the SIP OPTIONS probing is being sent from the wrong interface!
Any ideas how to set where dispatcher sends these from??
Cheers
Keith
Hello Klaus,
I have changed the rtpproxy_manage() in the route(NATMANAGE) to no avail. The c= in the Invite that arrives to Asterisk still points to the public IP of the Phone1.
Code is as follows:
route[NATMANAGE] {
#!ifdef WITH_NAT
if (is_request()) {
if(has_totag()) {
if(check_route_param("nat=yes")) {
setbflag(FLB_NATB);
}
}
}
if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB)))
return;
if (src_ip == ip.pbx.priva.te) {
rtpproxy_manage();
} else {
rtpproxy_manage("","ip.kamailio.priva.te");
}
if (is_request()) {
if (!has_totag()) {
add_rr_param(";nat=yes");
}
}
if (is_reply()) {
if(isbflagset(FLB_NATB)) {
fix_nated_contact();
}
}
The next test has been to comment out the rtpproxy_manage at NATMANAGE function and to put it both at route[RELAY] and onreply(route) following your post in this list from January 2013: http://lists.sip-router.org/pipermail/sr-users/2013-January/076254.html.
Now the media flows from Phone1 to Kamailio, from Kamailio to Asterisk and back, but it gets stuck at Kamailio. I cannot see it flow towards the public IP of the Phone2.
The force_send_socket you used could be of any use here?
Thank you
> ----- Original Message -----
> From: Klaus Darilion
> Sent: 01/21/14 07:25 AM
> To: Kamailio (SER) - Users Mailing List
> Subject: Re: [SR-Users] Kamailio behind NAT
>
> Yes, when calling rtpproxy (whatever function you use,
> manage/offer/answer/force), every function accepts as second parameter
> the IP address which should be written into the SDP c=... line.
>
> So, detect the direction (eg based on source-ip) and put the respective
> internal or external IP address into the SDP.
>
> Of course the NAT must be a static 1:1 NAT without any PAT.
>
> Btw: you have the same problem with some SIP headers, like Record-Route
> or Via. Kamailio has to insert the respective public/private IP,
> depending on where to send the message. If Kamailio uses only a single
> socket, then you have to do this manually. The automatic approach is to
> configure 2 listen=... sockets. One for the internal side, and one for
> the external side. On the "external" socket you add the "advertise"
> option - then Kamailio will automatically put the correct IP addresses
> in RR and Via, eg:
>
> # public IP address of Kamailio/rtpproxy: 3.3.3.3
> # internal socket
> listen=udp:10.10.0.2
> # external socket
> listen=udp:10.10.0.3 advertise 3.3.3.3:5060
> mhomed=0
>
> You could use separate subnets for the 2 sockets, or you could also use
> only a single IP address with 2 different ports for the 2 sockets.
>
>
> regards
> Klaus
>
>
> On 21.01.2014 14:50, John Smith wrote:
> > The intended setup is as you described in option a.
> >
> > And the behaviour of rewriting SDP using private/public ports is what I understood the rtpproxy_manage was tasked to do.
> >
> > As it is not working the way I expected, what is the best way to proceed? To check if the IP is from the outside and then rewrite via rtpproxy_offer in the NATMANAGE block?
> >
> > Thank you
> >
> >> ----- Original Message -----
> >> From: Klaus Darilion
> >> Sent: 01/21/14 05:25 AM
> >> To: Kamailio (SER) - Users Mailing List
> >> Subject: Re: [SR-Users] Kamailio behind NAT
> >>
> >> On 21.01.2014 13:24, John Smith wrote:
> >>> I might be making wrong assumptions regarding this traffic flow. Is that correct?
> >>
> >> That depends on your policy. It is up to you to define how RTP should be
> >> routed. There are basically 2 choices:
> >>
> >> a) RTP from clients is handled by rtpproxy:
> >>
> >> phone1 <-nat-> rtpproxy <--> Asterisk <--> rtpproxy <-nat-> phone2
> >>
> >> In this case, only the private IP of Kamailio and rtpproxy (can be the
> >> same IP address) must be mapped to a public IP address.
> >>
> >>
> >> b) RTP directly to Asterisk:
> >>
> >> phone1 <-nat-> Asterisk <-nat-> phone2
> >>
> >> In this case, the private IPs of Kamailio and Asterisk must be mapped to
> >> a public IP address.
> >>
> >>
> >> When using version a) you have to make sure to set the proper IP address
> >> in the SDP. For example, SDPs in messages from Kamailio to the phone
> >> must contains the PUBLIC IP of rtpproxy in the c=... line. SDPs in
> >> messages from Kamailio to Asterisk must contain the PRIVATE IP of
> >> rtpproxy in the c=... line.
> >>
> >> regards
> >> Klaus
> >>
> >> _______________________________________________
> >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> >> sr-users(a)lists.sip-router.org
> >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >
> >
> > _______________________________________________
> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> > sr-users(a)lists.sip-router.org
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi,
>From our repeated load tests what we can conclude irrespective of the number
of simultaneous calls, there is always this error "t_continue: transaction
not found" occurring.
If I run say 20 cps, then after running 5000 calls, we observe exactly 20
calls failing with the above error. We doubt that there is something
happening during a particular point in time (for a second) which impacts the
saving of those new transactions into shared memory.
For 10 cps run, we observe exactly 10 call failures. We repeated with
different cps and found that error is exactly equal to the cps being run.
Any configuration we are missing. Anyone can help?
Regards,
Shankar
From: Shankar [mailto:shankar.rk@plintron.com]
Sent: Tuesday, January 21, 2014 3:09 PM
To: 'Jason Penton'; 'SIP Router - Kamailio (OpenSER) and SIP Express Router
(SER) - Users Mailing List'
Subject: FW: [SR-Users] FW: Regd. t_suspend() and t_continue()
Hi Jason,
Below is our config,
route[LOCATION] {
if(is_method("INVITE"))
{
if(!route(FROMCSCF))
{
setflag(FLT_ACC);
setflag(FLT_ACCFAILED);
dlg_manage();
dlg_setflag("4");
async_route("RESUME", "1");
exit;
}
}
}
route[RESUME]
{
route(TO_LOCATION); // here t_relay to REGISTRAR is done
for user lookup.
exit;
}
Regards,
Shankar
Date: Tue, 21 Jan 2014 11:14:21 +0200
From: Jason Penton <jason.penton(a)smilecoms.com>
To: "Kamailio (SER) - Users Mailing List"
<sr-users(a)lists.sip-router.org>
Subject: Re: [SR-Users] FW: Regd. t_suspend() and t_continue()
Message-ID:
<CAE=KcrghqJHgnGDxqS1fYvUzM=HqRAcKWfEAsNJjm8xUDCq68w(a)mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
We use it heavily, but not using the async module - we use it directly from
the IMS code.
Can you please provide your config (or a relevant snippet) file so I can see
what exactly you are testing/trying to do
Cheers
jason
From: Shankar [mailto:shankar.rk@plintron.com]
Sent: Tuesday, January 21, 2014 2:25 PM
To: 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users
Mailing List'
Subject: RE: [SR-Users] FW: Regd. t_suspend() and t_continue()
Hi,
Anyone who had used t_suspend() and t_continue() can share the performance
details?
I tried async module with one sec sleep time. I tried only 5 calls per
second but still it was not successful. After sometime I see below logs,
Jan 21 13:51:55 PLT-RA-RD-W167A PCscf[16520]: ERROR: tm [t_suspend.c:128]:
t_continue(): ERROR: t_continue: transaction not found
Jan 21 13:52:49 PLT-RA-RD-W167A last message repeated 15 times
Jan 21 13:59:38 PLT-RA-RD-W167A last message repeated 12 times
Jan 21 14:13:03 PLT-RA-RD-W167A last message repeated 5 times
Any configuration changes can help here?
Regards,
Shankar
From: Shankar [mailto:shankar.rk@plintron.com]
Sent: Wednesday, January 15, 2014 1:26 PM
To: 'Jason Penton'
Cc: 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users
Mailing List'
Subject: RE: [SR-Users] FW: Regd. t_suspend() and t_continue()
Hi Jason,
I am using 4.0.2
Regards,
Shankar
From: Jason Penton [mailto:jason.penton@smilecoms.com]
Sent: Wednesday, January 15, 2014 1:21 PM
To: Shankar
Cc: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users
Mailing List
Subject: Re: [SR-Users] FW: Regd. t_suspend() and t_continue()
Hi Shankar,
What version of Kamailio are you running? Kamailio -V
Cheers
Jason
On Wed, Jan 15, 2014 at 6:58 AM, Shankar <shankar.rk(a)plintron.com> wrote:
Hi Jason,
Please find below my response inline,
I have some questions for you as we have used suspend/continue quite a lot
in the IMS code and don't have any leaks.
Firstly, why are you using pkg_mem for your hash_id and label? Remember that
you will be in 2 different processes in the suspend and continue portions of
the code... so pkg_mem will not work - you should use shm_mem instead.
[Shankar] We use pkg_mem because we are invoking t_continue from the same
process ( using thread ).
Secondly, how are you using top to tell that you have a leak? Kamailio's
memory is internally managed.
[Shankar] After running for say 20minutes, we get out of shared memory
error. Also in top output we observed incremental increase in the shared
usage of shared memory for the process.
Cheers
Jason
On Mon, Jan 13, 2014 at 1:29 PM, Shankar <shankar.rk(a)plintron.com> wrote:
> Re-sending without the attachment.
>
>
>
> *From:* Shankar [mailto:shankar.rk@plintron.com]
> *Sent:* Monday, January 13, 2014 4:57 PM
> *To:* 'sr-users(a)lists.sip-router.org'
> *Subject:* Regd. t_suspend() and t_continue()
>
>
>
> Hi,
>
>
>
> We are trying out the t_suspend() and t_continue() in our test setup.
> We are facing memory leak ( both shm and pkg as per top command results).
>
>
>
> Please find below the scenario,
>
>
>
> 1) Do a t_newtran()
>
> 2) Allocate pkg memory for hashid and label.
>
> 3) Call t_suspend()
>
> 4) Do t_continue() when async result is available
>
> 5) De-allocate pkg memory reserved for hashid and label
>
> 6) Do a t_relay() which forwards the sip message to another sip node.
>
>
>
> In the step (6) above, we see t_newtran() allocates one more time
> shared memory for the same transaction.
>
>
>
> We tried t_release() after step (4) to release the transaction as
> t_relay() anyways allocates new shared memory. Nothing helped.
>
>
>
> Please let me know what are the logs you would require to debug the same.
> I am attaching syslog for this run.
>
>
>
> Regards,
>
> Shankar
--
Jason Penton
Senior Manager: Applications and Services
Smile Communications Pty (Ltd)
Mobile:
+27 (0) 83 283 7000
Skype:
jason.barry.penton
<mailto:name.surname@smilecoms.com> jason.penton(a)smilecoms.com
<http://www.smilecoms.com/> www.smilecoms.com
<http://196.33.227.129/~smlcoms/sigs/pty/images/smile_signature_07_09.jpg>
This email is subject to the disclaimer of Smile Communications at
http://www.smilecoms.com/disclaimer
Hi all
Question about an additional cdr information.
We need to get the pdd value - means a time value till the user gets a ringback or an error- to track the delay, till a connection is done --> quality issue for customer.
5.6.1 Definition of Post Dial Delay
Post Dial Delay (PDD) is experienced by the originating customer as the time from the sending of the final dialled digit to the point at which they hear ring tone or other in-band information. Where the originating network is required to play an announcement before completing the call then this definition of PDD excludes the duration of such announcements.
How can this be done in Kamailio?
We use the carrierroute module with different fallback carriers.
Kamailio version 3.3.5
Thanks in advance
Oli
Hi All,
Thanks for all the advice, I managed to sort this one (I hope!). For anyone
else interested I had to add some code at the start of the routing to look
for a SIP UPDATE request. If it was a request then to set the $fs (forced
socket) value to equal $Ri (Received interface) value.
Once this was set it now holds the call open for longer than 30 seconds,
fingers crossed it's all good!
Thanks again, hope this is of some help to someone else.
Keith
The intended setup is as you described in option a.
And the behaviour of rewriting SDP using private/public ports is what I understood the rtpproxy_manage was tasked to do.
As it is not working the way I expected, what is the best way to proceed? To check if the IP is from the outside and then rewrite via rtpproxy_offer in the NATMANAGE block?
Thank you
> ----- Original Message -----
> From: Klaus Darilion
> Sent: 01/21/14 05:25 AM
> To: Kamailio (SER) - Users Mailing List
> Subject: Re: [SR-Users] Kamailio behind NAT
>
> On 21.01.2014 13:24, John Smith wrote:
> > I might be making wrong assumptions regarding this traffic flow. Is that correct?
>
> That depends on your policy. It is up to you to define how RTP should be
> routed. There are basically 2 choices:
>
> a) RTP from clients is handled by rtpproxy:
>
> phone1 <-nat-> rtpproxy <--> Asterisk <--> rtpproxy <-nat-> phone2
>
> In this case, only the private IP of Kamailio and rtpproxy (can be the
> same IP address) must be mapped to a public IP address.
>
>
> b) RTP directly to Asterisk:
>
> phone1 <-nat-> Asterisk <-nat-> phone2
>
> In this case, the private IPs of Kamailio and Asterisk must be mapped to
> a public IP address.
>
>
> When using version a) you have to make sure to set the proper IP address
> in the SDP. For example, SDPs in messages from Kamailio to the phone
> must contains the PUBLIC IP of rtpproxy in the c=... line. SDPs in
> messages from Kamailio to Asterisk must contain the PRIVATE IP of
> rtpproxy in the c=... line.
>
> regards
> Klaus
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Using advertised IP address in manage_rttproxy would work with unpatched rtpproxy?
Thank you
> ----- Original Message -----
> From: Klaus Darilion
> Sent: 01/21/14 05:18 AM
> To: Kamailio (SER) - Users Mailing List
> Subject: Re: [SR-Users] Kamailio behind NAT
>
> On 21.01.2014 12:27, Fred Posner wrote:
> > With a patched version of rtpproxy you can advertise your private ip.
> >
> > http://www.fredposner.com/voip/1457/kamailio-behind-nat/
>
> Aha, nice. Haven't known of this one.
>
> I always specified the "adverstised IP address" when calling
> manage_rtpproxy(). That should work too.
>
> regards
> Klaus
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello Kostas,
the idea is to hide the Asterisk completely behind Kamailio, so I work only with the public IP of Kamailio and its SIP/RTP ports.
There are no Asterisk RTP ports enabled, while the Kamailio RTP are already open.
Thank you
> ----- Original Message -----
> From: meres
> Sent: 01/21/14 05:06 AM
> To: Kamailio (SER) - Users Mailing List
> Subject: Re: [SR-Users] Kamailio behind NAT
>
> Hi John,
>
> rtpproxy is not enough if you are using asterisk in your environment.
> You have to check that asterisk is configured to work with NAT, otherwise you will experience audio problems.
> Are the asterisk RTP ports enabled/forwarded on your firewall?
>
> Regards,
>
> Kostas
>
> On Jan 21, 2014, at 2:24 PM, John Smith <jsmith.15(a)mail.com> wrote:
>
> > Hi Fred,
> >
> > I have followed your HOWTO and the scenario remains exactly the same.
> >
> > I see traffic from Phone1 IP to Kamailio private IP, from Kamailio private IP to Asterisk IP, and back directly to Phone2 public IP.
> >
> > I might be making wrong assumptions regarding this traffic flow. Is that correct?
> >
> > Thank you
> >
> > _______________________________________________
> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> > sr-users(a)lists.sip-router.org
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
