Duplication of the SIP URIs with prefix GW

Similar Questions

• Change caller id / name of the SIP URI of VCS calls

  Hello

  I have clusted CUCM 9.1 with a SIP to a VCS - C trunk.  When making calls, the calls show a caller id of [email protected] / * / address, for example [email protected] / * /.  I have a configuration URI directory on the phone that generates the call, but now it shows the URI.  Incoming calls from SIP URI properly.

  Thank you

  Hello

  On the trunk SIP for VCS, under outgoing calls, there should be an adjustment: vocation and connected part format, change it to URI deliver only partially connected. Also, under the profile SIP assigned to the SIP trunk to VCS, there should be a setting use entirely field in queries, check this box. The SIP profile should also be attributed to the device SIP calls.

  HTH, if yes, please rate.

• Configure SIP URI dialing

  Hello

  I tried to activate the SIP URI dial, unfortunately with no success yet. Here you can see what I've done, maybe one of you can tell me what is missing:

  • Set up the LDAP synchronization, assign msRTCSIP-PrimaryUserAddress URI directory (because of the interoperability of Lync)
  • DNs associated with devices of CSF and BOT
  • Associate the URIs directory with directory numbers
  • The "phones" partition of directory URI alias value
  • Modify a SIP profile (named Jabber) later
    • Define interpreting string dial with 0-9, *, # and +.
    • Use the FULL domain name in the SIP application
    • Allow the presentation of bfcp
  • Assign the profile Jabber SIP devices CSF and BOT
  • Set the DNs route partition as an alias of the directory URI (phones)
  • Jabber - config.xml and change download
    • msrtcsip-primaryuseraddress in section of the book
    • true in section strategies
  • Restart the tftp server and re - open a session with Jabber

  We have 9.1.2.11900 - 12 Call Manager Server Instant Messaging and presence 9.1.1.10000 - 8 and 9.6/9.7 Jabber clients.

  Is there anything I missed or misconfigured?

  Thank you

  LACI

  Hi Labelle,

  If you put DirectoryURI in the uri section directory publication is no longer available in the client.

  Of the documentention, I got that it belongs to the policies. But if I put it here my click to call URI is always the address e-mail and not msRTCSIP-PrimaryUserAddress. So I'll do some research here.

  One thing I found is the resolution of contact section. If I signed to jabber my name did not appear. Instead, it was my msRTCSIP-PrimaryUserAddress.

  To resolve this problem, you will need to add this to jabber - config.Xml.

  true
    msRTCSIP-PrimaryUserAddress
    SIP:

  Kind regards

  Paul

• SIP URI B2B calls via CUCM and Highway

  Hi all

  Cannot find out how to configure the SIP URI from SX codecs, recorded calls on CUCM.

  I CUCM and IM & P 10.5.1 a pair of X8.5.2 expressway with two areas of course - for B2B calls, and the external jabber.

  I want to make calls of SX-codecs outside via SIP, by using the URI field, for example, [email protected] / * / or [email protected] / * /. How can I configure that?

  I already have the routing model, which is the SIP Trunk for Exp - C, for H323 calls by ip address. Is it possible to make a routing model to call the SIP URI?

  You can see my deployment in this image.

  fghj.PNG

  

  Best wishes

  Igor

  Hi Igor

  These guides will help you resolve your issues:

  http://www.Cisco.com/c/dam/en/us/TD/docs/voice_ip_comm/Expressway/config_guide/x8-5/Cisco-Expressway-SIP-trunk-to-unified-cm-deployment-guide-CUCM-8-9-10-and-x8-5.PDF

  https://supportforums.Cisco.com/ru/video/12362936

  BR Oleksandr

• After adding a subscriber to the CUCM, Sx20 Sip URI field empty cluster

  Hello

  After adding a subscriber to CUCM Cluster, all the restarted cluster devices, then sip uri field sx20 features seemed to "Null", simply enter the SIP registrar one by one for all devices sx20 IP.  Anyone else facing this problem? In my view, is not normal behavior.  What are the causes of this problem? Waiting for your opinions.

  CUCM system version: 9.1.2.13057 - 1

  The SX20 software version: TC7.2.0.aea6651

  //

  Thanks in advance

  Hi Dani

  Greetings of the day!

  Ideally this should not take place. I suspect this is something at the end of Manager at the origin of the problem.

  You make changes to the device pool after adding Subscriber to CUCM Cluster?

  Modifications were made to the Group Manager call?

  Replication between the call manager Publisher and Subscriber is any good?

  The SX20 is supplied by TMS devices?

  You should check the logs of provisioning of the endpoint to enter the cause for it.

  Concerning

  Radhika Sajan

