Gigaset IP DECT hang up after a few second

[Martin Ludík]

Hi all

I have a two problem with Gigaset C530IP connected to SIPX cluster (3 SIP servers). 

1. I normaly setup SIP call (SIP INVITE) and after few second ( approximately 90second) the Gigaset C530 IP make hang up.
   When I use wireshark, for debug, I founded that the call end (disconnected) coming from SIPX PBX. SIPX send re-INVITE message and Gigaset answer ACK and hang up?
2. Gigaset C530 IP is ringing and than no aswer, caller hang up. After a few minutes Gigaset start ringing (similar as call back)???
   

This behaviour is only with Gigaset DECT IP (all models). Other phones  (as Yealink, GRANDSTREM...) works normally.

I try setup all combination in Gigaset phone. I dont succesfully.

This trouble I try it on alone SIPX PBX too with the same behaviour.

I can send pcap files.

Thank You

Martin Ludik

[Mihai Costache]

Is that re invite or a retransmission of initial invite?

Best Regards,

Mihai Costache

"No problem can withstand the assault of sustained thinking. "

                                -  Voltaire

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-users+unsubscribe@googlegroups.com.
To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/131bd024-bf5a-4980-b992-d09748873f62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Martin Ludík]

I dont know exactly, I dont have many skills with SIP protocol.
I think re-invite.
I sending pcap. (time stap 1046.812229)
Thanks
MartinLudik

Dne pátek 3. listopadu 2017 11:40:05 UTC+1 Mihai Costache napsal(a):

Is that re invite or a retransmission of initial invite?

Best Regards,

Mihai Costache

"No problem can withstand the assault of sustained thinking. "

                                -  Voltaire

On Fri, Nov 3, 2017 at 12:37 PM, Martin Ludík <m.e....@gmail.com> wrote:

Hi all

I have a two problem with Gigaset C530IP connected to SIPX cluster (3 SIP servers). 

1. I normaly setup SIP call (SIP INVITE) and after few second ( approximately 90second) the Gigaset C530 IP make hang up.
   When I use wireshark, for debug, I founded that the call end (disconnected) coming from SIPX PBX. SIPX send re-INVITE message and Gigaset answer ACK and hang up?
2. Gigaset C530 IP is ringing and than no aswer, caller hang up. After a few minutes Gigaset start ringing (similar as call back)???
   

This behaviour is only with Gigaset DECT IP (all models). Other phones  (as Yealink, GRANDSTREM...) works normally.

I try setup all combination in Gigaset phone. I dont succesfully.

This trouble I try it on alone SIPX PBX too with the same behaviour.

I can send pcap files.

Thank You

Martin Ludik

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.

[Martin Emanuel Ludik]

The message witch I am sending is too large

A reseding again.

ML

[Joegen Baclor]

Defintely a reinvite.  that second invite was sent 51 seconds after the initial invite was acked basing from the screen grab.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/CA%2Bpyz5qq0K49poawuwAGtW0jQxzuhs7HVWmFAayPVRULoqb38w%40mail.gmail.com.

[Martin Ludík]

Hello,

inside our network, traffic between public ip (188.246.x.x) and private ip (172.20.x.x) is routed

there is no NAT here.

we do not have any firewall rules set between these subnets that would block traffic.

the traceroute between the SIP server and the VOIP phone is ok and trasnparent.

all VOIP phones with a problem are located inside our network.

Vaculik Jiri |

2017-11-03 17:10 GMT+01:00 Martin Emanuel Ludik 

Ahoj Jirko

Muzes mrknout co pise Mihai Costache ohledne NATu a průchodu sipx vrejna IP versus telefon 172...adresa.

Díky

M

---------- Forwarded message ----------
From: Mihai Costache 
Date: 2017-11-03 13:37 GMT+01:00
Subject: Re: [sipxcom-users] Gigaset IP DECT hang up after a few second
To: Martin Emanuel Ludik 

Not sure how you can route from public 188.x to private 172.x networks.

