Re: SPA112 Incompatibility with some SIP provider (Zoiper working)

JulienRobin54446 · ‎02-14-2020

Hello, sorry for bothering with our problem here, but I guess that it may be easy to solve considering information we already collected and give here.

We have a working SIP configuration that is not working on SPA112 (but working with others SIP devices/software, including Zoiper - and some people also succeeded to with Siemens Gigaset SIP phones using the same configuration).

We used Wireshark to compare everything in details, and spent lots of hours trying to see what is different or wrong : we succeeded to have a configuration which is as identical as possible compared to Zoiper working configuration but the problem persists.

The problem is :

The registration is successful (the SPA112 send REGISTER requests, and the SIP server answers by 200 OK).

But when some mobile phone calls the SPA112 SIP Number, the SIP server doesn't even send us the INVITE request (no matter the fact that SIP server is able to communicate with us, as he already answered to us with success at REGISTER).

In the other direction, when calling from SPA112 to a mobile phone, (SPA112 sends INVITES request), after some seconds and as soon as the mobile phone begins ringing, the SPA112 call is Terminated by the SIP server (487 Request Terminated, precisely at the moment when the RTP transfer should begin). Sometimes, the RTP transfers isn't even started when terminated, sometimes 1 or 2 RTP packets had the time to be sent before the server terminate the call. The codec (G711A) is the good one here so it can't be the problem here.

This is not a firewall problem as SIP port range and RTP port range are open and forwarded to the SPA112.

Please find attached the SIP exchanges Wireshark captures from SPA112 vs some 2 others working devices with the same account.

Can you help us to find out what is the problem here ?

Thank you very in advance,

Best regards

Dan Lukes · ‎02-14-2020

But when some mobile phone calls the SPA112 SIP Number, the SIP server doesn't even send us the INVITE request (no matter the fact that SIP server is able to communicate with us, as he already answered to us with success at REGISTER).

It may not be the same case. Definitely, it's not the same case if a statefull firewall or NAT is on the path. So it's important to distinguish. SIP server doesn't send INVITE, or such invite has been sent but didn't arrived to destination ?

the SPA112 call is Terminated by the SIP server (487 Request Terminated, precisely at the moment when the RTP transfer should begin).

It's known symptom. If RTP packets send by server are rejected on the path, server use 487 to terminate call (useless call as audio is not delivered successfully). Even this is NAT/firewall issue most of the case.

This is not a firewall problem as SIP port range and RTP port range are open and forwarded to the SPA112.

Are you pretty sure ? There's nothing like well known RTP port range. Every SIP client uses own range which may or may not be configurable. So which range you have opened and forwarded ?

Zoiper may use (and propably is using) diffferent ports than SPA112.

Based on TXT files you attached:

Zoiper claims port 33258 for RTP

Integrated client claims 35368

SPA112 claims 16432

Hypothesis: you have opened and forwarded range suitable for Zopier/internal client but not range used by SPA112. Either modify firewall//NAT configuration to cover SPA112 range as well or configure SPA112 to use same range as Zoiper/internal uses.

Now how about rejected incoming INVITE. Even it's source port vary by client.

Hypothesis: source port used by SPA112 is not forwarded properly thus incoming INVITE is not delivered.Answer to REGISTER gets passed, because outgoing REGISTER has created a temporary NAT/firewall mapping that allows response to pass. Such mapping is temporary. Unless incomming INVITE arrives during short living existence of such mapping, it's rejected.

Solution: either create permanent mapping for the range used by SPA112, OR make sure that next periodic REGISTER is send before temporary mapping created by previous one gets expired (e.g. increase expiration time, decrease time between two consecutive REGISTER or both).

JulienRobin54446 · ‎02-14-2020

Hi,

Thanks for your suggestions, unfortunately, even by double checking, none of those suggestions are in trouble here.

But doing the double check, I got something even more strange : Ingoing calls attempts makes the SIP server trying to reach the SPA112 using TCP/IP port 5062 (despite the fact everything has been established using UDP).