• VCS with Mu - Law when the SIP media processing

  Hi guys, I have a very specific behavior.

  A customer has problems to integrate a VCS Starter Pack X7.2.1 with an Alcatel PBX with a SIP trunk.

  The problem is:

  This PBX is in Europe, so that it uses A - Law (they can´t change this).

  When a dial an extension using H323 as protocol endpoint, I can force the Protocol G711 A - law on the trunk SIP (generating SDP interworked), but when that point of termination (C20 runningn TC5.1.4) using SIP, the PBX Don t accept a p2p support. It must be mandated by the VCS.

  If force us the media through the VCS (by using encryption B2BUA or SIP Lock Mode), the codec negotiated btw VCS and endpoint to the title of this first step is G711 Mu - Law (PCMU) and the accepted PBX codec is PCMA, causing a shift and a loud noise in the call.

  No idea if we can force or configure VCS to use G711a as the Protocol when a SIP - SIP call with stream media through VCS?

  PS: I think that this isn't a problem in the United States, because they use the Mu - Law encoding.

  Thank you

  Can you put a cap set the filter on the endpoint at all?

  xConfiguration Experimental CapsetFilter: "G.711mu"
  
  

  Thank you

  Guy

• Supported SIP URI characters

  Hello

  I'm currently setting up interoperability between Cisco control VCS X7.1 and CUCM V7.1.3.

  The IPT dial plan consists of site prefixes and area codes that make up the full DN phones, this unique name is also starts with a #.

  For example #0044014761

  My problem is (I think), that # is a character in charge of SIP URI that is exposed in the deployment guide. I tried to use 35%, which is the ASCII value for #; Oddly enough, when you use that I can solve the alias against the CUCM SIP trunk, but when you attempt to dial for an endpoint, it fails.

  I know that my SIP trunk is OK, as I can carry 9.* by it on the break-out CUCM PSTN calls.

  Anyone encountered this problem before, or been able to work around it?

  Thank you, if

  Sent by Cisco Support technique iPhone App

  For your reference, it was similar (quite well) discussion there, a month

  https://supportforums.cisco.com/thread/2152374?tstart=210.

• Change the Source URI for outbound calls using VCS Expressway X8.2

  Hi all

  I would like a little help on a CPL script, that I'm working on. I lived all the examples of community support and I am always sick.

  We run on VCS X8.2.  What I've read, VCS X8.1 has introduced a few new CPL capabilities, including the node location CPL supports rewriting the regex-based source alias.  I would like to take advantage of this new feature. I'm looking for a tutorial or a direction more advanced examples using this new capability.

  Here's my question:

  I have an internal domain "CompanyA.local" and I have a public domain "Entreprisea.com". «My Cisco video endpoints register control VCS with a SIP URI of "[email protected] / * / .local'.»

  Receive calls from outside help "[email protected] / * / com" and the rules of research, I route calls properly internally.

  When I dial an external company, my endpoint is showing a video SIP URI of "[email protected] / * / .local"

  Of course, this isn't a SIP URI dial-able and should be changed to "[email protected] / * / .com'." "

  I know that this can be achieved using CPL, but I have not used this feature before.
  Any help would be appreciated.

  Please suggest an example script CPL I can review.

  I would use a Regex to cover all of my similar to the following endpoints:

  source-url-to-message-regex = "(.*) ' @CompanyA.local '"
  source-url-to-message-replace = "------[email protected] / * /"

  Thanks in advance for any help.

  oooooo, that answer above gave me the answer I was looking for. It does not work! It seems that the syntax for the xml file has changed from pre x 8 and x 8. Looks like I've been using the incorrect syntax. I was missing the AVA: in the clause to the proxy, which is my version of rule switch not working. Still don't know why the address switch did not work, but I prefer the rule-switch anyway, so no big loss for me.

  I've tested, and it is fully functional on my vm VCS x8.2 running lab

  
  
  "xmlns:TAA ="http://www.tandberg.net/cpl-extensions"
  "" xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance"
  xsi: schemaLocation = "urn: ietf:params:xml:ns:cpl cpl.xsd" >
         
           
             
               "[email protected] / * / ' >
                 
               
             
           
         
  

• QuickSet C20 (software: TC5.0.0.273156) in 8.6.2.20000 - 2 Communications Manager using the SIP protocol.

  All,

  I am trying to record a QuickSet C20 with the following scenario:

  Endpoint registration C20 (software: TC5.0.0.273156) in 8.6.2.20000 - 2 Communications Manager using the SIP protocol.

  My URI format is: [email protected] / * / (the IP address of the CUCM)

  I tried different settings in CUCM and QuickSet C20, but without success.

  Status in CUCM:

  Inscription: unknown
  IP address: unknown

  Status in C20 QuickSet:

  Failure / failed to save. Unprotected. Unverified.

  Note: The C20 QuickSet Gets the correct IP address.

  Can someone help me?

  Waiting,.

  Lucian Medeiros

  I would try to use the version of the following software:

  cmterm - s52000tc5_1_0_280662.cop.sgn

  Downloadable at:

  http://www.Cisco.com/Cisco/software/release.html?&mdfid=283613658&CATID=280789323&softwareid=280886992&release=TC5.1.0-CUCM&rellifecycle=&relind=available&RelType=all

  Not to mention that I would look at:

  http://www.Cisco.com/en/us/products/ps11424/prod_maintenance_guides_list.html

  In particular:

     http://www.Cisco.com/en/us/docs/Telepresence/endpoint/codec-c-series/TC5/administration_guide/cts_endpoint_administration_ucm86_quick_start_guide_tc51.PDF

