×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

SIP Dial Peer question

Answered Question
Jan 16th, 2014
User Badges:

            I currently have a working PRI for PSTN calls, and am testing a SIP trunk.  My trunk is registered.  I have the following outbound dial peers



dial-peer voice 902 pots

trunkgroup PRI

destination-pattern 91[2-9]..[2-9]......

no sip registrar


dial-peer 904 voip

destination-pattern 913(removed, but more explicit than above)

session protocol sipv2

session target X.X.X.X



If i do a   show dialplan number with the explcit number, i show matching dial peer 904 first, as expected

however, the calls go out the PRI.


I do not see an Invite message with debug ccsip messages.   Am I misisng something here?  If i was sending the incorrect number of digits, I would still see an Invite, correct?

Correct Answer by Suresh Subramanian about 3 years 6 months ago

Then the binding under dial peers should fix both inbound n outbound dialpeers

Correct Answer by Suresh Subramanian about 3 years 6 months ago

the one towards the provider.


Please rate all the useful posts

Correct Answer by MOHIT SINGH about 3 years 7 months ago

Thanks for the logs. I checked the logs and can see between CUBE and CUCM H323 is getting used not SIP because it is using dial peer 2004 and 2001 to route the call to CUCM which is configured for H323


   Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=2004, Call Count On=FALSE,


You have mentioned when IP phone user answer the call then CUBE is not sending 200 OK to PSTN. When IP phone receiver goes off hook H245 negotiation starts which is used for media. H245 requires a new TCP session to be established for its negotiation. In many netowrks due to some issue H245 TCP hand shake fails due to which both the ends are unable to establish media (it can be confirmed using packet capture but not needed now). When H245 negotiation fails then we can see cause code 47 (Cause No. 47 - resource unavailable, unspecified)

for disconnect same can be seen in your logs


.Jan 20 13:58:13.399: //296998/FE22867482DE/CCAPI/cc_api_call_disconnected:

   Cause Value=47, Interface=0x48755A64, Call Id=296998


As in H323 leg media negotiaition is failing so SIP leg between CUBE and service provider does not become aware if IP phone answered the call so CUBE never sends 200 OK to ITSP. I will suggest you two options to resolve the issue:


1. In H323 gateway configuration in CUCM, uncheck "wait for far end TCS" and reset the trunk. Then check the calls.


2. If above option fails then configure dial peer 2004 and 2001 to use SIP using "session protocol sipv2" command and configure a SIP trunk in CUCM for the CUBE if not already configured. Using SIP should fix the issue.


Regards,

Mohit Singh

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (4 ratings)
Loading.
Nadeem Ahmed Thu, 01/16/2014 - 15:30
User Badges:
  • Cisco Employee,

Can you please debug voice ccapi inout to check the dial-peer it's hitting and reason code ?

Sent from Cisco Technical Support iPhone App

Chris Deren Thu, 01/16/2014 - 15:30
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 IP Telephony, Contact Center, Unified Communications

You need to strip the 9 prefix.

Sent from Cisco Technical Support iPhone App

balitewiczp Fri, 01/17/2014 - 07:31
User Badges:

Here's the capture from the debug.  Its matching the 902 outbound pots dial peer.


I will try it without the 9, as Chris suggests, but I would still expect at least see an Invite upon a successful match of a sip dial peer.


.Jan 17 09:08:04.851: //-1/802798285A05/CCAPI/cc_api_display_ie_subfields:

   cc_api_call_setup_ind_common:

   cisco-username=1944

   ----- ccCallInfo IE subfields -----

   cisco-ani=1944

   cisco-anitype=0

   cisco-aniplan=0

   cisco-anipi=0

   cisco-anisi=1

   dest=913126836XXX

   cisco-desttype=0

   cisco-destplan=0

   cisco-rdie=FFFFFFFF

   cisco-rdn=

   cisco-rdntype=-1

   cisco-rdnplan=-1

   cisco-rdnpi=-1

   cisco-rdnsi=-1

   cisco-redirectreason=-1   fwd_final_type =0

   final_redirectNumber =

   hunt_group_timeout =0