@Dan Lukes wrote:
But when some mobile phone calls the SPA112 SIP Number, the SIP server doesn't even send us the INVITE request (no matter the fact that SIP server is able to communicate with us, as he already answered to us with success at REGISTER).
It may not be the same case. Definitely, it's not the same case if a statefull firewall or NAT is on the path. So it's important to distinguish. SIP server doesn't send INVITE, or such invite has been sent but didn't arrived to destination ?

As the ingoing call attempt is made just few seconds (10 seconds ?) after the registration is successful between the SPA112 and the SIP server using UDP, what I was already sure is that the SIP server doesn't even try to send the INVITE request on the UDP session on which exchanges (registrations, answers, outgoing call attempts and anwsers etc) are visible.

But by expanding the port forwarding to TCP 5060->5080 too (not UDP only), I saw on wireshark that the SIP server tries, on ingoing call, to reach the SPA112 by sending a TCP packet...! Which is not normal at all, as everything is made using UDP here.

Of course, the TCP server connection attempt from SIP server to SPA112 get thrown away immediately by SPA112.

Why is the SIP server doing this? Why isn't he using the working UDP session? Did you already see that in the past?

@Dan Lukes wrote:
the SPA112 call is Terminated by the SIP server (487 Request Terminated, precisely at the moment when the RTP transfer should begin).
It's known symptom. If RTP packets send by server are rejected on the path, server use 487 to terminate call (useless call as audio is not delivered successfully). Even this is NAT/firewall issue most of the case.

