• Welcome to SAIL Community Supported PBX . Please login or sign up.
 

yealink 26 found but will not provision

Started by rrkelly, February 25, 2017, 07:48:38 PM

Previous topic - Next topic

rrkelly

i suspect this has to do with the previous topic -- i have the embedded debian sark ver 5 i have two yealink phones a t21 that is found and provisioned just fine
and a t26 that is found but will not provision sark says #include yealink12 in the provisioning field for the t26 tried to change to t 26 no diff-- i tried to find config fields in the t26 phone itself to match what the previous topic mentioned still can not get the t26 to work -- the firmware for t26 is current any idea's is there a new t26 file?
rob

sysadmin

Which release of V5 do you have please?
Can you show me the content of the provisioning box for the extension please?

You can see the provisioning stream (if any) that V5 will supply by doing the following at your browser

http://your.sark.ip.address/provisioning/{mac}

where {mac} is the MAC address of the phone


rrkelly

sail           5.0.0-20 

this is the head of the provisioning file shown by the mac address from the browser -- i can add the rest of the codec's if needed
#!version:1.0.0.1

##File header "#!version:1.0.0.1" can not be edited or deleted, and must be placed in the first line.##

account.1.enable = 1
account.1.label = 401
account.1.display_name = Ext401
account.1.auth_name = 401
account.1.password = nVBM7wyJ 
account.1.user_name =  401
account.1.sip_server_host = 192.168.10.198
account.1.outbound_proxy_enable = 1
account.1.outbound_host = 192.168.10.198
account.1.proxy_require = 192.168.10.198

#Enable or disable the phone to subscribe the register status; 0-Disabled (default), 1-Enabled;
account.1.subscribe_register = 1

#Enable or disable the phone to subscribe the message waiting indicator; 0-Disabled (default), 1-Enabled;
account.1.subscribe_mwi = 1

#Enable or disable the phone to subscribe to the voicemail through the message waiting indicator; 0-Disabled (default), 1-Enabled;
account.1.subscribe_mwi_to_vm = 1

voice_mail.number.1 = *50*

# Enable/Disable the codecs you want to use - default is law, G729, G722

account.1.codec.1.enable = 1
account.1.codec.1.payload_type = PCMU
account.1.codec.1.priority = 1
account.1.codec.1.rtpmap = 0

sysadmin

OK, well it looks as thought the provisioning stream is being correctly built.   Syslog will give you a little more information.   If you tail -f /var/log/syslog and reboot the phone you should see some interaction between the phone and SARK.   Here's what it looks like on 5.0.0-34 (which is a little different, but not much).   I've added some annotation ==============>   like this


====================> Here is the SIP PnP subscribe arriving at the Multicast listener

Mar  1 16:55:51 s200 responder: IN -------------------------------------------------------{
Mar  1 16:55:51 s200 responder: SUBSCRIBE sip:MAC0015651db42e@224.0.1.75 SIP/2.0
Mar  1 16:55:51 s200 responder: Via: SIP/2.0/UDP 172.16.0.108:5059;branch=z9hG4bK44265
Mar  1 16:55:51 s200 responder: From: <sip:MAC0015651db42e@224.0.1.75>;tag=44174
Mar  1 16:55:51 s200 responder: To: <sip:MAC0015651db42e@224.0.1.75>
Mar  1 16:55:51 s200 responder: Call-ID: 44174@172.16.0.108
Mar  1 16:55:51 s200 responder: CSeq: 1 SUBSCRIBE
Mar  1 16:55:51 s200 responder: Contact: <sip:MAC0015651db42e@172.16.0.108:5059>
Mar  1 16:55:51 s200 responder: Max-Forwards: 70
Mar  1 16:55:51 s200 responder: User-Agent: Yealink SIP-T28P 2.70.23.10 0015651db42e
Mar  1 16:55:51 s200 responder: Expires: 0
Mar  1 16:55:51 s200 responder: Event: ua-profile;profile-type="device";vendor="Yealink";model="SIP-T28P";version="2.70.23.10"
Mar  1 16:55:51 s200 responder: Accept: application/url
Mar  1 16:55:51 s200 responder: Content-Length: 0
Mar  1 16:55:51 s200 responder: ----------------------------------------------------------}

=======================> The listener logs what it finds
Mar  1 16:55:51 s200 responder: Harvested MAC address 0015651db42e
Mar  1 16:55:51 s200 responder: Harvested Vendor Yealink
Mar  1 16:55:51 s200 responder: Harvested Model SIP-T28P

