12-21-2021 06:36 AM
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?
12-22-2021 01:18 AM
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?
12-22-2021 05:08 AM
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.
12-22-2021 06:01 AM
Thanks Chris. Suspected that. Just have to love service providers. <irony>
12-23-2021 01:17 AM
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.
12-23-2021 08:55 AM
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.
12-23-2021 09:10 AM
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.
12-23-2021 09:47 AM
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.
12-27-2021 01:02 AM
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 ---
05-31-2023 12:25 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide