FreePBX + Cisco 7945 'Hello World'


(Yaron) #11

LOL I guess it’s a talent.
I’ve gotten more complex things to work in the past.
Help me make a miracle happen.


(Dave Burgess) #12

Check the /var/log/asterisk/full logs for the phone trying to log in. If you have all of the ports set correctly and the password is short enough (7940 series only allows 8-12 characters) you should see the phone trying to connect.


#13

Sorry, I forgot that newer Cisco firmware supports only TCP for SIP. By default, this is disabled for chan_sip (I have no idea why). Go to Settings -> Asterisk SIP Settings -> Chan SIP Settings, enable TCP, Submit, Apply Config, restart Asterisk (or reboot entire server) and test. With luck you’ll at least see an error in the log.


(Yaron) #14

@Stewart1

I did that (thanks).
Still, Cisco 7945 fails to register and I see nothing in the verbose logs.
I also installed X-Lite on my laptop, and it was able to connect successfully to Asterix (including the relevant log files).
So I guess this narrows it down to - why doesn’t the phone communicate with Asterix, and probably - it doesn’t communicate at all (since it’s not updating the DateTime)… Any way I could verify this assumption from ssh to the phone? or the phone UI ?


#15

Sorry, I know nothing about the command line interface of the phone, but https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuipph/7960g_7940g/sip/4_4/english/administration/guide/ver4_4/siptrb44.html might be close to what you have (though it shows ‘ping’, which isn’t working for you). Try debug sip-messages, etc.

Also, try running Wireshark on the Mac. I believe that if you capture on its Ethernet interface, you will see all packets to/from the VM. Set the display filter to
ip.addr==10.1.0.33
and see whether anything shows up.

Possibly, the phone didn’t like something about the contents of the XML file (and therefore didn’t effect the registration settings), even though no error was logged. The debug commands may help.


(Yaron) #16

Done. The only packet I see, is the phone’s DHCP request.
I am guessing this is either a config issue (my latest config below), OR - a Switch related issue (Cisco 3750G PoE).
All the switch ports are on the same VLAN.

(I’ve set FreePBX IP address to 10.1.0.22)

<?xml version="1.0" encoding="UTF-8"?>
<device xsi:type="axl:XIPPhone" ctiid="1566023366">
    <fullConfig>true</fullConfig>
    <deviceProtocol>SIP</deviceProtocol>
    <sshUserId>cisco</sshUserId>
    <sshPassword>cisco</sshPassword>

    <devicePool>
        <dateTimeSetting>
            <dateTemplate>D-M-Y</dateTemplate>
            <timeZone>Jerusalem Standard/Daylight Time</timeZone>
            <ntps>
                <ntp>
                    <name>timeserver.iix.net.il</name>
                    <ntpMode>Unicast</ntpMode>
                </ntp>
            </ntps>
        </dateTimeSetting>
        <callManagerGroup>
            <members>
                <member priority="0">
                    <callManager>
                        <ports>
                            <sipPort>5160</sipPort>
                        </ports>
                        <processNodeName>10.1.0.22</processNodeName>
                    </callManager>
                </member>
            </members>
        </callManagerGroup>

    </devicePool>
    <sipProfile>
        <natEnabled>false</natEnabled>
        <natAddress></natAddress>

        <sipProxies>
	        <backupProxy></backupProxy> 
			<backupProxyPort></backupProxyPort> 
			<emergencyProxy></emergencyProxy> 
			<emergencyProxyPort></emergencyProxyPort> 
			<outboundProxy></outboundProxy> 
			<outboundProxyPort></outboundProxyPort> 
            <registerWithProxy>true</registerWithProxy>
        </sipProxies>
        
        <preferredCodec>g711alaw</preferredCodec>
        <!--phoneLabel>Y a r o n</phoneLabel-->
        
        <sipCallFeatures>
            <cnfJoinEnabled>true</cnfJoinEnabled>
            <callForwardURI>x--serviceuri-cfwdall</callForwardURI>
            <callPickupURI>x-cisco-serviceuri-pickup</callPickupURI>
            <callPickupListURI>x-cisco-serviceuri-opickup</callPickupListURI>
            <callPickupGroupURI>x-cisco-serviceuri-gpickup</callPickupGroupURI>
            <meetMeServiceURI>x-cisco-serviceuri-meetme</meetMeServiceURI>
            <abbreviatedDialURI>x-cisco-serviceuri-abbrdial</abbreviatedDialURI>
            <rfc2543Hold>false</rfc2543Hold>
            <callHoldRingback>2</callHoldRingback>
            <localCfwdEnable>true</localCfwdEnable>
            <semiAttendedTransfer>true</semiAttendedTransfer>
            <anonymousCallBlock>2</anonymousCallBlock>
            <callerIdBlocking>2</callerIdBlocking>
            <dndControl>0</dndControl>
            <remoteCcEnable>true</remoteCcEnable>
        </sipCallFeatures>
        <sipStack>
            <sipInviteRetx>6</sipInviteRetx>
            <sipRetx>10</sipRetx>
            <timerInviteExpires>180</timerInviteExpires>
            <timerRegisterExpires>180</timerRegisterExpires>
            <!-- Force short registration timeout to keep NAT connection alive -->
            <timerRegisterDelta>5</timerRegisterDelta>
            <timerKeepAliveExpires>120</timerKeepAliveExpires>
            <timerSubscribeExpires>120</timerSubscribeExpires>
            <timerSubscribeDelta>5</timerSubscribeDelta>
            <timerT1>500</timerT1>
            <timerT2>4000</timerT2>
            <maxRedirects>70</maxRedirects>
            <remotePartyID>false</remotePartyID>
            <userInfo>None</userInfo>
        </sipStack>
        
        <sipLines>
            <!-- Add lines here -->
            <line button="1">
                <featureID>9</featureID>
                <featureLabel>Line 1</featureLabel>
                <!-- Displays next to Line Number -->
                <name>100</name>
                <!-- SIP username -->
                <displayName>Line 1</displayName>
                <!-- Name to display on outbound caller ID -->
                <!-- SIP username again -->
                <proxy>10.1.0.22</proxy>
                <!-- SIP server -->
                <port>5160</port>
                <!-- AUTH -->
                <authName>100</authName>
                <!-- auth SIP username same as <name>-->
                <authPassword>********</authPassword>
                <messageWaitingLampPolicy>1</messageWaitingLampPolicy>
                <messagesNumber>*97</messagesNumber>              

            </line>
            <line button="2">
                <featureID>2</featureID>
                <featureLabel>Line 2</featureLabel>
                <speedDialNumber>86555</speedDialNumber>
            </line>
        </sipLines>
        <dialTemplate>dialplan.xml</dialTemplate>
        <voipControlPort>5160</voipControlPort>
    </sipProfile>
    <vendorConfig>
        <sshAccess>0</sshAccess>
        <sshPort>22</sshPort>
     	<pcPort>0</pcPort>
     	<settingsAccess>1</settingsAccess>
     	<garp>0</garp>
     	<webAccess>0</webAccess>
     	<spanToPCPort>1</spanToPCPort>
     	<loggingDisplay>2</loggingDisplay>
    </vendorConfig>
    <transportLayerProtocol>2</transportLayerProtocol>