.Jan 17 09:08:04.851: //-1/802798285A05/CCAPI/cc_api_call_setup_ind_common:

   Interface=0x48755A64, Call Info(

   Calling Number=1944,(Calling Name=)(TON=Unknown, NPI=Unknown, Screening=User,        Passed, Presentation=Allowed),

   Called Number=913126836XXX(TON=Unknown, NPI=Unknown),

   Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=T       RUE,

   Incoming Dial-peer=1000, Progress Indication=NULL(0), Calling IE Present=TRUE       ,

   Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALS       E), Call Id=293949

.Jan 17 09:08:04.851: //-1/802798285A05/CCAPI/ccCheckClipClir:

   In: Calling Number=1944(TON=Unknown, NPI=Unknown, Screening=User, Passed, Pre       sentation=Allowed)

.Jan 17 09:08:04.851: //-1/802798285A05/CCAPI/ccCheckClipClir:

   Out: Calling Number=1944(TON=Unknown, NPI=Unknown, Screening=User, Passed, Pr       esentation=Allowed)

.Jan 17 09:08:04.851: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:


.Jan 17 09:08:04.851: :cc_get_feature_vsa malloc success

.Jan 17 09:08:04.851: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:


.Jan 17 09:08:04.851:  cc_get_feature_vsa count is 3

.Jan 17 09:08:04.851: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:


.Jan 17 09:08:04.851: :FEATURE_VSA attributes are: feature_name:0,feature_time:1       277372256,feature_id:125075

.Jan 17 09:08:04.851: //293949/802798285A05/CCAPI/cc_api_call_setup_ind_common:

   Set Up Event Sent;

   Call Info(Calling Number=1944(TON=Unknown, NPI=Unknown, Screening=User, Passe       d, Presentation=Allowed),

   Called Number=91312683XXX(TON=Unknown, NPI=Unknown))

.Jan 17 09:08:04.855: //293949/802798285A05/CCAPI/cc_process_call_setup_ind:

   Event=0x4954EB60

.Jan 17 09:08:04.855: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:

   Try with the demoted called number 913126836XXX

.Jan 17 09:08:04.855: //293949/802798285A05/CCAPI/ccCallSetContext:

   Context=0x4CBBDA40

.Jan 17 09:08:04.855: //293949/802798285A05/CCAPI/cc_process_call_setup_ind:

   >>>>CCAPI handed cid 293949 with tag 1000 to app "_ManagedAppProcess_Default"

.Jan 17 09:08:04.855: //293949/802798285A05/CCAPI/ccCallProceeding:

   Progress Indication=NULL(0)

.Jan 17 09:08:04.859: //293949/802798285A05/CCAPI/ccCallSetupRequest:

   Destination=, Calling IE Present=TRUE, Mode=0,

  Outgoing Dial-peer=902, Params=0x4D36ECC4, Progress Indication=NULL(0)

.Jan 17 09:08:04.859: //293949/802798285A05/CCAPI/cc_fill_tg_params:

   Not a cic call

.Jan 17 09:08:04.859: //293949/802798285A05/CCAPI/ccCallSetupRequest:

   Trunk Group Select Interface Success;

   Interface=0x49DA805C, Selected Interface=1, Selected DSL=0

.Jan 17 09:08:04.859: //293949/802798285A05/CCAPI/ccCheckClipClir:

   In: Calling Number=6182330513(TON=Unknown, NPI=Unknown, Screening=User, Passe       d, Presentation=Allowed)

.Jan 17 09:08:04.859: //293949/802798285A05/CCAPI/ccCheckClipClir:

   Out: Calling Number=6182330513(TON=Unknown, NPI=Unknown, Screening=User, Pass       ed, Presentation=Allowed)

.Jan 17 09:08:04.863: //293949/802798285A05/CCAPI/ccCallSetupRequest:

   Destination Pattern=91[2-9]..[2-9]......, Called Number=913126836956, Digit S       trip=TRUE

