TATA SIP Trunk registration issue

Chris Deren · ‎12-21-2021

I have a SIP trunk in India with TATA which I cannot get registered and the provider is of no help. The relevant config is here:

sip-ua
credentials number XXXXXXXXXXXXXX username XXXXXXXXXXXXXX password 7 YYYY realm SIP-XXXXXXXXXXXXXX
authentication username XXXXXXXXXXXXXX password 7 YYYY realm SIP-XXXXXXXXXXXXXX
no remote-party-id
retry invite 3
retry register 3
timers connect 100
registrar 1 ipv4:<ip>:<port> expires 300
sip-server ipv4:<ip>:<port>
registration spike 50
connection-reuse

TATA responds to initial REGISTER with 401 Unauthorized challenge as expected:

REGISTER sip:<ip>:<port> SIP/2.0
Via: SIP/2.0/UDP 10.52.83.186:5060;branch=z9hG4bK322714F9
From: <sip:XXXXXXXXXXXXXX@<ip>>;tag=A711BCC8-2066
To: <sip:XXXXXXXXXXXXXX@<ip>>
Date: Tue, 21 Dec 2021 14:03:59 GMT
Call-ID: FFFFFFFFACE1006C-619D11EC-FFFFFFFF97F3BEC8-FFFFFFFFB0EBF35D
User-Agent: Cisco-SIPGateway/IOS-16.6.4
Max-Forwards: 70
Timestamp: 1640095439
CSeq: 2 REGISTER
Contact: <sip:XXXXXXXXXXXXXX@10.52.83.186:5060>
Expires: 300
Supported: path
Content-Length: 0

063755: Dec 21 23:03:59.492 India: //30993/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
WWW-Authenticate:Digest realm="XXXXXXXXXXXXXX@ngn.ttl.in",nonce="E2353C0A61C1DECF7F35FB966B8789FD",stale=FALSE,algorithm=MD5
Via: SIP/2.0/UDP 10.52.83.186:5060;branch=z9hG4bK322714F9
Call-ID:FFFFFFFFACE1006C-619D11EC-FFFFFFFF97F3BEC8-FFFFFFFFB0EBF35D
CSeq:2 REGISTER
From:<sip:XXXXXXXXXXXXXX@<ip>>;tag=A711BCC8-2066
To:<sip:XXXXXXXXXXXXXX@<ip>>;tag=uc94690D09
Content-Length:0

And nothing happens after that, my understanding is that CUBE expects the REALM to match my digest domain (SIP-XXXXXXXXXXXXXX) yet TATA responds with ngn.ttl.in, hence to follow up register. If I remove REALM from authentication config I get 403 Forbidden back from them.

In their documentation they state:

In response to Register msg from PBX/Server/CPE (Msg-1) initial registration message is challenged as part of the digest authentication method sent by SBC to PBX with nonce

SIP user should send the Register msg again to TATA UT SBC in response of the challenge MSG 2 include digest/realm/nonce.

Am I missing something here on my side as this clearly seems to be an issue on their side to me?

Roger Kallberg · ‎12-22-2021

How sure are you about the correctness of your realm configuration? I assume that you already have tried to use what you get in the response from TATA as the realm?

Chris Deren · ‎12-22-2021

Thanks for responding Roger. I've asked multiple times for confirmation, but they just respond with an email and sample PPT showing what the SIP messages should look like. I have tried several variations with the same results. Using ngn.ttl.in results in 403 Forbidden response from them.

Roger Kallberg · ‎12-22-2021

Thanks Chris. Suspected that. Just have to love service providers. <irony>

TONY SMITH · ‎12-23-2021

We did a Tata SIP connection a while ago. I don't have live access to the site at the moment but I have a saved configuration. The registration configuration is a little different but I think has the same end result, assuming your "number" and "username" are actually the same value in the credentials line. We had ...

sip-ua
 credentials username <PILOT> password 7 <PWD> realm SIP-<PILOT>
 authentication username <PILOT> password 7 <PWD> realm SIP-<PILOT>
 no remote-party-id
 retry invite 2
 retry response 3
 retry bye 3
 retry prack 6
 retry register 5
 retry options 10
 timers trying 350
 registrar ipv4:<IP> expires 600
 sip-server ipv4:<IP>
 registration spike 50
 host-registrar
