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

[Andreas Granig]

Hi,

Could you please check /var/log/ngcp/sems.log during such a call? Any 
lines appearing there?

Also, please post the content of /etc/sems/etc/ngcp.sbcprofile.conf to 
check what's configured for the b2bua.

Andreas

On 01/17/2013 07:30 PM, Matt Van Veenendaal wrote:
> 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
>