balitewiczp Fri, 01/17/2014 - 07:51
User Badges:

Telco informs me they want to see just 10 digits.  I modified the route pattern and destination pattern accordingly, dropping the 91 from the destinatioin patterntand just leaving the full 10 digits.  DNA confirms that my route pattern is correct, but debug ccapi inout shows nothing, and my call results in a fast busy.

Chris Deren Fri, 01/17/2014 - 08:03
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 IP Telephony, Contact Center, Unified Communications

If debug voice dial peer does not show anything perhaps the call does not get to the GW, did you try resetting the SIP trunk in CUCM?


Chris

Carlo Poggiarelli Fri, 01/17/2014 - 08:25
User Badges:
  • Green, 3000 points or more

Hi.

If you are using a sip trunk between CUCM and VG, please reset the sip trunk on CUCM as Chris suggested (+5 "C" ) and collect a debug ccsiop messages on VG.



Thanks



Regards


Carlo




Please rate all helpful posts

"The more you help the more you learn"

balitewiczp Mon, 01/20/2014 - 10:06
User Badges:

Thanks for everyones suggestion.  As this is my first go around with sip, appreciate the patience.  I have a softphone used for testing to the pstn.  for inbound pstn calls to the softphone, the cube is not sending 200 ok when the softphone answers the phone.    when I do eventually hang up the pstn call, strangly enough the cube does send a 200 to the cancel request.  attached is the ccsip messages debug


INVITE sip:6183101740@63.254.213.2:5060 SIP/2.0

Via: SIP/2.0/UDP 10.250.0.5:5060;branch=z9hG4bK6frerv20d0716ro5o0g1.1

From: "BURWOOD GROUP I";tag=1887040981-1390240594464-

To: "ECKERT LAND ."

Call-ID: BW175634464200114-482273093@64.199.51.169

CSeq: 409337105 INVITE

Contact:

Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY

Accept: application/media_control+xml,application/sdp,multipart/mixed

Supported: timer

Min-SE: 60

Max-Forwards: 47

Content-Type: application/sdp

Content-Length: 272


v=0

o=- 4184481674 1 IN IP4 10.250.0.5

s=-

c=IN IP4 10.250.0.5

t=0 0

m=audio 20062 RTP/AVP 18 0 8 101

a=sendrecv

a=ptime:20

a=rtpmap:18 G729/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=fmtp:18 annexb=no


.Jan 20 11:56:34.952: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 10.250.0.5:5060;branch=z9hG4bK6frerv20d0716ro5o0g1.1

From: "BURWOOD GROUP I";tag=1887040981-1390240594464-

To: "ECKERT LAND ."

Date: Mon, 20 Jan 2014 17:56:34 GMT

Call-ID: BW175634464200114-482273093@64.199.51.169

CSeq: 409337105 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0



.Jan 20 11:56:34.968: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 10.250.0.5:5060;branch=z9hG4bK6frerv20d0716ro5o0g1.1

From: "BURWOOD GROUP I";tag=1887040981-1390240594464-

To: "ECKERT LAND .";tag=8D6400AC-162D

Date: Mon, 20 Jan 2014 17:56:34 GMT

Call-ID: BW175634464200114-482273093@64.199.51.169

CSeq: 409337105 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: "Burwood Pete B Tes" ;party=called;screen=no;privacy=off

Contact:

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0



.Jan 20 11:56:50.729: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 10.250.0.5:5060;branch=z9hG4bK6frerv20d0716ro5o0g1.1

From: "BURWOOD GROUP I";tag=1887040981-1390240594464-

To: "ECKERT LAND .";tag=8D6400AC-162D

Date: Mon, 20 Jan 2014 17:56:34 GMT

Call-ID: BW175634464200114-482273093@64.199.51.169

CSeq: 409337105 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Remote-Party-ID: "Burwood Pete B Tes" ;party=called;screen=no;privacy=off

Contact:

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0



