cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1333
Views
0
Helpful
4
Replies

SIP Trunk registration issue on CUBE

CWD
Level 1
Level 1

Hi all

 

i have some troubles with SIP Trunk registration to a local provider.

 

Options ping is enabled on the CUBE and SP answers with a SIP/2.0 403 not registered message to the opption ping.

 

Normally i would think next step should be a REGISTER message without authorization header following by an authorization request SIP/2.0 401 Unauthorized from SP.

 

Unfortunately CUBE directly sends an Authorization header but with blank nonce which the SP switch does not accept leading to a failed attempt.

 

Is there a way to configure CUBE to send Authorization header only when prompted from SP or to at least remove it from first REGISTER message?

 

Aug 23 12:37:16.934: //740632/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 403 not registered
Call-ID: CFBDFBE0-C4C811E9-82F39227-303A6B83@55.55.55.66
CSeq: 101 OPTIONS
From: <sip:55.55.55.66>;tag=6B9CC828-5F0
To: <sip:55.55.55.55>;tag=03-32766-0099419f-60c9fd227
Via: SIP/2.0/UDP 55.55.55.66:5060;received=55.55.55.66;branch=z9hG4bK3D70E1F30
Content-Length: 0


Aug 23 12:37:31.539: //740639/000000000000/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:55.55.55.55:5060 SIP/2.0
Via: SIP/2.0/UDP 55.55.55.66:5060;branch=z9hG4bK3D70F1F90
From: <sip:0551999666@55.55.55.55>;tag=6B9D01AB1
To: <sip:0551999666@55.55.55.55>
Date: Fri, 23 Aug 2019 10:37:31 GMT
Call-ID: E4E1E9D2-B9AF11E9-99E89227-303A6B83
User-Agent: Cisco-SIPGateway/IOS-15.6.3.M6a
Max-Forwards: 70
Timestamp: 1566556651
CSeq: 10170 REGISTER
Contact: <sip:55.55.55.66:5060;bnc>
Expires: 240
Supported: path
Authorization: Digest username="0551999666",realm="Provider.FQDN",uri="sip:55.55.55.55:5060",response="",nonce=""
Content-Length: 0


Aug 23 12:37:31.539: //740639/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Call-ID: E4E1E9D2-B9AF11E9-99E89227-303A6B83
CSeq: 10170 REGISTER
From: <sip:0551999666@55.55.55.55>;tag=6B9D0134-AB1
To: <sip:0551999666@55.55.55.55>
Via: SIP/2.0/UDP 55.55.55.66:5060;received=55.55.55.66;branch=z9hG4bK3D70F1F90
Content-Length: 0


Aug 23 12:37:31.539: //740639/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 404 Domain not bound
Call-ID: E4E1E9D2-B9AF11E9-99E89227-303A6B83
CSeq: 10170 REGISTER
From: <sip:0551999666@55.55.55.55>;tag=6B9D0134-AB1
To: <sip:0551999666@55.55.55.55>;tag=00-08190-00b2b4ef-463e43123
Via: SIP/2.0/UDP 55.55.55.66:5060;branch=z9hG4bK3D70F1F90
Server: Cirpack/v4.76 (gw_sip)
Content-Length: 0

4 Replies 4

Thorwald_L.9216
Level 1
Level 1
Hi

could you not just remove the authorization Header of the REGISTER message?

Prassha
Level 1
Level 1
Hello CWD

As you mentioned correctly authorization header is creating problem here as your provider is not aware of digest creds.

Once you remove the Digest credentials, you will have ack for register message.

Regards
Prassha3
Rate if you find this helpful

Regards
Prassha3
Rate if you find this helpful

Rate if you find this helpful or Mark Solutions as Accepted

Yeah sure but should there not be a way to correct this behavior without a bunch of sip-profile manipulations? It is only the first REGISTER that should not include Authorization

2019-08-26 17_15_22-sip-config-15-mt-book.pdf - Adobe Acrobat Reader DC.png

Looking into the screenshot above taken from IOS 15 SIP Configuration guide there should be no Authorization Header in initial REGISTER and i hoped there was a simple solution just to get it to work like it should and is described

CWD

 

Not sure if you have taken this screen shots from IOS 15 solution guide but I have seen this scenario for third party SIP phones and when we have Digest Credentials enable. So whenever Digest credentials comes into the picture UAS (SIP Server) rejects the first register message from UAC as per RFC guide [RFC3261] 

Basically UAS is challenging the authenticity of the register messages and in the second register message Digest user creds and MD5 algorithm is exchanged. You can try decoding the first register and second register message you will see the difference and it seems to be as per SIP RFC. This is working as design when you enable the authorization.

 

In order to make it work your provider need to be aware of the same which is not quite easy here in case of provider.

 

 

Regards
Prassha3
Rate if you find this helpful

Rate if you find this helpful or Mark Solutions as Accepted
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: