Re: SIP registration failure

pcanters · ‎07-12-2010

I am having a problem getting my 2821 gateway to register with a SIP server.

I am able to use a publicly available sip client to verify the username/passwordthat I am trying to register with

The public client (xlite) seems tohave no issues and registers just fine but I can't get the gateway to register.

A debug ccsip message gives me the following:

001413: Jul 12 22:25:29.767 GMT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:91.195.160.3:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.150.1:5060;branch=z9hG4bK4B1214
From: <sip:311xxxxxxxx@91.195.160.3>;tag=EEF425DC-31
To: <sip:311xxxxxxxx@91.195.160.3>
Date: Mon, 12 Jul 2010 20:25:29 GMT
Call-ID: C6E43A7-8D2911DF-80A5D386-E41803AB
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
Timestamp: 1278966329
CSeq: 7 REGISTER
Contact: <sip:311xxxxxxxx@10.1.150.1:5060>
Expires: 600
Content-Length: 0

001414: Jul 12 22:25:29.991 GMT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.1.150.1:5060;branch=z9hG4bK4B1214;received=209.190.187.36;rport=62087
To: <sip:311xxxxxxxx@91.195.160.3>;tag=ac82353c
From: <sip:311xxxxxxxx@91.195.160.3>;tag=EEF425DC-31
Call-ID: C6E43A7-8D2911DF-80A5D386-E41803AB
CSeq: 7 REGISTER
WWW-Authenticate: Digest nonce="1278966329:cad9ef602d872b069e412533000bb6e9",algorithm=MD5,realm="91.195.160.3"
Content-Length: 0

I know that the username and password are correct...what else could be failing me here ??

Why can't the gateway register but a client can

Note: I have taken this gateway and set it up in my firewall with a static IP address.

I have allowed udp 5060 and port 16363 through 32767 access to it for now.

My sip-ua

sip-ua
credentials username 311xxxxxxxx password 7 11000H0D49061E7810 realm sipnl.net
authentication username 311xxxxxxxx password 7 151H1F440A373E703C realm sipnl.net
no remote-party-id
retry invite 2
retry register 10
timers connect 100
registrar ipv4:91.195.160.3 expires 600
sip-server ipv4:91.195.160.3
host-registrar

TIA

ADAM CRISP · ‎07-16-2010

Hi,

It's normal for an initial Registration message to be challanged as part of the digest authentication method.

There should be a second registration message sent from your router immediately after the 401 including digest.

However the service provider is asking for the digest realm to be: algorithm=MD5,realm="91.195.160.3"

and you don't that realm configured under sip-ua - you have realm "sipnl.net"

To fix this, change the realm to 91.195.160.3 - or leave the realm missing. I would be tempted to just miss the realm part out, because I think the SP has make a mistake....

Adam

pcanters · ‎07-16-2010

Thanks for the response Adam,

getting closer.

Neither removing teh realm completly nor adding the ip address as a realm got me a succesful connection.

Here is a debug trace with the realm as the IP address as you suggested.

Any more thoughts ???

TIA

006441: Jul 16 22:45:04.011 GMT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:0653786319@sip.sipnl.net:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.150.1:5060;branch=z9hG4bK4D71532
From: <>31172722478@sip.sipnl.net>;tag=14945474-BF7
To: <>0653786319@sip.sipnl.net>
Date: Fri, 16 Jul 2010 20:45:04 GMT
Call-ID: D804DB58-905111DF-81319897-D4085B48@10.1.150.1
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 16245760-3485729220-402660865-1148054850
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1279313104
Contact: <31172722478>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 241

v=0
o=CiscoSystemsSIP-GW-UserAgent 7905 6834 IN IP4 10.1.150.1
s=SIP Call
c=IN IP4 10.1.150.1
t=0 0
m=audio 19220 RTP/AVP 0 101
c=IN IP4 10.1.150.1
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