.Jan 20 11:56:55.633: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

CANCEL sip:6183101740@63.254.213.2:5060 SIP/2.0

Via: SIP/2.0/UDP 10.250.0.5:5060;branch=z9hG4bK6frerv20d0716ro5o0g1.1

CSeq: 409337105 CANCEL

From: "BURWOOD GROUP I";tag=1887040981-1390240594464-

To: "ECKERT LAND ."

Call-ID: BW175634464200114-482273093@64.199.51.169

Max-Forwards: 47

Content-Length: 0



.Jan 20 11:56:55.645: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.250.0.5:5060;branch=z9hG4bK6frerv20d0716ro5o0g1.1

From: "BURWOOD GROUP I";tag=1887040981-1390240594464-

To: "ECKERT LAND ."

Date: Mon, 20 Jan 2014 17:56:55 GMT

Call-ID: BW175634464200114-482273093@64.199.51.169

CSeq: 409337105 CANCEL

Content-Length: 0



.Jan 20 11:56:55.645: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 487 Request Cancelled

Via: SIP/2.0/UDP 10.250.0.5:5060;branch=z9hG4bK6frerv20d0716ro5o0g1.1

From: "BURWOOD GROUP I";tag=1887040981-1390240594464-

To: "ECKERT LAND .";tag=8D6400AC-162D

Date: Mon, 20 Jan 2014 17:56:55 GMT

Call-ID: BW175634464200114-482273093@64.199.51.169

CSeq: 409337105 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGateway/IOS-12.x

Reason: Q.850;cause=16

Content-Length: 0

MOHIT SINGH Mon, 01/20/2014 - 11:38
User Badges:
  • Bronze, 100 points or more

As per above discussion call flow looks like


PSTN --> SIP --> CUBE --> SIP --> CUCM --> IP phone.


Let me know if it is not correct. The SIP logs are for one leg only i.e between CUBE and CUCM so it is difficult to say what is happening. could you provide below mentioned debugs for a test inbound call with calling and called number


debug voip ccapi inout

debug ccsip message

debug ccsip error


Also share "show run" from router


Regards,

Mohit Singh

Correct Answer
MOHIT SINGH Mon, 01/20/2014 - 13:13
User Badges:
  • Bronze, 100 points or more

Thanks for the logs. I checked the logs and can see between CUBE and CUCM H323 is getting used not SIP because it is using dial peer 2004 and 2001 to route the call to CUCM which is configured for H323


   Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=2004, Call Count On=FALSE,


You have mentioned when IP phone user answer the call then CUBE is not sending 200 OK to PSTN. When IP phone receiver goes off hook H245 negotiation starts which is used for media. H245 requires a new TCP session to be established for its negotiation. In many netowrks due to some issue H245 TCP hand shake fails due to which both the ends are unable to establish media (it can be confirmed using packet capture but not needed now). When H245 negotiation fails then we can see cause code 47 (Cause No. 47 - resource unavailable, unspecified)

for disconnect same can be seen in your logs


.Jan 20 13:58:13.399: //296998/FE22867482DE/CCAPI/cc_api_call_disconnected:

   Cause Value=47, Interface=0x48755A64, Call Id=296998


As in H323 leg media negotiaition is failing so SIP leg between CUBE and service provider does not become aware if IP phone answered the call so CUBE never sends 200 OK to ITSP. I will suggest you two options to resolve the issue:


1. In H323 gateway configuration in CUCM, uncheck "wait for far end TCS" and reset the trunk. Then check the calls.


2. If above option fails then configure dial peer 2004 and 2001 to use SIP using "session protocol sipv2" command and configure a SIP trunk in CUCM for the CUBE if not already configured. Using SIP should fix the issue.


Regards,

Mohit Singh

balitewiczp Mon, 01/20/2014 - 14:46
User Badges:

Hello Mohit