========================> And responds with a 200OK
Mar  1 16:55:51 s200 responder: OUT (-> 172.16.0.108:5059) -------------------------------{
Mar  1 16:55:51 s200 responder: SIP/2.0 200 OK
Mar  1 16:55:51 s200 responder: Via: SIP/2.0/UDP 172.16.0.108:5059;branch=z9hG4bK44265
Mar  1 16:55:51 s200 responder: From: <sip:MAC0015651db42e@224.0.1.75>;tag=44174
Mar  1 16:55:51 s200 responder: To: <sip:MAC0015651db42e@224.0.1.75>
Mar  1 16:55:51 s200 responder: Call-ID: 44174@172.16.0.108
Mar  1 16:55:51 s200 responder: CSeq: 1 SUBSCRIBE
Mar  1 16:55:51 s200 responder: Expires: 0
Mar  1 16:55:51 s200 responder: Contact: <sip:224.0.1.75:5060>
Mar  1 16:55:51 s200 responder: User-Agent: responder
Mar  1 16:55:51 s200 responder: Content-Length: 0
Mar  1 16:55:51 s200 responder: ----------------------------------------------------------}

=================> ZTP is enabled so the listener creates a new extension for the phone

Mar  1 16:55:51 s200 responder: Inserted new extension 502 with MAC 0015651db42e for vendor Yealink and model SIP-T28P

==================> The listener issues a commit and waits for it to finish
Mar  1 16:55:51 s200 logger: Regenerating Asterisk
Mar  1 16:55:55 s200 logger: Regenerating Asterisk Finished

==================> Now the listener sends the provisioning URI to the phone

Mar  1 16:55:55 s200 responder: OUT-------------------------------------------------------{
Mar  1 16:55:55 s200 responder: NOTIFY 172.16.0.108:5059 SIP/2.0
Mar  1 16:55:55 s200 responder: Via: SIP/2.0/UDP 224.0.1.75:5060;rport
Mar  1 16:55:55 s200 responder: Max-Forwards: 25
Mar  1 16:55:55 s200 responder: Contact: <sip:224.0.1.75:5060>
Mar  1 16:55:55 s200 responder: To: <sip:MAC0015651db42e@224.0.1.75>;tag=44174
Mar  1 16:55:55 s200 responder: From: <sip:MAC0015651db42e@224.0.1.75>;tag=58b6fd17-2af9c94f
Mar  1 16:55:55 s200 responder: Call-ID: 44174@172.16.0.108
Mar  1 16:55:55 s200 responder: CSeq: 3 NOTIFY
Mar  1 16:55:55 s200 responder: Content-Type: application/url
Mar  1 16:55:55 s200 responder: User-Agent: responder
Mar  1 16:55:55 s200 responder: Subscription-State: terminated;reason=timeout
Mar  1 16:55:55 s200 responder: Event: ua-profile
Mar  1 16:55:55 s200 responder: Content-Length: 32
Mar  1 16:55:55 s200 responder:
Mar  1 16:55:55 s200 responder: http://172.16.0.134/provisioning
Mar  1 16:55:55 s200 responder: ----------------------------------------------------------}

==================> Now the phone issues a request for its 'Y" file

Mar  1 16:56:03 s200 apache2: 172.16.0.108 processing URI /provisioning/y000000000000.cfg

==================> In 5.0.0-35 we just serve a common Y file (it was different in -20).

Mar  1 16:56:03 s200 apache2: 172.16.0.108 Found Yealink Y file  y000000000000.cfg serving as common
Mar  1 16:56:03 s200 apache2: 172.16.0.108 sending config yealink.Common

==================> Finally, the phone requests its MAC config file
Mar  1 16:56:12 s200 apache2: 172.16.0.108 processing URI /provisioning/0015651db42e.cfg
Mar  1 16:56:12 s200 apache2: 172.16.0.108 Found MAC 0015651db42e
Mar  1 16:56:12 s200 apache2: 172.16.0.108 Found UA Yealink SIP-T28P 2.70.23.10 00:15:65:1d:b4:2e
Mar  1 16:56:12 s200 apache2: 172.16.0.108 Found phone model T28P from UA
Mar  1 16:56:12 s200 apache2: 172.16.0.108 Found UA Yealink SIP-T28P 2.70.23.10 00:15:65:1d:b4:2e
Mar  1 16:56:12 s200 apache2: 172.16.0.108 Found phone model T28P from UA
Mar  1 16:56:13 s200 apache2: 172.16.0.108 sending config 0015651db42e.cfg

============  And we're done, the phone will now register and come into service


rrkelly

seems to be pretty close also noticed that sail see's it go offline --



Mar  1 16:54:08 sarksvr responder: IN -------------------------------------------------------{
Mar  1 16:54:08 sarksvr responder:
Mar  1 16:54:08 sarksvr responder: Via: SIP/2.0/UDP 192.168.10.196:5059;branch=z9hG4bK1488326427
Mar  1 16:54:08 sarksvr responder: From: <sip:MAC00156534e02a@224.0.1.75>;tag=1488326427
Mar  1 16:54:08 sarksvr responder: To: <sip:MAC00156534e02a@224.0.1.75>
Mar  1 16:54:08 sarksvr responder: Call-ID: 1488326427@192.168.10.196
Mar  1 16:54:08 sarksvr responder: CSeq: 1 SUBSCRIBE
Mar  1 16:54:08 sarksvr responder: Contact: <sip:MAC00156534e02a@192.168.10.196:5059>
Mar  1 16:54:08 sarksvr responder: Max-Forwards: 70
Mar  1 16:54:08 sarksvr responder: User-Agent: Yealink SIP-T26P 6.73.0.40
Mar  1 16:54:08 sarksvr responder: Expires: 0
Mar  1 16:54:08 sarksvr responder: Event: ua-profile;profile-type="device";vendor="yealink";model="SIP-T26P";version="6.73.0.40"
Mar  1 16:54:08 sarksvr responder: Accept: application/url
Mar  1 16:54:08 sarksvr responder: Content-Length: 0
Mar  1 16:54:08 sarksvr responder: ----------------------------------------------------------}


sysadmin

I don't understand your last comment Rob, or the fragment, except to say that it looks like a normal T26 multicast subscribe.   I need to see the whole stream.  Or is that the whole stream?   There are two different conversations which go on.   The first is the PnP subscribe which happens between the Yealink and the multicast listener task (responder).   The second is the HTTP request which comes in to the provisioning server.  In that second phase, the phone will ask for its Y file and its {mac}.cfg file.   

   


rrkelly

ok the last posted was complete except the setting of the codec's which looked redundant -- when is the second phase suppose to show up -- i don't see the second part that you talked about -- how long after the segment i posted should the second part show up? i think that might be the problem.
could you post a copy of the second part so i now what to look for ? and is it in the syslog file? if not where? -- i can use tcpdump

thank you
rob

rrkelly

sorry what i posted was it for syslog  it was complete and the  the codec's were in the provisioning file  --  all after what i posted  is cron logging messages
i cannot see anything pertaining to the phone in the log when i unplug it

sysadmin

OK, I will spin up a -20 release on VM to see if I can recreate what you are seeing.

rrkelly

ok i can manually configure both phones t26 and t21  -- after a factory reset of the phones discovery will find and correctly identify both phones after i adopt the phones a correct cfg file named by the correct mac address is generated but the phones will not provision.  what is the format of the provisioning message  after the initialmsg below -- i will see if i can find it with tcpdump

Mar  1 16:54:08 sarksvr responder: IN -------------------------------------------------------{
Mar  1 16:54:08 sarksvr responder:
Mar  1 16:54:08 sarksvr responder: Via: SIP/2.0/UDP 192.168.10.196:5059;branch=z9hG4bK1488326427
Mar  1 16:54:08 sarksvr responder: From: <sip:MAC00156534e02a@224.0.1.75>;tag=1488326427
Mar  1 16:54:08 sarksvr responder: To: <sip:MAC00156534e02a@224.0.1.75>
Mar  1 16:54:08 sarksvr responder: Call-ID: 1488326427@192.168.10.196
Mar  1 16:54:08 sarksvr responder: CSeq: 1 SUBSCRIBE
Mar  1 16:54:08 sarksvr responder: Contact: <sip:MAC00156534e02a@192.168.10.196:5059>
Mar  1 16:54:08 sarksvr responder: Max-Forwards: 70
Mar  1 16:54:08 sarksvr responder: User-Agent: Yealink SIP-T26P 6.73.0.40
Mar  1 16:54:08 sarksvr responder: Expires: 0
Mar  1 16:54:08 sarksvr responder: Event: ua-profile;profile-type="device";vendor="yealink";model="SIP-T26P";version="6.73.0.40"
Mar  1 16:54:08 sarksvr responder: Accept: application/url
Mar  1 16:54:08 sarksvr responder: Content-Length: 0
Mar  1 16:54:08 sarksvr responder: ----------------------------------------------------------}



sysadmin

March 08, 2017, 01:40:04 PM #10 Last Edit: March 08, 2017, 01:42:14 PM by sysadmin
Do you have PnP provisioning turned on in Globals?   It looks rather like the listener is ignoring you.  It will do this if there is no extension definition in extensions and you do not have ZTP turned on.

You can manually set the provisioning address in the Yealink with this URI, but you must create the extension in SARK ahead of time, (you can't run ZTP unless you run PnP).

http://your.sark.ip.address/provisioning


rrkelly

thanks that was it -- no zpt -- missed the correct password but i fixed that
thank you very much now i can play with tcpdump and look at it -- 1 packet worth a 1000 words
screen and tcpdump would be nice to add to the basic package
rob