SIP Trunk Between Asterisk and Cisco UC560

Good morning

I need to configure a SIP trunk between a UC560 and Asterisk.
I have already set up the Asterisk Trunk, incoming and outgoing routes.

At the moment all SIP calls proventienti dall’Asterisk and directed to the UC560 work regularly.

I have some problems on calls from dall’UC560 directed to Asterisk.
UC tells me that “The Number you have dialed is not in service”

I have enabled debugging on Asterisk SIP and I noticed the following:

 pbxpi * CLI>
 <--- SIP read from UDP :/ / 192.168.0.227:57446 --->
 ACK sip: 801@192.168.0.230: 5060 SIP/2.0
 Via: SIP/2.0/UDP 192.168.0.227:5060; branch = z9hG4bK57231F
 From: "UC Extension" <sip:311@192.168.0.230>; tag = 1F7C8C-16B
 To: <sip:801@192.168.0.230>; tag = as707a2df5
 Date: Fri, 21 Apr 2013 07:39:38 GMT
 Call-ID: 8F6EE81A-D97C11E2-8065DF0E-CD1EB93@192.168.35.227
 Max-Forwards: 70
 CSeq: 101 ACK
 Allow-Events: telephone-event
 Content-Length: 0

The problem seems to be that, typing 801 on a phone connected to the UC560 the “To” field contains "@192.168.0.230" (which is the IP address of the UC) :open_mouth: :open_mouth: :open_mouth:

Unlike a SIP call made ​​by a PC connected to UC560 with SotPhone attested to Asterisk I note the following:

 <--- SIP read from UDP :/ / 192.168.10.12:5070 --->
 ACK sip: SIP/2.0 301@192.168.0.230
 Via: SIP/2.0/UDP 192.168.10.12:5070; rport; branch = z9hG4bK2932784
 To: <sip:301@192.168.0.230>; tag = as59a60f05
 From: "SoftPhone" <sip:801@192.168.0.230>; tag = 7185
 Call-ID: 1371751226-2784-COMPUTER-NAME@5.98.211.178
 CSeq: 457 ACK
 Max-Forwards: 20
 User-Agent: NCH Software Express Talk 4.28
 Authorization: Digest
 Content-Length: 0

The Field “To” is properly compiled!!!
There’s a way to Edit the “To:” field of the incominc SIP Call?
Can you give me some guidance to solve the problem?

Thank you very much in advance

Asterisk will not normally look at the domain part. In any case, it routes based on the request URI, not the one in the To: header, and the request URI only appears in the INVITE.

You need to provide the contents of the INVITE and all the responses to it, not just the final ACK. Also, just in case you made the routing domain sensitive, you need to provide the contents of sip.conf.

You should probably team up with the person who has incoming CUCM calls working but can’t make outgoing ones (I’m not sure if he posted to the correct forum, so you may want to look at other ones, if you can’t find the posting I’m referring to.

Here’s the INVITE packet:

<— SIP read from UDP://192.168.0.227:61242 —>
INVITE sip:801@192.168.0.230:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.227:5060;branch=z9hG4bK6A702
From: “UC560 User” sip:311@192.168.0.230;tag=40620C-44C
To: sip:801@192.168.0.230
Date: Thu, 20 Jun 2013 15:43:25 GMT
Call-ID: FAFFC3FE-D8F611E2-80E398B1-A9EE9F4@192.168.0.227
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 4203586382-3640005090-2162071729-0178186740
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: 1371743005
Contact: sip:311@192.168.0.227:5060
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 253

v=0
o=CiscoSystemsSIP-GW-UserAgent 5733 7833 IN IP4 192.168.0.227
s=SIP Call
c=IN IP4 192.168.0.227
t=0 0
m=audio 18832 RTP/AVP 0 101
c=IN IP4 192.168.0.227
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

In my environment the problem is to place a call from UC560 to Asterisk.
Seem that the Asterisk don’t know the To: sip:801@192.168.0.230

The Cisco CUCM work differetly from UC560. We have a CUCM that work perfectly with Asterisk through a SIP Trunk

Asterisk makes very little use of the To line.

It will take this line:

INVITE sip:801@192.168.0.230:5060 SIP/2.0

and normally strip out everything except 801, and then use that to look up an extension in the context that was matched based on the source address, and possibly the From line user part.

Basically, though, you are continuing to provide insufficient information to debug the problem. You still haven’t provider the SIP response, which will be telling the other side why the call was rejected. With the right debug and verbosity settings, Asterisk will also be telling you why it is rejecting the call. (Generally, you should uncomment full, in logger.conf, and run with core set verbose 5 and core set debug 5, then provide the logs from /var/log/asterisk/full.)

Also you haven’t provided sip.conf. There are some, rarely used, options in there that can change the context used depending on the domain part of the URI in the INVITE line.

Asterisk does not normally route based on the domain part.