you are correct, the CUBE is currentl also a H323 PSTN Gateway with PRI, migrating to SIP Trunk.  I have a SIP trunk configured in CUCM.  I used option 2 above, adding the session protocol sipv2 line.   I also thought about the media negotitation, and noticed that in my voice class, i have 711 listed first.  I made a new voice class, and preferred 729.  BANG


My inbound is now working.  I suspect I'll have to play with dtmf, but im not at that point.


My outbound is still not working.  Ive attached the ccsip message log, along with the relevant dial peer.  I have a specific destination pattern so I am sure im hitting the right dial peer, also because Im getting a response back from the ISP.  Can you take a look, and see if you notice anything.

Suresh Subramanian Mon, 01/20/2014 - 19:37
User Badges:
  • Gold, 750 points or more
  • Community Spotlight Award,

    Mobile User, October 2015

Hello,


could you please post the latest 'show run'?


for the show run file attached above, it seems you are missing binding interface command which is important.


Also configure Inbound & outbound dial-peers with correct set of voice class codecs and bind the right interface in the dial-peer level if required.


Please refer this URLs for better understanding of CUBE configuration.


points to be considered while starting CUBE config: https://supportforums.cisco.com/message/4117173#4117173


Binding Media & Signalling interfaces: https://supportforums.cisco.com/community/netpro/collaboration-voice-video/ip-telephony/blog/2013/04/04/cube-sip-media-and-signalling-binding-to-an-interface


CUBE FAQ: https://supportforums.cisco.com/docs/DOC-17964.


From the debug you posted, the invite message sent from CUBE to ITSP is below.


.Jan 20 16:28:24.269: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:3126836956@10.250.0.5:5060 SIP/2.0

Via: SIP/2.0/UDP 63.254.213.2:5060;branch=z9hG4bK29ADA7B2

Remote-Party-ID: "Burwood Pete B Tes" ;party=calling;screen=yes;privacy=off

From: "Burwood Pete B Tes" ;tag=8E5CDB98-1D29

To:

Date: Mon, 20 Jan 2014 22:28:24 GMT

Call-ID: 2582E53-815911E3-8487AE34-80EF1F2E@63.254.213.2

Supported: 100rel,timer,resource-priority,replaces,sdp-anat

Min-SE:  1800

Cisco-Guid: 717808384-65536-23-672071690

User-Agent: Cisco-SIPGateway/IOS-12.x

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

CSeq: 101 INVITE

Timestamp: 1390256904

Contact: 63.254.213.2:5060> Where the CallingParty can be reached for the return signaling path

Expires: 180

Allow-Events: telephone-event

Max-Forwards: 69

Session-Expires:  1800

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 238


v=0

o=CiscoSystemsSIP-GW-UserAgent 3970 7444 IN IP4 63.254.213.2

s=SIP Call

c=IN IP4 63.254.213.2 << the IPAddress that the originator expects the media to arrive at

t=0 0

m=audio 16408 RTP/AVP 18 19

c=IN IP4 63.254.213.2

a=rtpmap:18 G729/8000 ---> codec negotiated between CUBE & ITSP

a=fmtp:18 annexb=no

a=rtpmap:19 CN/8000

a=ptime:20


>> I don't see these IP address configured in CUBE. 63.254.213.2 is this the IP the ITSP wants to send you the signaling & media?

if so, you would need to configure this IP address in the interface where ISTP is connected to and bind this interface in the outbound dialpeer to ITSP.


>> similarly the gateway ip address: 10.0.15.5 needs binding towards CUCM leg.


could you please configure the below commands under 'voice service voip> sip' and check the behaviour?


  header-passing

  error-passthru

  asymmetric payload full

  midcall-signaling passthru




Please rate all the useful posts

MOHIT SINGH Mon, 01/20/2014 - 21:57
User Badges:
  • Bronze, 100 points or more

To fix DTMF issue configure "dtmf-relay rtp-nte" under inbound and outbound SIP dial peer also remove "h245-alpha".


In your outbound call signalling is proper with ITSP. Could you explain what is the issue you are facing? Are you getting busy tone immediately when dialing out or you don't hear ringback tone? From logs call was disconnected from ITSP end with "487 Request terminated". Flow is shown below