Guess your server is somewhere with public IP and phones in a NAT setup. You will need to enable nat travsersal and under internet settings to  remove 172.x./16 network since is not routeable? I see the x-sipx-nonat  parameter

Solve this issue first you should see the phones registered with public IP and a x-sipx-privcontact= private IP

I think part of the sip signaling is lost. Not fully sure how the other part gets there (i assume you have a sip alg router). When the call drops after a few seconds

Best Regards,

Mihai Costache

"No problem can withstand the assault of sustained thinking. "

                                -  Voltaire

Dne pátek 3. listopadu 2017 11:37:19 UTC+1 Martin Ludík napsal(a):

[Michael Picher]

So 188.246.0.0/16 needs to be in Internet calling...

Michael Picher, VP of Product Management
eZuce, Inc.

300 Brickstone Square

Suite 104

Andover, MA. 01810

O.978-296-1005 X2015 
M.207-956-0262
@mpicher <http://twitter.com/mpicher> 

linkedin
www.ezuce.com

Notice: This transmittal and/or attachments may be privileged or confidential. It is intended solely for the addressee(s) named above. Any dissemination or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you.

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-users+unsubscribe@googlegroups.com.
To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/16a32b7d-cb90-4d5b-9a4a-a6eff76f3a27%40googlegroups.com.

[João Veríssimo]

I on my experience my company only had on gigaset dect with sipxcom we experience other issue like the phone was ring but the user could not answer. We have replaced this dect for the yealink dect and all work now. 

[Martin Ludík]

OK, 

the same to you

now I trying Graedstream DECT

Martin Ludík

Dne středa 15. listopadu 2017 20:00:28 UTC+1 João Veríssimo napsal(a):

[Martin Ludík]

Hello

I have analyzed the problem with the Gigaset dirty phones on SIPXCOM. Gigaset Support has found no problem, and believes there is a bug in the SIPXcom PBX. Below, I submit statements from phone support.

Thanks for some suggestions.

Martin Ludík

Hello Martin,
I've been looking at the issue and to my understanding this issue is pbx-based. In the attached packet captures you have two examples - one in conjunction with sipxcom, where we have a strange invite from pbx coming out of the blue (packet# 2682) which comes up at around 40s from an initial CANCEL conducted on the handset (packet# 1422).

Another example comes from ucware pbx with the same phone and there you have no such issue. Initial phone call was also primitively canceled but the ucware's pbx didn't send an invite out of the blue, thus I presume this issue needs to be evaluated by sipxcom further as it's out of the scope for me why sipxcom behaves as it does.

Gigaset Communications Polska Sp. z o.o.
53-611 Wrocław, Poland

Dne pátek 3. listopadu 2017 11:37:19 UTC+1 Martin Ludík napsal(a):

Hi all

[Joegen Baclor]

They are messing states sent by sipX in the record-route

Here is what sipX sent 

<sip:172.29.18.122:5060;lr;sipXecs-CallDest=UNK%2CINT;sipXecs-rs=%2Aauth%7E.%2Afrom%7EMTQyNTI4ODI0MA%60%60.900_ntap%2Aid%7EMjkwNC05%21832e44710da97f4c143a4a0fe4143dec>

This is what they are sending back in the responses.  

<sip:172.29.18.122:5060;lr;sipXecs-CallDest=UNK%2CINT;sipXecs-rs=*auth~.*from~MTQyNTI4ODI0MA%60%60.900_ntap*id~MjkwNC05!832e44710da97f4c143a4a0fe4143dec>

Ask them to send back the state parameters untouched.

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-users+unsubscribe@googlegroups.com.
To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/42e226ec-fa6c-4fdc-a371-05760ed5aede%40googlegroups.com.

[arturg...@gmail.com]

Hello there,

I'm currently handling the case regarding the sipxcom vs. gigaset for Martin. I'd like to add trace file to this reply, where the issue with sipxcom would be better visualized, but I don't see the option here to attach files directly, thus the link to those files:
https://drive.google.com/open?id=1FYkKj2goKSU5PupIHEzDkCVFUF8-o7Z6

