cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8440
Views
40
Helpful
4
Replies

SX20 Quick Set registered but can't place calls

jwolfe1221
Level 1
Level 1

We have several new SX20 units, two of which I have setup and registered via SIP with UCM (v8.6.2, required a device pack).  I can place a call to the SX20 from a regular IP phone (7961 - SCCP), answer the call with the telepresence unit and carry on a voice only conversation.  However when dialing from the SX20 to another SX20 or any other IP phone it briefly displays "connecting call", then immediately goes to "call has disconnected".  I have tried dialing just the 4 digit DN, as well as the SIP URI.  Below is a portion of the command line log output for the sx20 that indicates the SIP call is being rejected with a 403 forbidden message. 

It should be noted that prior to these devices, we had no phones registered via SIP, only SCCP.  At this point, these devices do not need to dial outside of our network.  I've had a TAC case open for two weeks, and keep getting passed between Telepresence and UCM teams.  I told them we've never had a SIP device registered with our UCM before and if there was anything else that needed to be configured, the answer was nothing more for internal calls only.  I am in the process of trying to get it escalated now, but thought I would give the forums a go.  Any help is greatly appreciated, and I apologize if this issue is something is something ridiculously simple.

63018.74 DATACTRL I: DataGateCfgReq(ig=7) hdlc=yes

63018.76 SipStack I: SipDialog(ui=8,s=0) sendInviteRejToStack (403:Forbidden)

63018.76 MC W: Mcfsm::handleOtherMessages() unknown msg SIP_DialogFreed_Ind from SipStack

63018.77 SipCall I: sip_call_handler::handleSIPMCallRej(8/0/-1): Call rejected (cause: Forbidden)

63018.78 MC I: signalLocalReceiveCapsetChange, RemoteParticipant::signalLRCap

63018.78 SipCall I: ==== makeOutgoingUpdate appId=8, stackId=-1, eventCookie=-1, isEmptyCap=0, holdState=0

63018.74 DATACTRL I: DataGateCfgReq(ig=7) hdlc=yes

63018.76 SipStack I: SipDialog(ui=8,s=0) sendInviteRejToStack (403:Forbidden)

63018.76 MC W: Mcfsm::handleOtherMessages() unknown msg SIP_DialogFreed_Ind from SipStack

63018.77 SipCall I: sip_call_handler::handleSIPMCallRej(8/0/-1): Call rejected (cause: Forbidden)

63018.78 MC I: signalLocalReceiveCapsetChange, RemoteParticipant::signalLRCap

63018.78 SipCall I: ==== makeOutgoingUpdate appId=8, stackId=-1, eventCookie=-1, isEmptyCap=0, holdState=0

-JW

1 Accepted Solution

Accepted Solutions

Took a look at the logs on your case - looks like there is no calling number passed in the RPID or Contact header, so CUCM rejects the call and sends the 403 forbidden.  Note the "From" field below - should be sip:1070@XX.XX.XX.XX.  What do you have configured as your SIP URI in your SX20?  Not that familar with the SX20, but on my EX90 in the lab, there's a SIP URI field that I had to enter the DN@ address>.  Anything on CUCM that would block the DN from being passed on a call from SX to IP phone?

primaryDN=1070, Cannot get calling DN to determine the LineControl...sending 403

SIP/2.0 403 Forbidden

Via: SIP/2.0/TCP XX.XX.XX.XX:5060;branch=z9hG4bK8664f3a10726dfcdd3f6437593e431b6.1;rport

From: "1070" ;tag=123835963de850ed

To: <>1091@XX.XX.XX.XX>;tag=1701792190

Date: Thu, 14 Jun 2012 16:56:46 GMT

Call-ID:

143a225a97ecefc2@XX.XX.XX.XX

CSeq: 100 INVITE

Allow-Events: presence

Warning: 399 CM2 "Unknown calling DN"

Content-Length: 0 SIP/2.0 403 Forbidden
Via: SIP/2.0/TCP XX.XX.XX.XX:5060;branch=z9hG4bK8664f3a10726dfcdd3f6437593e431b6.1;rport
From: "1070" ;tag=123835963de850ed
To: <>1091@XX.XX.XX.XX>;tag=1701792190
Date: Thu, 14 Jun 2012 16:56:46 GMT
Call-ID: 143a225a97ecefc2@XX.XX.XX.XX

CSeq: 100 INVITE
Allow-Events: presence
Warning: 399 CM2 "Unknown calling DN"
Content-Length: 0

View solution in original post

4 Replies 4

Amlesh Sengar
Level 1
Level 1

Hi,

   Can you please tell the SR opened with TAC.  We can have a look and revert.

Also i believe you have already checked partitions and css config on cucm.

Thanks,

Amlesh

Thanks for your reply Amlesh, the case is SR# 621972909.  I did check the css config and partition on cucm.  They are set to partitions and css that we normally use, but I tried several others with no noticable effect on the issue.  Thanks again.

Took a look at the logs on your case - looks like there is no calling number passed in the RPID or Contact header, so CUCM rejects the call and sends the 403 forbidden.  Note the "From" field below - should be sip:1070@XX.XX.XX.XX.  What do you have configured as your SIP URI in your SX20?  Not that familar with the SX20, but on my EX90 in the lab, there's a SIP URI field that I had to enter the DN@ address>.  Anything on CUCM that would block the DN from being passed on a call from SX to IP phone?

primaryDN=1070, Cannot get calling DN to determine the LineControl...sending 403

SIP/2.0 403 Forbidden

Via: SIP/2.0/TCP XX.XX.XX.XX:5060;branch=z9hG4bK8664f3a10726dfcdd3f6437593e431b6.1;rport

From: "1070" ;tag=123835963de850ed

To: <>1091@XX.XX.XX.XX>;tag=1701792190

Date: Thu, 14 Jun 2012 16:56:46 GMT

Call-ID:

143a225a97ecefc2@XX.XX.XX.XX

CSeq: 100 INVITE

Allow-Events: presence

Warning: 399 CM2 "Unknown calling DN"

Content-Length: 0 SIP/2.0 403 Forbidden
Via: SIP/2.0/TCP XX.XX.XX.XX:5060;branch=z9hG4bK8664f3a10726dfcdd3f6437593e431b6.1;rport
From: "1070" ;tag=123835963de850ed
To: <>1091@XX.XX.XX.XX>;tag=1701792190
Date: Thu, 14 Jun 2012 16:56:46 GMT
Call-ID: 143a225a97ecefc2@XX.XX.XX.XX

CSeq: 100 INVITE
Allow-Events: presence
Warning: 399 CM2 "Unknown calling DN"
Content-Length: 0

Thanks for your reply.  The SX20 also has the SIP URI field.  When I initially opened my Service Request that was the first thing I asked, what I needed to put in that field.  The response I got was that it was just an identifier and it didn't matter what format it was in, etc...  So, previously I just had the DN as the SIP URI.  After replacing it with 1070@XX.XX.XX.XX, the call went through just fine.  I had a feeling it was something simple, so thank you for clearing that up I greatly appreciate it.