• Question about components entering the SIP/h.323 and SRV

  We have our VCS - E put in place for entrants and outbout call to the internet.  We have an SRV record for SIP and H323 audience.

  The SRV record lists the SIP/h.323 services for ourdomain.com, redirecting to video.ourdomain.com.

  I have some problems however;

  When testing with a client of Polycom that does not work with SRV or that has a different implementation of it, we have to deal (alias) @video.ourdomain.com.

  When you use Cisco Jabber (free), it only works when you dial (alias) @ourdomain.com but don't touch our VCS-E at all when you dial (alias) @video.ourdomain.com.  We can compose (alias) @our-public-IP of Jabber OK.

  Cisco Jabber doesn't use regularly debriefed if SRV is not available?

  Optimally all would support SRV, I have to accept that some people that we connect will not support it and I would like to be able to give the same dial in URI to everyone.

  Do I need to register an SRV record for video.ourdomain.com (I don't know yet if we record SRV for subdomains)? Or if I want the same dial in details any material they use, I have to give @public-IP (aka)?

  Cisco 'free version' never took in charge a record search as far as I know.

  The only reason for which you can use on the version "on-prem" is because the VCS-E can be configured to do this, not the customer.

  To ignore completely the DNS and the support of all comers, you will indeed give [email protected] / * /-E_IP_address, that said, as far as H.323 goes you will get a few old systems or systems with the old firmware, Polycom Polycom and LifeSize that only support ip_address ##Alias - so a transformation should be put in place to allow these establishments.

  And Yes, you can configure an SRV for subdomains.

  /Jens

• Numbering outside telepresense SIP URI

  Dear all,

  I'm new in cisco and telepresense Highway and I have a challenge to set up the system so that anyone from outside of the network should be able to manage our devices at the end of TV that are stored in CUCM presence. These are devices EX, SX and DX and the requirement is to compose these extension from any where on the outside with dialing SIP URI.

  We already have expressway-C and E, configured for the client and customers Jabber wants to use the highway to be able to do or to make calls from outside any other end point.

  This is achievable if so what would be the steps to get it.

  Hi Laurent,.

  To answer your questions:

  1 can I make a call to my Jabber client for devices SX using SIP URI.

  -  Yes. Method of numbering SIP URI is recommended, especially when the endpoints are connecting via the Internet.

  2. How can a person outside our network call on my devices EX and SX. Basically what he must dial to reach the device SX bearing the number 1234. for example [email protected] / * /.

  -  An endpoint outside the network can reach your end point within your network through the highway. Any device on Cisco Unified CM can be reached during
  the Internet by alphanumeric numbering assigned SIP URI or the required directory number (DN) using the <+E.164 number>@domaine. He is the solution provided by the side of the highway and track Express Core to extend your audio network seamlessly to mobile users, wherever they are.

  3-Yes, I need to configure anything specific for this thing.

  -You need set up a crossing secure area between your Core Expressway and the edge of the highway. Configuration is simple. Just follow the deployment guide in the link that I sent you. Refer to page 15 and the following procedures.

  Kind regards

  ACE

• All links to external programs open my homepage instead of the target URI

  All links to external programs has recently began to open my homepage rather than the target URI. This only happens when Firefox is my default browser, not when other browsers are set to be the default browser. I see this more often with links in e-mail messages in Thunderbird, but I also reproduced the problem by inserting a link in a document of LibreOffice Writer and clicking on it.

  Looks like a problem with the default browser where the command is missing %U parameter that caused the link not not to be send to Firefox.

• SPA-3102: unable to connect to the SIP server

  Hello

  We have a SPA-3102 installed and work properly in our US Office. We are trying to install another one in our office in India, but we cannot get this device to register with the SIP server.

  This device works perfectly when try us two different residences here in India with two different providers. But when we try to our office with a third party service provider, it is impossible to save.

  The internet connection at the office from the East through an ADSL router which is mode bridged with two IP static coming out of it. We are able to have access to the internet for our PC through this SPA-3102, but the SPA itself is unable to register with our SIP server. We use a Gizmo5 SIP server.

  The same parameters were working in our offices in the United States and two different residences in India but does not work in our office. I don't think that the ISP here has nothing to do with this problem. Would be - this works the ADSL router in bridge mode? Can I make changes in the settings of the SPA to work around this problem?

  Any help is appreciated.

  The problem could be the firewall or the router, but it is also possible that your Indian ISP is blocking voip connections.  It was reported that is not unknown in India.  Sometimes this type of blocking is done by throwing packages for voip standard sip signalling port 5060. You can easily change the SIP port in the SPA3102 to traffic returning to the SPA packages and in fact routers often changes the port without your knowledge, but packets destined for voip provider must use the port specified by the provider number.  Since you can access the internet with your pc, I would try to run tests to see if this is the case.

  I ran a few ping tests and tests to see if I could save with other providers or services that use replacing or other sip signaling ports.

• SIP message with 488 here is not Acceptable

  Hello, I'm having this problem. I have read the documentation and I look in this forum for similar problems.
  Seems is a Codec problem. Service provider asks a g711alaw. However, I already change the codec, transcoder configured which is register with handler calls and everything seems fine. But outgoing calls always give this error. Can someone help me?

  Here's the part of my configuration:

  Send-call voice alert

  convert-discpi-to-prog voice calls

  voice, send rtp-received

  voip phone service

  list of approved IP addresses

  IPv4 10.20.1.0 255.255.255.0

  h323 connections allow h323

  allow connections h323 to SIP

  allow connections sip h323

  allow sip to sip connections

  service additional h450.12

  Fax protocol t38 ls-redundancy version 0 0 hs-redundancy 0 help none

  H323

  No keepalive timeout h225

  SIP

  midcall-signalling passthru

  SCCP local GigabitEthernet0/1

  SCCP ccm 10.20.1.5 identifier 2 priority 2 version 7.0

  SCCP ccm 10.20.1.6 identifier 1 priority 1 version 7.0

  SCCP

  !

  SCCP ccm Group 1

  associate the ccm 1 priority 1

  the associated profile 1 registry COMPcode

  the associated profile 2 registry COMP01-PSG

  !

  transcode dspfarm profile 1

  Codec g711ulaw

  Codec g711alaw

  Codec g729ar8

  Codec g729abr8

  Codec g729r8

  Codec g729br8

  maximum sessions 14

  associate the PCRS application

  !

  dspfarm profile 2 PSG

  Codec g711ulaw

  maximum sessions 120 software

  associate the PCRS application

  !

  Dial-peer voice voip 50

  Description # calls of CUCM to VG #.

  incoming called number 9.T

  DTMF-relay h245 alphanumeric

  Codec g711alaw

  No vad

  !

  Dial-peer voice 11 voip

  Description * outgoing SIP Trunk call *.

  outgoing SIP CALLS OUT translation-profile

  preference 1

  destination-model 9 t

  Setup progress_ind allow 3

  progress_ind enable progress 8

  progress_ind connect enable 8

  redirect ip2ip

  session protocol sipv2

  session target ipv4:88.XXX. XX.XXX

  DTMF-relay rtp - nte cisco-rtp

  Codec g711alaw

  No vad

  The Sip Trunk on the call manager uses a MRGL both of PSG and XCODE.

  SCCP Admin State: to the TOP
  Gateway local Interface: GigabitEthernet0/1
  IPv4 address: 10.20.1.11
  Port number: 2000
  IP precedence: 5
  List of Codec hidden user: no
  Call Manager: 10.20.1.5, Port number: 2000
  Priority: 2, Version: 7.0, identifier: 2
  Call Manager: 10.20.1.6, Port number: 2000
  Priority: 1, Version: 7.0, identifier: 1

  Transcoding of Oper status: ACTIVE - reason Code: NO

  Here are the two him debugs:

  * 3 Dec 12:08:32.859: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
  Received:
  GUEST sip:[email protected]/ * /: SIP-5060/2.0
  Via: SIP/2.0/TCP 10.20.1.6:5060; branch = z9hG4bK148c5e3b74ba77
  From: <> [email protected]/ * */>;tag=1130165~6e3f6e1b-b59e-4604-be6a-d6295dc18cf6-45522220
  To: <> [email protected]/ * / >
  Date: Monday, December 3, 2012 12:02:40 GMT
  Call ID: [email protected] / * /
  Supported: timer, resource-priority, replaces
  Min - SE: 1800
  User-Agent: Cisco - CUCM8.6
  Allow: PROMPT, OPTIONS, INFO, BYE, ACK, CANCEL, PRACK, UPDATE, VIEW, SUBSCRIBE, NOTIFY
  CSeq: INVITE 101
  Expires: 180
  Allow-events: presence, kpml
  Support: X-cisco-srtp-relief
  Support: geolocation
  Call-Info: ; method = "NOTIFY; Telephone-event = event; duration = 500 "
  Cisco-Guid: 1422849408-0000065536-0000391810-0100733962
  Session time-out: 1800
  P has asserted-Identity: <> [email protected]/ * / >
  Remote-Party-ID: <> [email protected]/ * / >; left = call; screen = yes; intimacy = off
  Contact: <> [email protected]/ * /: 5060; transport = tcp >
  Max-Forwards: 70
  Content-Length: 0

  * 3 Dec 12:08:32.863: //-1/54CEF5800005/CCAPI/cc_api_display_ie_subfields:
  cc_api_call_setup_ind_common:
  Cisco-username = 02036666666
  -ccCallInfo IE subfields-
  Cisco-ani = 02036666666
  Cisco-anitype = 0
  Cisco-aniplan = 0
  Cisco-anipi = 0
  Cisco-anisi = 1
  dest = 907718005555
  Cisco-desttype = 0
  Cisco-destplan = 0
  Cisco-ISDS = FFFFFFFF
  Cisco-rdn =
  Cisco-rdntype = 0
  Cisco-rdnplan = 0
  Cisco-rdnpi =-1
  Cisco-rdnsi =-1
  Cisco-redirectreason = - 1 fwd_final_type = 0
  final_redirectNumber =
  hunt_group_timeout = 0

  * 3 Dec 12:08:32.863: //-1/54CEF5800005/CCAPI/cc_api_call_setup_ind_common:
  Interface = 0 x 31196458, call Info)
  Number = 02036666666, (Calling Name =) (TON = unknown, NPI = unknown, screening = User, spent, presentation = allowed).
  Called number = 907718005555 (TON = unknown, NPI = unknown).
  The appeal translated = FALSE, Subscriber Type Str = unknown, FinalDestinationFlag = TRUE,
  Incoming dial-peer = 50, progress Indication = NULL (0), Calling THE Present = TRUE,
  Road Trkgrp Label source, label Trkgrp road target = CLID Transparent = FALSE), call Id = 21355
  * 3 Dec 12:08:32.863: //-1/54CEF5800005/CCAPI/ccCheckClipClir:
  In: Component number = 02036666666 (TON = unknown, NPI = unknown, screening = User, spent, presentation = allowed)
  * 3 Dec 12:08:32.863: //-1/54CEF5800005/CCAPI/ccCheckClipClir:
  Departures: Component number = 02036666666 (TONE = unknown, NPI = unknown = User, spent, screening presentation allowed =)
  * 3 Dec 12:08:32.863: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

  * 3 Dec 12:08:32.863: cc_get_feature_vsa success of malloc
  * 3 Dec 12:08:32.863: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

  * 12:08:32.863 3 dec: cc_get_feature_vsa number is 1
  * 3 Dec 12:08:32.863: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

  * 12:08:32.863 3 dec: FEATURE_VSA attributes are: feature_name:0, feature_time:832856160, feature_id:21306
  * 12:08:32.863 3 dec: / / 21355, 54CEF5800005, CCAPI, cc_api_call_setup_ind_common:
  Set up the event sent;
  Call Info (number = 02036666666 (TON = unknown, NPI = unknown, screening = User, spent, presentation = allowed),)
  Called number = 907718005555 (TON = unknown, NPI = unknown))
  * 12:08:32.863 3 dec: / / 21355, 54CEF5800005, CCAPI, cc_process_call_setup_ind:
  Event = 0x2AFCEB88
  * 3 Dec 12:08:32.863: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
  Try again with the demoted called number 907718005555
  * 12:08:32.863 3 dec: / / 21355, 54CEF5800005, CCAPI, ccCallSetContext:
  Context = 0x32D52B8C
  * 12:08:32.863 3 dec: / / 21355, 54CEF5800005, CCAPI, cc_process_call_setup_ind:
  > Handed CCAPI cid 21355 with tag 50 app '_ManagedAppProcess_Default '.
  * 12:08:32.867 3 dec: / / 21355, 54CEF5800005, CCAPI, ccCallProceeding:
  Progress Indication = NULL (0)
  * 12:08:32.867 3 dec: / / 21355, 54CEF5800005, CCAPI, ccCallSetupRequest:
  Destination =, Calling IE date = TRUE, Mode = 0.
  Leaving Dial-peer = 11, Params = 0x2B62716C, Indication of progress = FROM SIDE IS NO ISDN (3)
  * 12:08:32.867 3 dec: / / 21355, 54CEF5800005, CCAPI, ccCheckClipClir:
  In: Component number = 02036666666 (TON = unknown, NPI = unknown, screening = User, spent, presentation = allowed)
  * 12:08:32.867 3 dec: / / 21355, 54CEF5800005, CCAPI, ccCheckClipClir:
  Departures: Component number = 02036666666 (TONE = unknown, NPI = unknown = User, spent, screening presentation allowed =)
  * 12:08:32.867 3 dec: / / 21355, 54CEF5800005, CCAPI, ccCallSetupRequest:
  The destination model = 9 t., called number = 07718009863, band numbers = FALSE
  * 12:08:32.867 3 dec: / / 21355, 54CEF5800005, CCAPI, ccCallSetupRequest:
  Number = 02036666666 (TON = unknown, NPI = unknown, screening = User, spent, presentation = allowed).
  Called number = 07718009863 (TON = unknown, NPI = unknown).
  Redirect = number, display of information is
  Account number 02036666666, Destination = final = TRUE flag,.
  GUID = 54CEF580-0001-0000-0005-FA820601140A, outbound Dial-peer = 11
  * 12:08:32.867 3 dec: / / 21355, 54CEF5800005, CCAPI, cc_api_display_ie_subfields:
  ccCallSetupRequest:
  Cisco-username = 02036666666
  -ccCallInfo IE subfields-
  Cisco-ani = 02036666666
  Cisco-anitype = 0
  Cisco-aniplan = 0
  Cisco-anipi = 0
  Cisco-anisi = 1
  dest = 07718009863
  Cisco-desttype = 0
  Cisco-destplan = 0
  Cisco-ISDS = FFFFFFFF
  Cisco-rdn =
  Cisco-rdntype = 0
  Cisco-rdnplan = 0
  Cisco-rdnpi =-1
  Cisco-rdnsi =-1
  Cisco-redirectreason = - 1 fwd_final_type = 0
  final_redirectNumber =
  hunt_group_timeout = 0

  * 12:08:32.867 3 dec: / / 21355, 54CEF5800005, CCAPI, ccIFCallSetupRequestPrivate:
  Interface = 0 x 31196458, Type of Interface = 3, = Destination, the Mode = 0x0,
  Call Params (number = 02036666666, (Calling Name =) (= unknown, NPI = unknown, screening = User, TON spent, presentation = allowed),)
  Called number = 07718009863 (TON = unknown, NPI = unknown), the appeal translated = FALSE,
  Subscriber Type Str = unknown, FinalDestinationFlag = TRUE, outgoing Dial-peer = 11, Call On County = FALSE,
  Trkgrp road Label source, label of road target Trkgrp =, tg_label_flag = 0, Application Call Id =)
  * 3 Dec 12:08:32.867: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

  * 3 Dec 12:08:32.867: cc_get_feature_vsa success of malloc
  * 3 Dec 12:08:32.867: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

  * 12:08:32.867 3 dec: cc_get_feature_vsa number is 2
  * 3 Dec 12:08:32.867: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

  * 12:08:32.867 3 dec: FEATURE_VSA attributes are: feature_name:0, feature_time:832857952, feature_id:21307
  * 12:08:32.867 3 dec: / / 21356, 54CEF5800005, CCAPI, ccIFCallSetupRequestPrivate:
  Application for facility call SPI's success; Interface type = 3, FlowMode = 1
  * 12:08:32.867 3 dec: / / 21356, 54CEF5800005, CCAPI, ccCallSetContext:
  Context = 0x2B62711C
  * 12:08:32.867 3 dec: / / 21355, 54CEF5800005, CCAPI, ccSaveDialpeerTag:
  Outbound Dial-peer = 11
  * 12:08:32.867 3 dec: / / 21356, 54CEF5800005, CCAPI, cc_api_call_proceeding:
  Interface = 0 x 31196458, Indication = NULL (0) progress
  * 12:08:32.871 3 dec: / / 21356/54CEF5800005/SIP/Msg/ccsipDisplayMsg:
  Envoy:
  GUEST sip:[email protected] / * /.XXX:5060 SIP/2.0
  Via: SIP/2.0/UDP 194.168.146.148:5060; branch = z9hG4bK4F1C77
  Remote-Party-ID: <> [email protected]/ * / >; left = call; screen = yes; intimacy = off
  From: <> [email protected]/ * / >; tag = E448A58-A24
  To: <> [email protected] / * /.XXX >
  Date: Monday, December 3, 2012 12:08:32 GMT
  Call ID: [email protected] / * /
  Supported: timer, resource-priority, replaces, sdp-anat
  Min - SE: 1800
  Cisco-Guid: 1422849408-0000065536-0000391810-0100733962
  User-Agent: Cisco-SIPGateway/IOS - 12.x
  Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, VIEW, SUBSCRIBE, NOTIFY, INFO, REGISTER
  CSeq: INVITE 101
  Time stamp: 1354536512
  Contact: <> [email protected]/ * /: 5060 >
  Expires: 180
  Allow-events: telephone-event
  Max-Forwards: 69
  Session time-out: 1800
  Content-Length: 0

  * 12:08:32.871 3 dec: / / 21355/54CEF5800005/SIP/Msg/ccsipDisplayMsg:
  Envoy:
  SIP/2.0 100 trying
  Via: SIP/2.0/TCP 10.20.1.6:5060; branch = z9hG4bK148c5e3b74ba77
  From: <> [email protected]/ * */>;tag=1130165~6e3f6e1b-b59e-4604-be6a-d6295dc18cf6-45522220
  To: <> [email protected]/ * / >
  Date: Monday, December 3, 2012 12:08:32 GMT
  Call ID: [email protected] / * /
  CSeq: INVITE 101
  Allow-events: telephone-event
  Server: Cisco-SIPGateway/IOS - 12.x
  Content-Length: 0

  * 12:08:32.899 3 dec: / / 21356/54CEF5800005/SIP/Msg/ccsipDisplayMsg:
  Received:
  SIP/2.0 100 trying
  Via: SIP/2.0/UDP 194.168.146.148:5060; received = 194.168.146.148; branch = z9hG4bK4F1C77
  From: <> [email protected]/ * / >; tag = E488A58-A24
  To: <> [email protected] / * /.XXX >
  Call ID: [email protected] / * /
  CSeq: INVITE 101
  Time stamp: 1354536512
  Content-Length: 0

  * 12:08:32.995 3 dec: / / 21356/54CEF5800005/SIP/Msg/ccsipDisplayMsg:
  Received:
  SIP/2.0 488 here is not Acceptable
  Via: SIP/2.0/UDP 194.168.146.148:5060; received = 194.168.146.148; branch = z9hG4bK4F1C77
  To: <> [email protected] / * /.XXX >; tag = 3563525093-836070
  From: <> [email protected]/ * / >; tag = E488A58-A24
  Call ID: [email protected] / * /
  CSeq: INVITE 101
  Allow: CANCEL, ACK, INVITE, BYE, OPTIONS, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH
  Contact: <> [email protected] / * /.XXX:5060 >
  Reason: Q.850; cause = 65
  Content-Length: 0

  * 12:08:32.995 3 dec: / / 21356, 54CEF5800005, CCAPI, cc_api_call_disconnected:
  Value = 127, Interface = 0 x 31196458, Call Id = 21356
  * 12:08:32.995 3 dec: / / 21356, 54CEF5800005, CCAPI, cc_api_call_disconnected:
  Call the entry (Responsed = TRUE, Cause value = 127, Retry Count = 0)
  * 12:08:32.995 3 dec: / / 21355, 54CEF5800005, CCAPI, ccCallReleaseResources:
  free xcoding reserved resource.
  * 12:08:32.995 3 dec: / / 21356, 54CEF5800005, CCAPI, ccCallSetAAA_Accounting:
  = 0, Id = 21356 Call Accounting
  * 12:08:32.995 3 dec: / / 21356, 54CEF5800005, CCAPI, ccCallDisconnect:
  Value = 127, Tag = 0x0, entry calls (previous disconnection Cause = 0, remove the Cause = 127)
  * 12:08:32.995 3 dec: / / 21356, 54CEF5800005, CCAPI, ccCallDisconnect:
  Value = 127, entered calls (Responsed = TRUE, Cause value = 127)
  * 12:08:32.999 3 dec: / / 21356, 54CEF5800005, CCAPI, cc_api_call_disconnect_done:
  Available = 0, Interface = 0 x 31196458, Tag = 0 x 0, Call Id 21356 =.
  Call the entry (disconnect Cause = 127, class voice Cause Code = 0, retry count = 0)
  * 12:08:32.999 3 dec: / / 21356, 54CEF5800005, CCAPI, cc_api_call_disconnect_done:
  Call interrupted event sent
  * 3 Dec 12:08:32.999: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

  * 3 Dec 12:08:32.999: cc_free_feature_vsa release A 31, 46758
  * 3 Dec 12:08:32.999: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

  * 3 Dec 12:08:32.999: free vsacount is 1
  * 12:08:32.999 3 dec: / / 21355, 54CEF5800005, CCAPI, ccCallDisconnect:
  Value = 127, Tag = 0x0, entry calls (previous disconnection Cause = 0, remove the Cause = 0)
  * 12:08:32.999 3 dec: / / 21355, 54CEF5800005, CCAPI, ccCallDisconnect:
  Value = 127, entered calls (Responsed = TRUE, Cause value = 127)
  * 12:08:32.999 3 dec: / / 21355/54CEF5800005/SIP/Msg/ccsipDisplayMsg:
  Envoy:
  SIP/2.0 500 Internal Server Error
  Via: SIP/2.0/TCP 10.20.1.6:5060; branch = z9hG4bK148c5e3b74ba77
  From: <> [email protected]/ * */>;tag=1130165~6e3f6e1b-b59e-4604-be6a-d6295dc18cf6-45522220
  To: <> [email protected]/ * / >; tag = E488ADC-CEC
  Date: Monday, December 3, 2012 12:08:32 GMT
  Call ID: [email protected] / * /
  CSeq: INVITE 101
  Allow-events: telephone-event
  Server: Cisco-SIPGateway/IOS - 12.x
  Reason: Q.850; cause = 127
  Content-Length: 0

  * 3 Dec 12:08:33.035: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
  Received:
  SIP ACK:[email protected]/ * /: SIP-5060/2.0
  Via: SIP/2.0/TCP 10.20.1.6:5060; branch = z9hG4bK148c5e3b74ba77
  From: <> [email protected]/ * */>;tag=1130165~6e3f6e1b-b59e-4604-be6a-d6295dc18cf6-45522220
  To: <> [email protected]/ * / >; tag = E488ADC-CEC
  Date: Monday, December 3, 2012 12:02:40 GMT
  Call ID: [email protected] / * /
  Max-Forwards: 70
  CSeq: 101 ACK
  Allow-events: presence, kpml
  Content-Length: 0

  * 12:08:33.039 3 dec: / / 21355, 54CEF5800005, CCAPI, cc_api_call_disconnect_done:
  Available = 0, Interface = 0 x 31196458, Tag = 0 x 0, Call Id = 21355.
  Call the entry (disconnect Cause = 127, class voice Cause Code = 0, retry count = 0)
  * 12:08:33.039 3 dec: / / 21355, 54CEF5800005, CCAPI, cc_api_call_disconnect_done:
  Call interrupted event sent
  * 3 Dec 12:08:33.039: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

  * 3 Dec 12:08:33.039: cc_free_feature_vsa release A 31, 46058
  * 3 Dec 12:08:33.039: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

  * 3 Dec 12:08:33.039: free vsacount is 0
  * 3 Dec 12:08:33.039: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
  Envoy:
  SIP ACK:[email protected] / * /.XXX:5060 SIP/2.0
  Via: SIP/2.0/UDP 194.168.146.148:5060; branch = z9hG4bK4F1C77
  From: <> [email protected]/ * / >; tag = E488A58-A24
  To: <> [email protected] / * /.XXX >; tag = 3563525093-836070
  Date: Monday, December 3, 2012 12:08:32 GMT
  Call ID: [email protected] / * /
  Max-Forwards: 70
  CSeq: 101 ACK
  Allow-events: telephone-event
  Content-Length: 0

  Thank you very much

  Chris

  Hi Chris,

  It seems that your CUBE config is correct. The CUCM sends a PROMPT to provide at the beginning now. This means that you have enabled the PSG on the SIP trunk. The codec sent in the INVITATION is G711ulaw. In order to change this, go to the SIP trunk and search "PSG preferred from Codec" and replace it by default of G711ulaw, G711alaw. If all goes well, which does the trick for you.

  HTH.

  Kind regards

  Stefano.