For outgoing calls being "487 Terminated" as soon as the mobile phone starts to ring, of course this is the first thing we checked (so we opened the firewall). But this was pointless : even in this case, RTP stream is initiated by the client as soon as the "183 Session Progress" SIP/UDP message is received by the SPA112. Same for the others SIP client (this is why Zoiper didn't need to open port forwards). The problem is : when using SPA112, "487 Request Terminated" SIP/UDP message is sent by the SIP server only few milliseconds (~30 ms) after the "183 Session Progress" message, no matter if the SPA112 already sent or not RTP packets (this is so short that sometimes, 1, 2 or 3 RTP packet are sent before we receive the 487, sometimes the RTP packets are sent when the 487 Message already arrived).

This is not a firewall problem as SIP port range and RTP port range are open and forwarded to the SPA112.
Are you pretty sure ? There's nothing like well known RTP port range. Every SIP client uses own range which may or may not be configurable. So which range you have opened and forwarded ?

Yes, absolutely sure, as the SPA112 gives the ability to choose this range (I let the standard one, from 16384 to 16482), this is why it selected the 16432 port you saw in the capture.

At router's side :

Now how about rejected incoming INVITE. Even it's source port vary by client.
Hypothesis: source port used by SPA112 is not forwarded properly thus incoming INVITE is not delivered.Answer to REGISTER gets passed, because outgoing REGISTER has created a temporary NAT/firewall mapping that allows response to pass. Such mapping is temporary. Unless incomming INVITE arrives during short living existence of such mapping, it's rejected.

Unfortunately this is not what happen here. (And what would have been the solution is already done).

SPA112 is using the same source port as the destination port for SIP (5062) (of course it's not mandatory to do so : Zoiper for example take a random locally available source port talking with SIP-Server:5062 - when you want to use several connections to the same destination:port, letting the system choosing a random/available local port is even often mandatory). But having the SPA112 using the 5062 port as source is unlikely to be the cause, as when using the ISP router integrated SIP client, it also works using 5062 port as source and destination (and there is no problem with it). [EDIT : ISP router is using 5060 as originating port, not 5062]

Of course when using gateways and firewalls things, TCP and UDP connections should be kept alive by regular keepalives or exchanges, but here, as the problem shows up, the registration has been completed only a handful of seconds ago so this is not the problem (datagrams emited from the server would have been received into the SPA112). And even port forwarding is correctly set on this port, so this definitely cannot be the problem here.

Thanks anyway for those suggestions, and thanks in advance for further help! I got to understand why the SIP server tries to connect to the SPA112 using TCP/IP for ingoing call. And for outgoing calls, I guess I should spy on the WAN if something similar is hitting the router on some unforwarded port (I can put a Wireshark on the fiber WAN link), as on the SPA112 link, there is nothing visible explaining the sudden "487 Request Terminated" that follow the "183 Session Progress"

Best regards

PS : using the SPA112 with another SIP provider (OVH) works here, with the same local network and conditions, without the need of any port forward into the router. The problem here is only encountered when using SFR SIP server. It looks like no one succeeded to get the SPA112 working with SFR SIP accounts. But this is science and standards, so we got to find a solution, or at least a clear explanation

Dan Lukes · ‎02-16-2020

Incoming calls attempts makes the SIP server trying to reach the SPA112 using TCP/IP port 5062 (despite the fact everything has been established using UDP). Of course, the TCP server connection attempt from SIP server to SPA112 get thrown away immediately by SPA112.Why is the SIP server doing this? Why isn't he using the working UDP session?

OK, make sure it's TCP even on WAN side. If yes, it's server bug. As workaround, try to use TCP for SIP instead of UDP ("SIP Transport" option in configuration). It may or may not help.

I guess I should spy on the WAN if something similar is hitting the router on some unforwarded port (I can put a Wireshark on the fiber WAN link), as on the SPA112 link, there is nothing visible explaining the sudden "487 Request Terminated" that follow the "183 Session Progress"

Yes, try it - and share observation results.

JulienRobin54446 · ‎02-17-2020

I guess I should spy on the WAN if something similar is hitting the router on some unforwarded port (I can put a Wireshark on the fiber WAN link), as on the SPA112 link, there is nothing visible explaining the sudden "487 Request Terminated" that follow the "183 Session Progress"
Yes, try it - and share observation results.

Hi, that's what I already did (described in new messages). The final question to all this problem is :

Do you know which setting would ask the SPA112 to add ";transport=UDP" into every sent messages, like Zoiper is doing?

This is the problem here : even when contacting the SIP server using UDP, ingoing call are signaled by the server through TCP connection attempt (and Outgoing calls over UDP are stopped by the the server just at their begining because no TCP connection is active).

I found a workaround by using "5060" as emitting port (while the SIP server port is 5062), but resolving this problem using this kind of "lucky unexplained magic trick" is a bit of an abomination into computing science and device configurations.

Of course this is a little bit strange coming from a server which refuses registration over TCP/IP, so there is 2 problems here (one at Cisco/SPA112-1.4.1_SR5 client side, the other one at Alcatel-Lucent-HPSS/3.0.3 server side)

As the SPA112 support will be terminated in few months, if some option should be added/corrected I would be glad to help and test before the SPA112 software support is stopped.

Thank you in advance.

Dan Lukes · ‎02-17-2020

Do you know which setting would ask the SPA112 to add ";transport=UDP" into every sent messages, like Zoiper is doing?
This is the problem here

Do you mean those lines ?

REGISTER sip:ims.mnc010.mcc208.3gppnetwork.org;transport=UDP SIP/2.0
Contact: <sip:OUR_SIP_LINE_PHONE_NUMBER@OUR_EXTERNAL_IP_ADDRESS:46663;rinstance=616788d2287cf629;transport=UDP>
To: <sip:OUR_SIP_LINE_PHONE_NUMBER@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>
From: <sip:OUR_SIP_LINE_PHONE_NUMBER@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>;tag=f5386b65

No such setting exist as far as I know - because "transport=UDP" is the default (unless transport layer protocol can be derived from DNS SRV record - so make sure there are no incompatible DNS records). See RFC 3261 par. 19.1.2:

The default transport is scheme dependent.  For sip:, it is UDP.  For sips:, it is TCP.

But there seems not to be problem here. You claimed router internal SIP client working - and such client sends no transport=UDP as well. So missing transport= declaration should not be the issue cause.

This is the problem here : even when contacting the SIP server using UDP, ingoing call are signaled by the server through TCP connection attempt (and Outgoing calls over UDP are stopped by the the server just at their begining because no TCP connection is active).

Definitely server's bug. I see no bug on SPA112 side - transport=UDP is optional (and superfluous as no transport mean UDP here).

As the SPA112 support will be terminated in few months, if some option should be added/corrected I would be glad to help and test before the SPA112 software support is stopped.

I'm just enthusiast and volunteer. No Cisco employee in charge of ATA developments reads those forums as far as I know. Moreover, according my experience, SPA112 software support has been stopped already, long time ago. Only severe secure bugs will be patched (and you should not bet even on it). As we identified no SPA112 bug at all, chances are near to zero.

JulienRobin54446 · ‎02-17-2020

@Dan Lukes wrote:
Do you know which setting would ask the SPA112 to add ";transport=UDP" into every sent messages, like Zoiper is doing?
This is the problem here
Do you mean those lines ?
REGISTER sip:ims.mnc010.mcc208.3gppnetwork.org;transport=UDP SIP/2.0
Contact: <sip:OUR_SIP_LINE_PHONE_NUMBER@OUR_EXTERNAL_IP_ADDRESS:46663;rinstance=616788d2287cf629;transport=UDP>
To: <sip:OUR_SIP_LINE_PHONE_NUMBER@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>
From: <sip:OUR_SIP_LINE_PHONE_NUMBER@ims.mnc010.mcc208.3gppnetwork.org;transport=UDP>;tag=f5386b65
No such setting exist as far as I know - because "transport=UDP" is the default (unless transport layer protocol can be derived from DNS SRV record - so make sure there are no incompatible DNS records). See RFC 3261 par. 19.1.2:
The default transport is scheme dependent.  For sip:, it is UDP.  For sips:, it is TCP.

Yes it's about those lines.

Well, those things exists into the RFC, into some SIP clients, and RFC compliant servers implementation are be able to handle it (which is even the case of the strange server I'm connecting to).

https://tools.ietf.org/html/rfc3261#page-154

   sip:bob@biloxi.com              (can resolve to different transports)
   sip:bob@biloxi.com;transport=udp

The undefined (and pretty surprising/problematic) server behavior discussed here due to having the SPA112 not defining explicitly which protocol should be used for the further exchanges - so that the server choose or expect the wrong one (stupid server) - would have been easily avoided by using something in the RFC that has been made available for this purpose.

It's a chance that the undefined behavior resulting from this missing transport declaration can be influenced by the source port, as it's my wonky workaround for this issue.

Moreover, according my experience, SPA112 software support has been stopped already, long time ago. Only severe secure bugs will be patched (and you should not bet even on it). As we identified no SPA112 bug at all, chances are near to zero.

I appreciate the time you spent trying to help me, but over your experience you may got used to to think "all people are here because they are wrong", so that people asking for help cannot be right. That's not always helping, as eventually, most of your opinions on the causes and solutions of the trouble I initially encountered here finally turned to be wrong or at least questionable opinions - it happens even to the best of us, even me... haha.

I'll hope that what you say (about having no chances to have the support looking at it) turns to be wrong, but who know, unfortunately this part may prove to be true, as the SPA112 is becoming old and will soon stop being manufactured! It may be too late (there might be some ways to find out), but your opinons may do much better than discouraging me to try (it's a customer service thing, trying to make customers accepting their unsolved problems - much cheaper this way)

This was important to say but of course I appreciate the time you spent trying to help me

Best Regards

Dan Lukes · ‎02-17-2020

https://tools.ietf.org/html/rfc3261#page-154

   sip:bob@biloxi.com              (can resolve to different transports)
   sip:bob@biloxi.com;transport=udp

Just note - it can resolve to different transports only if DNS SRV record _sip._tcp.biloxi.com exists (assuming compliant client)

you may got used to to think "all people are here because they are wrong", so that people asking for help cannot be right.

You should consider the English is not my native language. My speaking skills are very limited. So often I'm just unable to fine tune wording to soften the sentence.

I'll hope that what you say (about having no chances to have the support looking at it) turns to be wrong, but who know, unfortunately this part may prove to be true, as the SPA112 is becoming old and will soon stop being manufactured! It may be too late (there might be some ways to find out), but your opinons may do much better than discouraging me to try

This is misunderstanding caused by language barrier. I'm not discouraging you to ask official support for help at all. It's polite to report bugs-issues found (assuming your English is good enough to report them by phone as it's only support contact method available).

Just don't expect it will solve the issue in short time. Note that saying "short time" I mean something like one year.

I has reported two severe bugs (first one related to SSL connection handling allowing man-in-the-middle kind of attack; second one allowing unauthenticated remote client to initiate call). We've been waiting for the patch for more than a year. And you are not reporting bug, you have just feature request - so you need to have valid service contract to be eligible to discuss this with support ...

I assume you need to have your phone system working, you should not rely on help from support - now and for every issue in the future. Just honest advice from someone running SPAxxx based phone system with hundreds phones for about ten years in more than seven countries around. Despite my long term experience, I'm wishing you to have success asking support for help. Just don't bet on fast solution.

JulienRobin54446 · ‎02-14-2020

Some problem is found :

Despite the fact the registration has been made using UDP port 5062 on both side (SPA112 side and SIP server port), when some ingoing call arrives, the INVITE request is sent by the SIP server using a TCP/IP connection attempt... which is refused by SPA112.

I placed a port forward for TCP Port 5062 to my computer, opened a TCP/IP server on it and look what happened

The SIP server acted as TCP/IP client and tried to connect to my IP on port 5062, then sending the invite request.

But this request was expected on UDP/IP port 5062 (so it arrives into the SPA112), not on TCP/IP (the SPA112 refuses it). Do you know what makes the SFR's SIP server behaving like this when using SPA112?

JulienRobin54446 · ‎02-15-2020

The problem, definitely, is that the SPA112 does not ask for UDP transport explicitly.

On Zoiper into the first REGISTER message we can see :

REGISTER sip:ims.mnc010.mcc208.3gppnetwork.org;transport=UDP SIP/2.0

Look at the "transport=UDP" string. This is what makes everything working here. Into the following SIP server 200 OK answer, we can see the transport=udp string taken into account.

Contact: <sip:+33XXXXXXXXX@OUR_EXTERNAL_IP:46663;rinstance=616788d2287cf629;transport=udp>;expires=300

I didn't find any way to tell the SPA112 to add this to the sent requests. But I noticed that the provider's router integrated SIP client does not ask for transport=UDP either... but still get this answer into the 200 OK message :

Contact: <sip:+33XXXXXXXXX@OUR_EXTERNAL_IP:5060;user=phone;transport=udp>;expires=3483

He got into the answer (200 OK) the "transport=udp" string for free from the server... but the SPA112 did not.

And the from SPA112, ingoing/outgoing call doesn't work (symptoms described, with SIP server trying to reach the SPA112 for ingoing call over TCP/IP instead of using the UDP established communication used for registration).

As neither SPA112 and ISP's SIP client are explicitely requesting the "transport=udp" string, I guessed that using 5060 as originating port, instead of using 5062 as originating port (outbound proxy server is still on 5062), is a kind of "magic formula" here... this makes no sense, but it worked around the issue : when SPA112 uses 5060 as originating port, the SIP server answers "transport=UDP" into the 200 OK message. Everything works now... but this is a crappy workaround. This is not the way it is supposed to be done.

How to tell to the SPA112 to add transport=UDP explicitely into the REGISTER request?