CUBE --> Invite --> ITSP

CUBE <-- 100 Trying <-- ITSP

CUBE <-- 183 session progress <-- ITSP


After around 46 second ITSP disconnects the call


CUBE <-- "487 Request terminated" <-- ITSP


ask your provider why they are sending ""487 Request terminated"?


Regards,

Mohit Singh

balitewiczp Tue, 01/21/2014 - 08:06
User Badges:

ok, here is the latest show run, with some other debugs.  Outbound is not working, IP Phone hears ringback, nothing on PSTN side.  from the logs, it looks like im failing between the UCM and Voice GW. as I eventually get a 500 Internal Service error.   I do not have any media/control bind statements, as the only places i can put them are under global voice service voip.  I would prefer to do it under dial peers, but do not have the bind keyword for voice-class sip paramenter.  I am running 12.4(22)T

balitewiczp Tue, 01/21/2014 - 08:08
User Badges:

fyi, I also have my sip trunk in a different region than my IP Phone, so that should means g729 codec

Suresh Subramanian Tue, 01/21/2014 - 08:50
User Badges:
  • Gold, 750 points or more
  • Community Spotlight Award,

    Mobile User, October 2015

did you try the binding under voice service voip? if not, could you please try that for testing?



Please rate all the useful posts

Correct Answer
Suresh Subramanian Tue, 01/21/2014 - 08:54
User Badges:
  • Gold, 750 points or more
  • Community Spotlight Award,

    Mobile User, October 2015

the one towards the provider.


Please rate all the useful posts

Correct Answer
Suresh Subramanian Tue, 01/21/2014 - 09:31
User Badges:
  • Gold, 750 points or more
  • Community Spotlight Award,

    Mobile User, October 2015

Then the binding under dial peers should fix both inbound n outbound dialpeers

balitewiczp Tue, 01/21/2014 - 09:41
User Badges:

do you know what IOS first supported binding at the dial peer level?  I dont have that as a valid choice.  Im on 12.4(22)T5


Eckerts-BV-2811(config-dial-peer)#voice-class sip ?

  anat              allow alternative network address types IPv4 and IPv6

  asserted-id       Type of privacy identity

  asymmetric        Configure SIP asymmetric payload support

  bandwidth         allow SIP SDP bandiwidth related options

  e911              SIP e911 support for this dial-peer

  early-offer       Configure sending Early-Offer

  g729              G729 codec interoperability setttings

  history-info      History Info Header Enable

  localhost         DNS name for local host

  options-ping      Send in-dialogue OPTIONs to ping other endpoint

  outbound-proxy    Configure an Outbound Proxy Server

  privacy           Type of privacy support

  profiles          Set SIP-Profiles parameters

  rel1xx            Type of reliable provisional response support

  resource          SIP Network Resource Parameters Configs

  rsvp-fail-policy  Configure RSVP Failure Policies

  srtp              allow SIP related SRTP options

  transport         Configure transport related parameters

  url               url type in request line of outgoing INVITE

balitewiczp Tue, 01/21/2014 - 09:56
User Badges:

Take a look at this ccsip mesage log.  I see both initial invites/trying  from the ucm to the cube, then cube to isp.  Im back to getting the 487 request terminated message from telco.  I'll inquire with telco.

MOHIT SINGH Tue, 01/21/2014 - 12:00
User Badges:
  • Bronze, 100 points or more

You can hear ringback because service provider is sending "183 session progress" but for some reason they are disconnecting the call with "487 request terminated" after some time. It looks like they are not able to complete the call. If you will see my previous post i mentioned the same and requsted to check with ITSP.


Regards,

Mohit Singh

balitewiczp Wed, 01/22/2014 - 12:12
User Badges:

Got outbound working.  on CUCM 9.1, under Sip Profiles, there is a line item,  Accept Audio Codec Preferences in Received Offer.  I had to change it from Default to ON.

Actions

This Discussion