• SPA112 &amp; SIP122 - bytes of garbage sent using the SIP over TCP

  Because the port UDP 5060 is blocked in my case, the SIP over TCP is a good solution for me.

  But when I put SPA112 to use SIP over TCP, the server record is still broken.

  (I used the version of the firmware is latest: 1.3.3 but older versions has the same behavior.)

  After capturing packets, a problem is found:

  Each time before SPA112 has sent a message to register, there were 9 frames of data sent before him.

  Each frame has 20 bytes, and the content is the same.

  The 20 bytes has a motive: the first 4 bytes is always 00 01 00 00.

  So come with 4 * 4 bytes, for example, d8 22 6 b 17 d8 d8 d8 22 6 b 17 22 6 b 17 b 22 6, 17

  So, in the stream TCP, the register message is like:

  ....."k.." k.. » k.. » k......"k.." k.. » k.. » k......"k.." k.. » k.. » k......"k.." k.. » k.. » k......"k.." k.. » k.. » k......"k.." k.. » k.. » k......"k.." k.. » k.. » k......"k.." k.. » k.. » k......"k.." k.. "" k... "k.NOTIFY sip:sip.callwithus.com:5060 SIP/2.0

  Via:...

  The server responded immediately "SIP/2.0 484 address incomplete."

  Then send SPA112 record message again, this time it succeeded and the server response "SIP/2.0 401 Unauthorized '.

  Seems good.

  Subsequently, SPA112 has sent a new message digest information register but the bytes of garbage appeared again.

  Is there any configuration on this bytes of garbage?

  It seems that you hit the Nice firmware bug. I can tell you what I see in captured TCP stream.

  Your client is connected to the SIP server, but it is not start sending SIP messages - it STUN via the stream instead. You caught "STUN Binding request" nine times before the first SIP package. And an another STUN is tried before the second REGISTER.

  This is a bug with doubt - STUN have nothing to do in the stream TCP SIP. As the switch waits for the SIP packets, it is confused by byte STUN causing packets SIP to be misunderstood and rejected.

  Unfortunately, I have no idea how to report a bug in firmware to Cisco, unless you are willing to pay for it.

  On the other side, it would be that hard to solve the problem. Just disable the STUN.

  Thread mark as answered if it solves your problem, it will help others to find solutions.