[Spce-user] Fwd: Sipwise sending BYE 60 seconds after INVITE

Matt Van Veenendaal matt at curiousminds.com
Thu Jan 17 13:30:54 EST 2013


Thanks so much for helping me out with this Andreas,

Here's the logs from one of the calls: https://gist.github.com/0cdace00683ed788e548 

-- 
Matt Van Veenendaal


On Thursday, January 17, 2013 at 3:12 AM, Andreas Granig wrote:

> Hi Matt,
> 
> You shouldn't tinker with these SIP-internal call-timers, rather than 
> figuring out why exactly the call is torn down.
> 
> Can you post the output of "ngrep-sip b" for such a call, so we can 
> together find out who is disconnecting the call and what exactly is 
> happening before that.
> 
> Andreas
> 
> On 01/17/2013 02:30 AM, Matt Van Veenendaal wrote:
> > Hi Guys,
> > 
> > I've been having this issue recently as well recently and i'm getting
> > the same issues.
> > I've attempted a few things with no luck:
> > 
> > 1. Altering SEMS configuration in /etc/ngcp-config/config.yml
> > 
> > I've tried turning off conferencing, setting calltimer_enable to 'no'
> > and setting session_timer enable: to 'no'.
> > In all of these cases the call religiously disconnects at 60 seconds.
> > 
> > 2. Altering /etc/sems/sems.conf
> > 
> > I've tried tinkering with this file in particular commenting out the
> > following two lines:
> > sip_timer_b=60000
> > sip_timer_f=60000
> > 
> > This worked in 2.6 and seems to have no effect in 2.7
> > I had some brief luck setting these to be 10 times higher and
> > connections seemed to work well, however this reverted an hour or so
> > later and now i'm still getting the 60 second disconnect issue.
> > 
> > It's worth noting again that this message is not originating from the
> > client and is sent to both clients simultaneously and only occurs for
> > calls that are peer-to-peer. Turning off ICE on the client forces the
> > media proxy and the call to be longer then 60 seconds, but we would
> > prefer to alow these calls to be P2P.
> > 
> > In terms of answering the above question about the sems log, there's
> > really nothing interesting there:
> > Jan 16 19:10:10 sipwise01 sems[2170]: [#7f9c0bafa700] [run,
> > udp_trsp.cpp:186] INFO: Started SIP server UDP transport on 127.0.0.1:5080
> > Jan 16 19:10:10 sipwise01 sems[2170]: [#7f9c0b8f8700] [run,
> > udp_trsp.cpp:186] INFO: Started SIP server UDP transport on 127.0.0.1:5080
> > Jan 16 19:10:10 sipwise01 sems[2170]: [#7f9c0b9f9700] [run,
> > udp_trsp.cpp:186] INFO: Started SIP server UDP transport on 127.0.0.1:5080
> > Jan 16 19:10:10 sipwise01 sems[2170]: [#7f9c0b7f7700] [run,
> > udp_trsp.cpp:186] INFO: Started SIP server UDP transport on 127.0.0.1:5080
> > 
> > Thanks for your help!
> > --
> > Matt Van Veenendaal
> > 
> > On Wednesday, November 28, 2012 at 2:31 AM, Andrew Pogrebennyk wrote:
> > 
> > > James,
> > > 
> > > On 11/26/2012 08:42 PM, James Hurley wrote:
> > > > Here's the log, it looks like the BYE is coming from SEMS on port 5080.
> > > > ( the users in question are 16.james and 16.james_expert )
> > > > 
> > > > https://gist.github.com/e865aa36c663665503a1
> > > 
> > > Yes. Is there any hint in sems.log?
> > > 
> > > Andrew
> > > 
> > > _______________________________________________
> > > Spce-user mailing list
> > > Spce-user at lists.sipwise.com <mailto:Spce-user at lists.sipwise.com>
> > > http://lists.sipwise.com/listinfo/spce-user
> > > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Spce-user mailing list
> > Spce-user at lists.sipwise.com (mailto:Spce-user at lists.sipwise.com)
> > http://lists.sipwise.com/listinfo/spce-user
> > 
> 
> 
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com (mailto:Spce-user at lists.sipwise.com)
> http://lists.sipwise.com/listinfo/spce-user
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20130117/c2737308/attachment-0001.html>


More information about the Spce-user mailing list