16 Jul
2014
16 Jul
'14
9:39 p.m.
Hi,
I have a simple kamailio install (2 servers, using location service and
a failover node with dispatcher, STUN, clients behind different NATs),
without rtpproxy, only peer-to-peer RTP and TURN server if the
connection is really messy (it's not relevant here). Signaling is over
TLS. Both of the clients are behind NAT.
Basically everything works, but some of the calls are dropped after 15
minutes and some seconds, for me it seems the RTP connection is dropped
but not sure.
I cannot find find out wether it's a kamailio problem or client/NAT problem.
Has anyone idea what is going on?
Thanks,
Andras
16 Jul
16 Jul
10:54 p.m.
New subject: Some of the calls drops after 15 minutes + some seconds
Hello,
I expect that the signaling is ok at least for call setup.
From signling point of view, I can think of following situations:
- endpoints send keep alive packets (or session updates) which are no
answered. You can add an xlog(...) at the top of request_route{} and
reply_route{} blocks printing at least the method, call-id, cseq, from
and to header, plus the response code for reply block. In this case you
can see if there is some signaling before call is dropped.
- the tls connection is cut (can be done by routers in the middle) and
one endpoint disconnects the call instead of trying first to reconnect
If none of the above is the case, then might be some problem with rtp
transmission and call is disconnected by a device because of that.
Cheers,
Daniel
On 16/07/14 20:39, Andras FOGARASI wrote:
Hi,
I have a simple kamailio install (2 servers, using location service and
a failover node with dispatcher, STUN, clients behind different NATs),
without rtpproxy, only peer-to-peer RTP and TURN server if the
connection is really messy (it's not relevant here). Signaling is over
TLS. Both of the clients are behind NAT.
Basically everything works, but some of the calls are dropped after 15
minutes and some seconds, for me it seems the RTP connection is dropped
but not sure.
I cannot find find out wether it's a kamailio problem or client/NAT problem.
Has anyone idea what is going on?
Thanks,
Andras
_______________________________________________
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.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
11 p.m.
New subject: Some of the calls drops after 15 minutes + some seconds
On Jul 16, 2014, at 3:54 PM, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
Hello,
I expect that the signaling is ok at least for call setup.
From signling point of view, I can think of following situations:
- endpoints send keep alive packets (or session updates) which are no answered. You can
add an xlog(...) at the top of request_route{} and reply_route{} blocks printing at least
the method, call-id, cseq, from and to header, plus the response code for reply block. In
this case you can see if there is some signaling before call is dropped.
Is this happening just on calls between two phones in your domain, or is there a
carrier/federation involved?
--FC
11:05 p.m.
New subject: Some of the calls drops after 15 minutes + some seconds
On 7/16/14, 10:00 PM, Frank Carmickle wrote:
On Jul 16, 2014, at 3:54 PM, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
No other parties are involved, only the two phones involved (and the
proxy of course).
Andras
Hello,
I expect that the signaling is ok at least for call setup.
From signling point of view, I can think of following situations:
- endpoints send keep alive packets (or session updates) which are no answered. You can
add an xlog(...) at the top of request_route{} and reply_route{} blocks printing at least
the method, call-id, cseq, from and to header, plus the response code for reply block. In
this case you can see if there is some signaling before call is dropped.
Is this happening just on calls between two phones in your domain, or is there a
carrier/federation involved?
17 Jul
17 Jul
4:41 p.m.
New subject: Some of the calls drops after 15 minutes + some seconds
On Jul 16, 2014, at 4:05 PM, Andras FOGARASI <fogarasi(a)fogarasi.com> wrote:
On 7/16/14, 10:00 PM, Frank Carmickle wrote:
I would expect that if it was a NAT issue you would see it much sooner than 15 minutes,
30-60 seconds. Are session timers being stripped by Kamailio? You say it's a TURN
server or is it acting more like a media relay where it is signaled into the path? What
TURN server are you using? How is it configured?
--FC
On Jul 16, 2014, at 3:54 PM, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
No other parties are involved, only the two phones involved (and the
proxy of course).
Hello,
I expect that the signaling is ok at least for call setup.
From signling point of view, I can think of following situations:
- endpoints send keep alive packets (or session updates) which are no answered. You can
add an xlog(...) at the top of request_route{} and reply_route{} blocks printing at least
the method, call-id, cseq, from and to header, plus the response code for reply block. In
this case you can see if there is some signaling before call is dropped.
Is this happening just on calls between two phones in your domain, or is there a
carrier/federation involved?
6:27 p.m.
New subject: Some of the calls drops after 15 minutes + some seconds
On 7/17/14, 3:41 PM, Frank Carmickle wrote:
On Jul 16, 2014, at 4:05 PM, Andras FOGARASI <fogarasi(a)fogarasi.com> wrote:
The problem occurs even without TURN, in pure peer-to-peer mode. We use
TURN only in emergency case (symmetric NAT and like that...). I do
nothing with session timers - i didn't think about it until now...
Andras
On 7/16/14, 10:00 PM, Frank Carmickle wrote:
I would expect that if it was a NAT issue you would see it much sooner than 15 minutes,
30-60 seconds. Are session timers being stripped by Kamailio? You say it's a TURN
server or is it acting more like a media relay where it is signaled into the path? What
TURN server are you using? How is it configured?
On Jul 16, 2014, at 3:54 PM, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:
No other parties are involved, only the two phones involved (and the
proxy of course).
Hello,
I expect that the signaling is ok at least for call setup.
From signling point of view, I can think of following situations:
- endpoints send keep alive packets (or session updates) which are no answered. You can
add an xlog(...) at the top of request_route{} and reply_route{} blocks printing at least
the method, call-id, cseq, from and to header, plus the response code for reply block. In
this case you can see if there is some signaling before call is dropped.
Is this happening just on calls between two phones in your domain, or is there a
carrier/federation involved?
6:34 p.m.
New subject: Some of the calls drops after 15 minutes + some seconds
On Jul 17, 2014, at 11:27 AM, Andras FOGARASI <fogarasi(a)fogarasi.com> wrote:
On 7/17/14, 3:41 PM, Frank Carmickle wrote:
How do you set up the TURN only in emergency case? Do the phones do it themselves? Does
Kamailio control the TURN, rtpengine/mediaproxy-ng?
Who sends the bye?
--FC
I would expect that if it was a NAT issue you
would see it much sooner than 15 minutes, 30-60 seconds. Are session timers being
stripped by Kamailio? You say it's a TURN server or is it acting more like a media
relay where it is signaled into the path? What TURN server are you using? How is it
configured?
The problem occurs even without TURN, in pure peer-to-peer mode. We use
TURN only in emergency case (symmetric NAT and like that...). I do
nothing with session timers - i didn't think about it until now…
9:56 p.m.
New subject: Some of the calls drops after 15 minutes + some seconds
On 7/17/14, 5:34 PM, Frank Carmickle wrote:
On Jul 17, 2014, at 11:27 AM, Andras FOGARASI <fogarasi(a)fogarasi.com> wrote:
Caller send BYE as i see.
Meanwhile i made some debug: after 15 minutes an UPDATE comes. Sometimes
the UPDATE is answered with 200 OK, then the call doesn't drop,
continues and everything works as expected. Sometimes it's not answered
at all (it seems timeout), then hangs up.
Andras
On 7/17/14, 3:41 PM, Frank Carmickle wrote:
How do you set up the TURN only in emergency case? Do the phones do it themselves? Does
Kamailio control the TURN, rtpengine/mediaproxy-ng?
Who sends the bye?
I would expect that if it was a NAT issue you
would see it much sooner than 15 minutes, 30-60 seconds. Are session timers being
stripped by Kamailio? You say it's a TURN server or is it acting more like a media
relay where it is signaled into the path? What TURN server are you using? How is it
configured?
The problem occurs even without TURN, in pure peer-to-peer mode. We use
TURN only in emergency case (symmetric NAT and like that...). I do
nothing with session timers - i didn't think about it until now…
18 Jul
18 Jul
10:16 a.m.
New subject: Some of the calls drops after 15 minutes + some seconds
On 17/07/14 20:56, Andras FOGARASI wrote:
On 7/17/14, 5:34 PM, Frank Carmickle wrote:
Is the UPDATE forwarded from the proxy? Can you see some activity on the
network? Maybe you can run kamailio with debug=3 in cfg and get more log
messages from there that can provide further hints.
Also, you can try to run over tcp to see if it reproduces in the same way.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
On Jul 17, 2014, at 11:27 AM, Andras FOGARASI
<fogarasi(a)fogarasi.com> wrote:
Caller send BYE as i see.
Meanwhile i made some debug: after 15 minutes an UPDATE comes. Sometimes
the UPDATE is answered with 200 OK, then the call doesn't drop,
continues and everything works as expected. Sometimes it's not answered
at all (it seems timeout), then hangs up.
On 7/17/14, 3:41 PM, Frank Carmickle wrote:
How do you set up the TURN only in emergency case? Do the phones do it themselves? Does
Kamailio control the TURN, rtpengine/mediaproxy-ng?
Who sends the bye?
I would expect that if it was a NAT issue you
would see it much sooner than 15 minutes, 30-60 seconds. Are session timers being
stripped by Kamailio? You say it's a TURN server or is it acting more like a media
relay where it is signaled into the path? What TURN server are you using? How is it
configured?
The problem occurs even without TURN, in pure peer-to-peer mode. We use
TURN only in emergency case (symmetric NAT and like that...). I do
nothing with session timers - i didn't think about it until now…
3780
days inactive
3782
days old
8 comments
3 participants
participants (3)
-
Andras FOGARASI -
Daniel-Constantin Mierla -
Frank Carmickle