!

I can't remember registration being an issue so I may not have any debugs saved, but I'll have a look.

Don't know how much help this is.

Scott Leport · ‎12-23-2021

Hi,

We also worked on a Tata SIP trunk a few months ago and went through a lot of effort to get our customers SIP trunk registered. In my situation, they had originally supplied an insecure password, which we insisted they change. They said they had changed it, we couldn’t get the trunk registered and of course they said it was our configuration. I took a chance that they hadn’t changed the password. Modified the SIP auth and reg config with the first password they supplied and the trunk was now registered!

Not sure if your situation is the same. If it is, you might want to give that a try and check again.

FYI, we also used “ngn.ttl.in” in our realm config too.

Chris Deren · ‎12-23-2021

Thanks Scott, are you saying you needed to define ngn.ttl.in under your credentials and authentication configuration rather than what TATA states in their communication as SIP-XXXXXXXXXXXXXX where XXXXXXXXXXXXXX is the Pilot number?

When I leave out the realm domain per RFC implementation CUBE responds to the 401 challenge automatically with the realm they responded with, but that for me leads to 403 forbidden message from them.

Scott Leport · ‎12-23-2021

Hi Chris,

I am not in a position to check the config at the moment, but from memory the realm was configured with 123456789@ngn.ttl.in

123456789 being the pilot number in my example above.

b.winter · ‎12-27-2021

Hello @Chris Deren,

as @Scott Leport said, you have to use a realm in the form of "".

As a hint, if you are not sure, which realm to use, just check the message coming back from the provider. This message includes the realm:

063755: Dec 21 23:03:59.492 India: //30993/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
WWW-Authenticate:Digest realm="XXXXXXXXXXXXXX@ngn.ttl.in",nonce="E2353C0A61C1DECF7F35FB966B8789FD",stale=FALSE,algorithm=MD5
Via: SIP/2.0/UDP 10.52.83.186:5060;branch=z9hG4bK322714F9
Call-ID:FFFFFFFFACE1006C-619D11EC-FFFFFFFF97F3BEC8-FFFFFFFFB0EBF35D
CSeq:2 REGISTER
From:<sip:XXXXXXXXXXXXXX@<ip>>;tag=A711BCC8-2066
To:<sip:XXXXXXXXXXXXXX@<ip>>;tag=uc94690D09
Content-Length:0

FYI:

If the under the credentials command and the authentication command is the same, the login (username/pwd) from the credentials command is used.

This is due to an internal priority.

Therefore, if both commands have the same realm, then you can leave out the authentication command, since it will never be used.

For the "403 Forbidden":

Maybe the username/pwd is wrong, or that your REGISTER messages are not correctly formatted.

Do you have a trace? Without any masked fields?

--- Please rate this post as "Helpful" or accept as a solution, if your question has been answered ---

aniket0422 · ‎05-31-2023

Below is the working configuration for TATA SIP Trunk.

voice class tenant 100
registrar 1 ipv4:10.60.XX.XX:5061 expires 120 - This is TATA SBC IP address
credentials number 0091XXXXXXX100 username 0091XXXXXXX100@10.60.XX.XX password 0 XXXXX realm 0091XXXXXXX100@ngn.ttl.in
authentication username 0091XXXXXXX100@10.60.XX.XX password 0 XXXX
no remote-party-id
retry invite 5
retry bye 2
retry cancel 2
retry options 10
timers trying 550
timers expires 60000
timers connect 100
no timers hold
timers register 1000
timers buffer-invite 5000
notify telephone-event max-duration 2000
reason-header override
connection-reuse
session transport udp
url sip
error-passthru
bind control source-interface GigabitEthernet0/0/1 -- TATA SIP trunk Interface
bind media source-interface GigabitEthernet0/0/1 -- TATA SIP trunk Interface
no pass-thru content custom-sdp
outbound-proxy ipv4:10.60.xx.xx:5061
early-offer forced