Anyway if one compares the mac addresses of the UA's from both traces then it will be visible that it was the same phone connected to two different virtual appliances on, both appliances deployed on virtual box. One was ucware (this is just an example and based on few dozens of other interoperability tests done on different pbx's, the behavior was always the same), the other was sipxcom. And in terms of the test, sipxcom was not playing a role of a sip proxy. It was a direct connection on the same lan with sipxcom being installed as a virtual appliance on virtualbox. And yet, once the connection to another handset on the same phone (C530), through the same sipxcom appliance, different handset, was prematurely terminated before the other party picked it up, then after small amount of time it was SIPXCOM(UAS), that sent out an invite back to the DUT (UAC). Not the the other way around. To the DUT this was an unknown connection, or canceled one I should rather say (frame 44), thus BYE in further frame, plus 481 as an addition to that. In the link once again both traces for your convenience.


Regards,
Artur

To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.

To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.

[Michael Picher]

Did you try setting the signaling to TCP?

The UDP is getting fragmented...  This is seen in packets 11 - 14 

Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/04689047-a495-4da0-9987-0fe2c357cd58%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Thanks,

   Mike

-----------------------------------------------------------------------------------------

I'll do today what others don't so that I can do tomorrow what others can't. - Mat Fraser

[Joegen Baclor]

Although there seems to be a bug in sipXstackLib sending out that INVITE after the transaction has been CANCELed, that is not the cause of the premature disconnect.   The cause of the disconnect is the CANCEL coming from your UA.  Did you figure out what caused your UA to send that premature CANCEL?

The rogue INVITE needs some more investigation.  Please provide proxy logs in debug level.  This is not related to the cuase of the issue your are experiencing.

joegen 

To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-users+unsubscribe@googlegroups.com.

To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/04689047-a495-4da0-9987-0fe2c357cd58%40googlegroups.com.

[arturg...@gmail.com]

Customer reported the issue with UDP only. Apparently no issue with TCP. As for alleged fragmentation of the udp in packet 15 (reassamble of #14), this has no meaning as it didn't influence the premature session completion/termination up to #26 by the look of it, that was done through pressing "red" button on the handset. Besides, re-Invite in #27 comes after around two minutes(#27) once the call has been canceled by the user in #19 and confirmed through the pbx. Should it be the recall on the previously incomplete call, then there should a complete new session generated with new invite and new call-id, not the old one, afaik. And because the invite in #27 from pbx stick still to the previous session, that doesn't exist on the dut, thus the behavior as seen in further packets from dut itself. I'm I making myself clear?

Artur

[Martin Ludík]

When I tested Gigaset, TCP had any problem too.

Martin Ludík

Dne středa 18. dubna 2018 11:22:49 UTC+2 Michael Picher napsal(a):

[Martin Ludík]

I apologize for misinformation (EN is not my mother tongue).

I wanted to write that there was some problem when using TCP.

Dne čtvrtek 19. dubna 2018 16:44:13 UTC+2 Martin Ludík napsal(a):

[Martin Ludík]

So please identify the problem? Is an error in SIPXCOM or GIGASET? It is very troublesome to us. We migrate hundreds of users from SIPXECS 3.7.6 (here giaset worked smoothly) to SIPXCOM 17.08 cluster. Is it interesting that Gigaset phones have no problem with PBX Asterisk ???

Can you help? Do I have to send you a DECT Gigaset device to verify bad behavior on SIPXCOM and identify the problem? I am surprised that no one else has overlooked this problem (and are Gigaset phones only used in Europe)?

Thank you for finding a solution.

Martin Ludík

Dne pátek 3. listopadu 2017 11:37:19 UTC+1 Martin Ludík napsal(a):

Hi all

[Michael Picher]

It's open source software. You're free to examine the code and provide a fix (or pay someone else to do it).

3.7.6 version of sipX? Wow, ancient history. That pre-dates my time at eZuce.

From an eZuce perspective, we only QA for Polycom devices. We don't have any paying customers requiring this phone.

Thanks,

Mike

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.
To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/f378e604-43a8-43b4-ae84-5e9707e2211b%40googlegroups.com.