</device>

(Tom Ray) #17

And the pbx and phones are on the same VLAN? Or you have it so tags are stripped? Or that the VLANs can talk to each other?


#18

That’s a broadcast packet which would show up anywhere on the LAN.
Confirm that the capture is working as expected, by pinging the phone from the VM and seeing the ICMP request and the reply in Wireshark.

Assuming that it is, your switch should be able to mirror all traffic to/from the phone to another port for analysis. Unfortunately, Cisco switches have a security feature (which can’t be disabled) that prevents the destination port from carrying normal traffic. Do you have another computer that can run Wireshark? Or, can you set up two NICs on the Mac, e.g. connect to your LAN by Wi-Fi and use the Ethernet port for the capture? See chapter 28 of https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/release/12-2_35_se/configuration/guide/scg.pdf .

I assume that you have Voice VLAN disabled, since that has its own complexity.

+1


(Tom Ray) #19

Here is the real solution to this problem: https://www.voipsupply.com/cisco-spa303g

You buy a real SIP phone that isn’t EOL, designed for a specific PBX and well isn’t running a “hack” of a SIP stack.


(Yaron) #20

Just to explain my rational:
The thing is, I have a box of 20 new, never opened Cisco 7945.
If you buy them from me, I can afford to buy real sip phones that are not EOL :wink:

I am a hacker. Hacking for me is a way to satisfy curiosity, while learning a new space and having fun. And ideally, solving a practical problem. Last time I took a similar project, it ended up with me starting a new company and inventing a whole new way to manage cloud infrastructure.

BTW this setup is for my home, not for a business. Obviously for a business I would take a different approach.


(Yaron) #21

BOOM.

I think I nailed it.
Following this post: https://www.voip-info.org/asterisk-phone-cisco-79x1-xml-configuration-files-for-sip#PhoneFirmware - I set <proxy> to USECALLMANAGER (literally - previously it was set to the IP address of FreePBX).
Phone registered!!

@cynjut - Hello world. What a wonderful world :slight_smile:
All - thank you very much, (I may have some follow up questions though - appreciate your continued help in case I do)


(Tom Ray) #22

Well I can save you some trouble. If you didnt install the CallManager patch most features wont work because, well, Cisco. Again, as I explained before these phones where designed for a specific platform the UCM. Even with the SIP firmware it sends things with headers and values that are not SIP RFC.


#23

You can also install sccp-b channel and use the phone with sccp firmware.


(Yaron) #24

Which important features that you know of, which will not work with SIP 9.4.2 SE2 ? (are you sure?)
And @arielgrin - thanks btw, will these features work on sccp-b ?


(Tom Ray) #25

Check out http://usecallmanager.nz/document-overview.html it outlines all the features that require the patch in order to work properly on Asterisk. BLF, Call Pickup CID, Park, etc. The maintainer of the patch is generally 3-6 months (or more) behind or so on the Asterisk version it is valid for. Currently it is patched for 13.21.1 (from June) while 13 is currently at 13.23.1 (from late Oct).

That would require you to make sure your Asterisk version is 13.21.1. There was no updates for 14 or 15 but that could be because they were just “Stable” and not “LTS”. 16 is LTS but only came out in Oct so it might not be until early 2019 for there to be a 16 version (if at all).

From what I can see in the documentation for this as well, it’s 100% Chan_SIP with nothing for PJSIP which isn’t encouraging with Chan_SIP being deprecated and its possible removal down the road. Plus the fact that Chan_SIP is also 100% community driven now, so if there are new bugs found or updates needed for this to work (or anything for Chan_SIP to work) the community has to be the ones to do and submit patches to Digium to be accepted and merged.


#26

Not sure here, @cynjut probably knows best, but I think SCCP-B channel gets you almost all functionality, or at least the most desired ones.


(F Smith) #27

What is it with this board? I have not visited here in a long long time because of negative comments like this. Imagine what someone must think when they are just finding out about SIP trunks and Asterisk and they are met with combative answers to legitimate beginner questions. There are a lot of users that have the technical know how to implement something like this but just need to be pointed in the right direction.


(Tom Ray) #28

Negative comments like what? Recommending a low-cost alternative that would make all these items a non-issue is negative? After the OP explained he had almost 2 dozen brand new ones and wanted to use them, I reminded them that they need the CallManager patch to make functions work and then provided the link to said patch. How is that negative? Was it also negative when I pointed out the caveats and considerations of using the CallManager patch to make those functions work?

I fail to see how any of what I have said, or anyone else that has contributed, is negative outside of the fact things where pointed out to give the OP a heads up/FYI on how these phones actually work with Asterisk and the TLC that is going to be required to make it a continued thing.

What I do see as a negative comment is someone posting in the thread that isn’t actually contributing to it in anyway but “attacking” the contributors about how they are just “negative” and “ruin the forum”.


(Dave Burgess) #29

Just so we’re clear:

  • The 7940 series phone is one of the hardest to get working.
  • Using reliably with SIP requires additional, unsupported patches to Asterisk.
  • This guy is running all of this on a Mac.

So, he has taken the hardest phone there is to get working, added the complexity of having to patch Asterisk, and then wants to run it all on a Mac. These are not “beginner” questions. Crap, I’ve been doing this for 15+ years, and I wouldn’t undertake this on a dare. Will we (and did we) help? I think so. Would we recommend the average new user try this? Not a chance.

I don’t think we attacked anyone - there was one response about getting better phones. For a business user, that would be a valid and (eventually) fiscally responsible approach to solving the problem. Even the recommendation to use Chan-SCCP-B was constructive, since Asterisk doesn’t need to be patched to use it and provides the full capability set of the phones “out of the box”. Once he identified himself as a hobbyist (and therefore “into the challenge”, the conversation turned to “here’s the pain the rest of us found on this journey.”

The obligatory car analogy: we have a forum about driving and fixing cars. The OP asked a question about supercharging a snow-mobile and driving along the roof of the Holland Tunnel. Yes, you can do it, but … Really?

@Ami_mac - I see that you’ve asked a lot of questions about the Cisco UCM phones over the past three years, so you should know the pain of this entire discussion as well as any of us. With the movement away from Chan-SIP, I expect lots of people are going to be coming to this forum and trying to find out how to get their BLF working again under the new system.

When that happens, I expect we’ll see the same basic answers about old Cisco phones again:

  • Don’t do that - it’s too painful
  • Cisco makes newer better phones.
  • There is a community independent driver that supports them but isn’t part of FreePBX.
  • The phones aren’t even standard conformant when flashed to SIP, so they are a nightmare.
  • Now that we’re done with the warnings, here are your solution spaces.

I try really hard to not be negative towards posters because I have a reputation to maintain. I try to give people answers that will help them find their own way through their problems. Sometimes, this means holding their hand step by step, and other times it’s as simple as “Yes, and start looking for ‘This’.”. For the most part, this thread hasn’t deviated too far from that goal.


(system) closed #30

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.