T41P/T48G/T58V IPv6 SIP Issues

[Phil2021]

(06-08-2017 09:14 AM)Kevin_Yealink Wrote:  

(06-07-2017 03:01 PM)ReubenFarrelly Wrote:  I have been recently testing out IPv6 SIP connectivity from a local Asterisk server to my 3 Yealink phones and run into what I believe are two bugs in the Yealink SIP implementation.

Using IPv4, none of these problems exist and the phones all work flawlessly but as soon as I change the configuration to use IPv6 SIP these issues appear. For both IPv4 and IPv6 I am using TCP transport.

These problems all occur with all three phones. All are running the latest firmware available, 58.80.0.10 (T58) and 35.81.0.110 (T48/T41).

The first relates to the IPv6 default gateway. If I statically configure an IPv6 address and enter the global IPv6 gateway address of my router on the same /64 subnet as the gateway, I observe network connectivity to the phone works. I can ping it and access the web interface over IPv6. However the phone will refuse to even attempt to connect to the IPv6 SIP server. The syslog during boot shows that the SIP application on the phone considers the IPv6 network to be unreachable (even though it is not, and the phone is reachable from outside the subnet) and it refuses to even try and connect to the SIP server. Packet captures show no attempts. The workaround for this is to enter a link-local IPv6 address for the network gateway, in which case the phone will then attempt to connect and will be able to successfully register.

Here is the section of the boot log:

Jun 5 23:31:29 ipphone-2.reub.net [497]: SUA <6+info > [000] ****API Event:(0x0009) SIPUA_EVENT_A2S_REGISTER_ON ****
Jun 5 23:31:29 ipphone-2.reub.net [497]: REG <5+notice> [000] Register: start...
Jun 5 23:31:29 ipphone-2.reub.net [497]: APP <5+notice> [SIP] linestatus lid:0, enable=1, tick=0, old_status:1, new_status:1
Jun 5 23:31:29 ipphone-2.reub.net [497]: APP <6+info > [SIP] <IPC_p2my>:msg=0x00042103, wparam=0, lparam=0, id=SIP_S2S_M2M_REG_STATUS_CHANGE
Jun 5 23:31:29 ipphone-2.reub.net [497]: APP <6+info > [SIP] <IPC_broa>:msg=0x00040001, wparam=0, lparam=1, id=SIP_REG_UPDATE_REGISTER
Jun 5 23:31:29 ipphone-2.reub.net [497]: APP <6+info > [SIP] <IPC_rcv >:msg:0x00042103, wparam:0x00000000, lparam:0x00000000, id:SIP_S2S_M2M_REG_STATUS_CHANGE
Jun 5 23:31:29 ipphone-2.reub.net ipvp[495]: IPVP<5+notice> 489.622.341:Message=0x00040001(0x00000000+0x00000001+0)
Jun 5 23:31:29 ipphone-2.reub.net ipvp[495]: IPVP<6+info > 489.622.416:unknown msg,0x00040001,from 0xe31f45b4 0x00000000, 0x00000001
Jun 5 23:31:29 ipphone-2.reub.net [497]: FSM <6+info > [000] allocating transaction ressource 1 0_582421779
Jun 5 23:31:29 ipphone-2.reub.net [497]: FSM <6+info > [000] allocating NICT context
Jun 5 23:31:29 ipphone-2.reub.net [497]: NET <6+info > [255] New binding with 2001:44b8:xxxx:xx10::25:5060
Jun 5 23:31:29 ipphone-2.reub.net [497]: NET <6+info > [255] socket node:2001:44b8:xxxx:xx10::25 , socket 31, family:10 set to non blocking mode
Jun 5 23:31:29 ipphone-2.reub.net [497]: NET <6+info > [255] Cannot connect socket node:2001:44b8:xxxx:xx10::25 family:10 Network is unreachable[101]
Jun 5 23:31:29 ipphone-2.reub.net [497]: DLG <5+notice> [000] cb_transport_error (id=1)
Jun 5 23:31:29 ipphone-2.reub.net [497]: DLG <6+info > [000] cb_nict_kill_transaction (id=1)
Jun 5 23:31:29 ipphone-2.reub.net [497]: SUA <6+info > [000] ****eCore event:(0x0002)ECORE_REGISTRATION_FAILURE ****
Jun 5 23:31:29 ipphone-2.reub.net [497]: DLG <5+notice> [000] Clear service route!
Jun 5 23:31:29 ipphone-2.reub.net [497]: REG <4+warnin> [000] Register: no responser, server id:0
Jun 5 23:31:29 ipphone-2.reub.net [497]: DLG <5+notice> [000] Clear service route!
Jun 5 23:31:29 ipphone-2.reub.net [497]: DLG <5+notice> [000] Release a terminated transaction


The second relates to the use of a Server Host and Outbound Proxy Server settings in the Account tab. I have a valid IPv6 DNS entry for sip.reub.net which has an AAAA record. It does note have an A record (for testing). If I enter that hostname in these fields the phone is unable to resolve the name and the phone is unable to register. If I put the raw IPv6 address in the field instead, the phone then is able to register and works fine. There is something wrong with the DNS resolution over IPv6:

Jun 6 09:24:33 ipphone-2.reub.net [1206]: DNS <3+error > [SIP] Query error: 'DNS server returned answer with no data'
Jun 6 09:24:33 ipphone-2.reub.net [1206]: SUA <3+error > [000] DNS resolver fail, unknown destination...
Jun 6 09:24:33 ipphone-2.reub.net [1206]: REG <4+warnin> [000] Register: no responser, server id:0

The DNS record is a very standard AAAA record:

thunderstorm ~ # host sip.reub.net
sip.reub.net has IPv6 address 2001:44b8:xxxx:xx10::25
thunderstorm ~ #

If I change this to an A record with an IPv4 address then the phone accepts it and is able to resolve and register with the SIP server over IPv4.

I believe these are both IPv6 specific bugs in the SIP application on the phone.

These are both very easy to reproduce.

Hello

This is Kevin from Yealink support team, nice to know you.

For question 1, we need your help to export syslog,config.bin,pcap files to me. You can refer to the FAQ to get those files.
http://support.yealink.com/faq/faqInfo?id=311
NOTE: I need your help to export those files in 2 scenario(global address and link address for gateway), then i can do a comparison.

For question 2, please kindly help use this parameter 'account.X.sip_server_mode=1' to provision your phone. Please change X to corresponding line. Default value is 0, so it will not DNS on IPV6 environment.
If the issue still exist, please kindly send files to me.

May i know how many phones in your side now? Is there new projects so you are testing yealink phones? Can you share me more information about it.

BR
Kevin

Just to add fell over this bug in dual-stack mode some 4 years later on the W60B, worked fine in single mode IPv6 but in dual-stack despite setting a preference under network settings to favour IPv6, it would register only via IPv4. Adding the setting discussed above sees it defaulting first to IPv6, which should be the default behaviour. With IPv6 becoming ever more popular a customer shouldn't need to be adding obscure settings.