006442: Jul 16 22:45:04.231 GMT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.1.150.1:5060;branch=z9hG4bK4D71532;received=209.190.187.36;rport=54924
To: <>0653786319@sip.sipnl.net>
From: <>31172722478@sip.sipnl.net>;tag=14945474-BF7
Call-ID: D804DB58-905111DF-81319897-D4085B48@10.1.150.1
CSeq: 101 INVITE
Content-Length: 0

006443: Jul 16 22:45:04.311 GMT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 10.1.150.1:5060;received=209.190.187.36;branch=z9hG4bK4D71532;rport=54924
Record-Route: <91.195.160.3>
To: <>0653786319@sip.sipnl.net>;tag=hlbnydzu4hg2ld6i.i
From: <>31172722478@sip.sipnl.net>;tag=14945474-BF7
Call-ID: D804DB58-905111DF-81319897-D4085B48@10.1.150.1
CSeq: 101 INVITE
Content-Type: application/sdp
Server: Sippy
Content-Length: 229

v=0
o=Sippy 230733964 1 IN IP4 91.195.160.3
s=session
t=0 0
m=audio 44806 RTP/AVP 0 101
c=IN IP4 91.195.160.3
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=sendrecv

006444: Jul 16 22:45:10.487 GMT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
CANCEL sip:0653786319@sip.sipnl.net:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.150.1:5060;branch=z9hG4bK4D71532
From: <>31172722478@sip.sipnl.net>;tag=14945474-BF7
To: <>0653786319@sip.sipnl.net>
Date: Fri, 16 Jul 2010 20:45:04 GMT
Call-ID: D804DB58-905111DF-81319897-D4085B48@10.1.150.1
CSeq: 101 CANCEL
Max-Forwards: 70
Timestamp: 1279313110
Reason: Q.850;cause=16
Content-Length: 0

006445: Jul 16 22:45:10.703 GMT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.150.1:5060;branch=z9hG4bK4D71532;received=209.190.187.36;rport=54924
To: <>0653786319@sip.sipnl.net>
From: <>31172722478@sip.sipnl.net>;tag=14945474-BF7
Call-ID: D804DB58-905111DF-81319897-D4085B48@10.1.150.1
CSeq: 101 CANCEL
Content-Length: 0

006446: Jul 16 22:45:10.711 GMT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 10.1.150.1:5060;received=209.190.187.36;branch=z9hG4bK4D71532;rport=54924
Record-Route: <91.195.160.3>
To: <>0653786319@sip.sipnl.net>
From: <>31172722478@sip.sipnl.net>;tag=14945474-BF7
Call-ID: D804DB58-905111DF-81319897-D4085B48@10.1.150.1
CSeq: 101 INVITE
Server: Sippy
Content-Length: 0

006447: Jul 16 22:45:10.711 GMT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:0653786319@sip.sipnl.net:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.150.1:5060;branch=z9hG4bK4D71532
From: <>31172722478@sip.sipnl.net>;tag=14945474-BF7
To: <>0653786319@sip.sipnl.net>
Date: Fri, 16 Jul 2010 20:45:04 GMT
Call-ID: D804DB58-905111DF-81319897-D4085B48@10.1.150.1
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Length: 0

006448: Jul 16 22:45:13.167 GMT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:

ADAM CRISP · ‎07-17-2010

Hi,

Did it register OK, your trace shows a call being placed?

What was the problem with the call? There's nothing wrong with the trace really.

We have a SIP invite that's not challenged. Does this mean your SP is using IP authentication?

This is then followed by a 100 trying and then Session progress with Media (ring ring sound is sent from the remote end)

and then before the call is connected you hang up.

So what was wrong ?

thanks

pcanters · ‎07-19-2010

Adam,

I am registered but the call is getting rejected.

A trace from the SIP server shows that authentication is not correct.

They can't tell me what is not correct other than I am not presenting the right credentials.

TAC thinks that we are sending what is required.....thus I am at a standstill.

I have tried IP address,realm name, no name...every possible combination without success

Don't know what needs fixing other then they tell me it is broken....which I know.

I think I am going to try with another switch/provider

Thanks for the help Adam

ADAM CRISP · ‎07-20-2010

No problem at all. If you're in the UK I can help you with SIP trunks.

But before you give up with your provider, it's odd that you can register (and authenticate) but can't authenticate an Invite.

Off the wall reasons I can think of are:

1. There's a really low MTU in the network somewhere that might be blocking UDP based SIP messages. A trace from your SP will rule this out.

2. Have you an outbound proxy configured on your outbound dial-peer which is routing calls to the wrong place ?

good luck.

Adam

pcanters · ‎07-20-2010

Funny as the provider that I am having issues with is in The Netherlands.

I felt like I was pretty close being registered and all. The calls kept getting rejected and the provider could just give me no real reason as to why.

As to a low MTU, I suppose that this is possible as the SIP session is actually going across multiple continents (test environment) and more than likely some smalle, more contentious internet pipes.

I don't think it's a proxy issue.

Ihave verified with the provider as to valid/expected inbound and outbound IP addresses so as to make sure that I was not blocking SIP return traffic coming from different proxied servers. As far as that goes,I think I am beating a dead horse.

It also appears that there is no known Cisco gateway integration, that would be another issue.

I am moving onto a Broadsoft platform that should be much better supported and hopefully easier to integrate with

Thanks for all the help Adam

scd2zaken · ‎09-11-2010

Dears,

I've got the same problem with sipnl.net in the Netherlands .. on the UC520.

When I check the connection information at ISP site .. I will see that the username (who must have 31xxx) is not correct activated at

ISP site..

Every call is dropped, and the error messages will give SIP/2.0 404 Not Found
So far I can see meens that, that the registration at the provider is not done in the correct way.

I think the problem will be in the authentication steps in the sip-ua area.
Is their anybody who know more about registration with the UC500 series on the ISP , sipnl.net in the Netherlands ?

Regards,

Eric Oosterbaan

ADAM CRISP · ‎09-11-2010

Hi Eric, If you don't get a response from anybody using sipnl, see if you can get the connection working with a softphone and then compare to your cisco.

feel free to capture the output of debug ccsip messages....

pcanters · ‎09-13-2010

I went down this( the Adam crisp suggestion) exact path to attempt to debug the sipnl provider.

I was able to get the Xlite client to come up just fine

As far as TAC was concerned we looked fine and we faithfully reproduced what we saw in the traces from the sofphone client.

TAC came back and said that we need to hear from sipnl what it is that is failing auth.

Sipnl never able to supply that info as I was never able to get anyone to be on the softswitch to tell me what is happening at the time of registration.

Part of the issue was that i was in US and 6 hr time difference.

I'll be curious to see your sip-ua if you get this to come up as I will more than likely have to revisit the issue

Alfred Johnson · ‎10-14-2010

It looks to me like there is a discrepancy with the SDP offer/answer negotiation. The original SDP in the INVITE has:

a=fmtp:101 0-15,

but the 183 has:

a=fmtp:101 0-16

So the 183 appears to be specifying the DTMF value 16 that the INVITE does not advertise support for. Could this be causing the CANCEL? I have seen this issue raised before, but I do not remember where. I was actually searching for this because we saw some error logs that may be due to this problem, though our calls are not failing because of it. I seem to recollect that the 16 value may be a non-standard Cisco symbol.

dksingh · ‎10-14-2010

Going by call trace it seems GW sending a CANCEL as it did not

rec. 200 OK (answer) for the Invite.

Interesting that your SP is not challenging the Invite with a 401 for

auth rather sends 100 and 183. Invite does not have a Auth header.

Can u check if the GW is infact registered using sh sip regist status ?

You will need some answers from your SP to get it to work.

I can tell u that a=fmtp:101 0-15 or 0-16 is not an issue and is not

why the call is failing..

DK

pcanters · ‎11-16-2010

Well....I am back and trying to pick this up again as this issue is being revisited

.

Did you ever get any answers as to doing this with this provider using the UC500. I can't imagine the issue being much different on a h.323 gateway from a UC500 device....

I am hopeful that you did find an answer....What did you end up doing ??

TIA