CCME Internal extensions registering with external SIP trunk

[tgregorics]

Hi,

We have set up a CME with 8 internal SCCP extensions and 3 SIP extensions. After adding the SIP trunk to our provider I noticed that my extensions are trying to register with the provider. Even my MWI On/Off extension is trying to register with the trunk provider!

Provider not too happy about it.

Any idea what could I have missed in the configuration?

Debug:

6941 SCCP phone extension:

Sent:
REGISTER sip:sip.provider.hu:5060 SIP/2.0
Via: SIP/2.0/UDP XXX.XX.112.116:5060;branch=z9hG4bK4FA68F4A
From: <sip:1404@sip.provider.hu>;tag=DC8D53D4-CE6
To: <sip:1404@sip.provider.hu>
Date: Wed, 10 Sep 2014 10:14:27 GMT
Call-ID: FC4E977E-166311E4-8043C383-656087A6
User-Agent: Cisco-SIPGateway/IOS-15.3.3.M2
Max-Forwards: 70
Timestamp: 1410344067
CSeq: 15415 REGISTER
Contact: <sip:1404@XXX.XX.112.116:5060>
Expires:  300
Supported: path
Content-Length: 0

883929: Sep 10 12:14:27.828: //305320/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP XXX.XX.112.116:5060;branch=z9hG4bK4FA68F4A;rport=60819;received=XXX.XX.112.116
From: <sip:1404@sip.provider.hu>;tag=DC8D53D4-CE6
To: <sip:1404@sip.provider.hu>
Call-ID: FC4E977E-166311E4-8043C383-656087A6
CSeq: 15415 REGISTER
Server: Kamailio (1.4.1-notls (i386/linux))
Content-Length: 0

883930: Sep 10 12:14:27.828: //305320/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP XXX.XX.112.116:5060;branch=z9hG4bK4FA68F4A;rport=60819;received=XXX.XX.112.116
From: <sip:1404@sip.provider.hu>;tag=DC8D53D4-CE6
To: <sip:1404@sip.provider.hu>;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.c6e1
Call-ID: FC4E977E-166311E4-8043C383-656087A6
CSeq: 15415 REGISTER
Contact: <sip:1404@XXX.XX.112.116:5060>;q=0;expires=300;received="sip:XXX.XX.112.116:60819"
Server: Kamailio (1.4.1-notls (i386/linux))
Content-Length: 0

MXI extension:

883987: Sep 10 12:15:35.649: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:sip.provider.hu:5060 SIP/2.0
Via: SIP/2.0/UDP XXX.XX.112.116:5060;branch=z9hG4bK4FA7410B9
From: <sip:8000....@sip.provider.hu>;tag=DC8E5CE0-6C7
To: <sip:8000....@sip.provider.hu>
Date: Wed, 10 Sep 2014 10:15:35 GMT
Call-ID: FC4F33A6-166311E4-8049C383-656087A6
User-Agent: Cisco-SIPGateway/IOS-15.3.3.M2
Max-Forwards: 70
Timestamp: 1410344135
CSeq: 15415 REGISTER
Contact: <sip:8000....@XXX.XX.112.116:5060>
Expires:  300
Supported: path
Content-Length: 0

883991: Sep 10 12:15:35.681: //305332/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP XXX.XX.112.116:5060;branch=z9hG4bK4FA7410B9;rport=60819;received=XXX.XX.112.116
From: <sip:8000....@sip.provider.hu>;tag=DC8E5CE0-6C7
To: <sip:8000....@sip.provider.hu>
Call-ID: FC4F33A6-166311E4-8049C383-656087A6
CSeq: 15415 REGISTER
Server: Kamailio (1.4.1-notls (i386/linux))
Content-Length: 0

884007: Sep 10 12:15:55.594: //305336/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP XXX.XX.112.116:5060;branch=z9hG4bK4FA78233;rport=60819;received=XXX.XX.112.116
From: <sip:8001....@sip.provider.hu>;tag=DC8EAAA8-14C3
To: <sip:8001....@sip.provider.hu>;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.c0be
Call-ID: FC4F33A6-166311E4-804AC383-656087A6
CSeq: 15415 REGISTER
Contact: <sip:8001....@XXX.XX.112.116:5060>;q=0;expires=300;received="sip:XXX.XX.112.116:60819"
Server: Kamailio (1.4.1-notls (i386/linux))
Content-Length: 0

Edit: attached config.

[Tony]

Check out your SIP UA config section.  You have a SIP registrar configured which is causing your phones to attempt to register with a SIP Proxy/Registrar server.

[tgregorics]

But if I remove that line, wouldn't it make my sip trunk line stop working?

[Suresh Subramanian · Accepted solution]

Hi,

can you try the keyword  "no-reg both" after max-dn 50 and check please?

Router(config-telephony)# max-dn 50 no-reg both

[tgregorics]

Unfortunately that did not help.

[Suresh Subramanian]

Please try adding no-reg after the number under ephone-dn configuration and check. Example ephone-dn 7 dual-line number 1404 no-reg You need to do this for all the numbers under all the ephone-dn

[tgregorics]

I did just that, but nothing changed. Also, I can't seem to add the no-reg parameter to my SIP phone definitions (voice register dn) anyway.

[Carlo Poggiarelli]

Hi.

After you applied no-reg under voice register dn, did you try to go under voice register global and issue the command "create profile" and reset the phone?

Let us know

Regards

Carlo

[Jesutofunmi O]

I have been on this for months. My ITSP was blacklisting my IP because they were receiving multiple register requests from my CME. All 60 phones on my CME were sending reg requests to ITSP. 

Your solution worked for me.
I issued a "no-reg both" command after the "max-dn" in telephony-service and I also went under every ephone-dn and used the "no-reg both" command (my lines are dual lines).

Thank you, you are star!!!

Sample below for others that may have the same issue in the furture;

telephony-service 

max-dn 20 no-reg both  (you can add both or not)

ephone-dn 1
number 2xx no-reg 

[Jesutofunmi O]

I have been on this for months. My ITSP was blacklisting my IP because they were receiving multiple register requests from my CME. All 60 phones on my CME were sending reg requests to ITSP. 

Your solution worked for me.
I issued a "no-reg both" command after the "max-dn" in telephony-service and I also went under every ephone-dn and used the "no-reg both" command (my lines are dual lines).

Thank you, you are star!!!

Sample below for others that may have the same issue in the furture;

telephony-service 

max-dn 20 no-reg both  (you can add both or not)

ephone-dn 1
number 2xx no-reg 

[tgregorics]

Hi,

Actually, It is working now (not sure if recreating the cnf files or the phone restart did the trick).

My only problem: SCCP phones are ok, but the SIP phones are still trying to register with the sip proxy. Can't use the no-reg parameter with those.

Any idea?

[tgregorics]

Fixed the SIP reg problem too:

voice register dn  1
 number 1001
 huntstop
 no-reg

[Suresh Subramanian]

Good to know you fixed the issue, Thanks for the update :)