locked
Cisco CUBE IOS Version RRS feed

  • Question

  • We are running OCS Mediation <=> Cisco Cube <=> CCM 4.13 (So the cube is converting SIP to H323)

     

    Hopefully other people are running this configuration and I would be very interested to know what IOS version you are running and if you are experiencing any problems.

     

    We are using c2800nm-spservicesk9-mz.124-15.XZ

    The only issue we are experiencing is a relatively high level of dropped calls which has increased since we switched over to the Cube instead of using a dialogic gateway connecting via E1.

    (The rate of dropped calls would appear to have doubled to about 4% up from about 2%. The way we measure suspected dropped calls is to look at the CDR records and look for patterns where the same user dials the same number within a minute and for calls which last longer then a few minutes.)

     

    Thanks

     

     

     

    Wednesday, August 6, 2008 11:46 AM

Answers

  • I thought you may have the document but wasnt sure. So the SIP ua timer will still apply to SIP to H323 as the connection to OCS will still time out with no mid call signaling to refresh the session so I would certainly make sure to adjust that timer as it will make a difference to hold issues. So any call longer than 5 mintues that are placed on hold will drop with out a session refresh or a change to that timer. If you were using Callmanager 6.x you could enable midcall-signaling passthru to have the callmanager do your session refresh but since you are on 4.1.3 extending this timer is the only choice. I have tested with SIP-H323 and this solves the issue.

     

    I will send an email to your listed address in your profile so we can talk more offline. I am really interested to here about any other issue you may have noticed.

     

    Cheers

    Chris

    Wednesday, August 6, 2008 3:14 PM

All replies

  •  

    Hi AlistairK

     

    I have been working with MSFT for sometime on this and you have some interesting data there. 12.4-15xz has some interesting upgraded SIP features that can also be found in 12.4-20t which I have tested in our labs. We are currently using 12.49t6 in our production pilot and although I have had no reports from users of dropped calls I do susupect there would be some. It would be interesitng to know when your calls are dropping. There are a few issues that can cause your calls to drop some most related to calls being put on hold on the OCS side. This can be fix by extending the timers connection aging  to 120 under the SIP-ua. Below is an excerpt from a document that I wrote that Microsoft is using for customers. You can change 12.4-15xz for 12.4-20t. you may also want to check the rebuild of the 15xz code 15xz1 to see if there are some bug fixes that may help.

     

    Hope this helps

     

    Cheers

    Chris

    ===============================================================================

    Simultaneous ringing and call forward all

    IP-IP GW currently does not support 183 Session progression messages with no SDP or the use of the 181 “call is being forwarded”. This has the following effects:

    Simultaneous ring when no logged onto MOC – No ring back on the calling end, calls may prematurely end due to a failure for the PSTN receive session progression messages dropped by the IP-IP GW

    Call forward all- due to no support for 181 and 183 session progression messages on the IP-IP GW call forwarded calls may fail due to the PSTN gateway interface not receiving notification of a session progress.

    There is currently a work around available using Microsoft SIP Processing Language – MSPL. The script below is “respond with ringing”. Please refer to MSFT documentation for further details on using and applying scripts.

     

    http://msdn.microsoft.com/en-us/library/bb632061.aspx

     

     IOS routing behavior changes in 12.4(15xz) compared to 12.4(9t6)

    IOS changes on inbound routing of the (+) sign may require changes to the configuration stated in this document. Later IOS version beyond 12.4(9t6) no longer require the use of inbound translation rules to remove the (+) sign and it is removed by default. This change in behavior will still require the use of translation rules to append the (+) sign on inbound calls to OCS for number name resolution in the address book if the address book has been normalized.

    Example dial peer for 12.4(15xz). Translation profile can be used to remove or add digits depending on the desired inbound requirement of CUCM

    !

    dial-peer voice 905 voip

     description to Callmanager

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

     session protocol sipv2

     session target ipv4:X.X.X.X

     session transport tcp

     dtmf-relay rtp-nte sip-notify

     codec g711ulaw

     no vad

    !

     

     12.4(9t6) and earlier

    !

    dial-peer voice 901 voip

     description to Callmanager

     translation-profile outgoing 101

    destination-pattern +T

     session protocol sipv2

     session target ipv4:X.X.X.X

     session transport tcp

     dtmf-relay h245-alphanumeric

     codec g711ulaw

     no vad

    IOS 12.4(15xz)

    Versions of Cisco IOS before 12.4(15xz) do not support re-invite messages from Callmanager or OCS and will drop calls when the re-invite is issued. The use of the command “midcall-signaling passthru” overcomes this limitation and is only available in 12.4(15xz) and beyond.

    Option-ping command available in the 12.4(15xz) removes the need to extend TCP session timers by refreshing sessions before they reach the default 5 minute expire time. If the TCP timer expires mid call signaling (e.g. on-hold) may cause calls to be prematurely terminated by the IP-IP GW. For IOS earlier the following commands allow the extension of TCP timer beyond the default of 5 minutes.

    sip-ua

     timers connection aging 120

    Wednesday, August 6, 2008 2:31 PM
  • Ahh _ thanks.

    So you wrote that excellent document. Great bit of work.

    (It really helped us get over a few problems. One to do with number normalization. The other issue we had was DTMF not working reliably but this turned out to be IOS related. When we used 15xz the issue went away)

     

    I understood that the timer SIP-ua only really applies if you are SIP to SIP but we are SIP to H323.

     

    I just tried 15xz1 but it has problems with call hold. ie if from OCS I make another call both will drop when the second calls connects.

     

    I will work though your list of suggestions and report back _ thanks.

     

    On the call drops with 15xz

    The gateways have not rebooted, CPU utilization has been below 25%, drops appear to be per session i.e. some calls will be dropped while other continue ok. Call duration before call drops appear to be random

    The "grumble" from users is that they are dropped mid call.

     

     

    Wednesday, August 6, 2008 2:55 PM
  • I thought you may have the document but wasnt sure. So the SIP ua timer will still apply to SIP to H323 as the connection to OCS will still time out with no mid call signaling to refresh the session so I would certainly make sure to adjust that timer as it will make a difference to hold issues. So any call longer than 5 mintues that are placed on hold will drop with out a session refresh or a change to that timer. If you were using Callmanager 6.x you could enable midcall-signaling passthru to have the callmanager do your session refresh but since you are on 4.1.3 extending this timer is the only choice. I have tested with SIP-H323 and this solves the issue.

     

    I will send an email to your listed address in your profile so we can talk more offline. I am really interested to here about any other issue you may have noticed.

     

    Cheers

    Chris

    Wednesday, August 6, 2008 3:14 PM
  • I think the SIP ua timer may have fixed the issue.

     

    I didn't apply it earlier as I was told it would only apply to SIP to SIP.

    However based on todays results the rates of dropped calls using the original IOS looks like being the normal background level.

     

    I will monitor and post up.

     

    Thanks again !

    Thursday, August 7, 2008 3:21 PM
  •  

    Hi Chris,

     

    We experimented a similar issue where the in SIP we trunked in IP a CCM behind a CUBE.

    When the call is put in hold, then the CUBE never released the Hold.

     

    If you have any clue on this topic, it would be helpfull

    Thanks in advance for your help

    Best regards

    Bertrand 

    Friday, September 26, 2008 2:51 PM
  • Hi Bertrand,

     

    Yes this is an issue that can be fixed:-) So this is a very deciving problem. The call is actually dropped but MOC doesnt show it as that. So its related to two things. The non support of a refresh and the expiration of the TCP timers. Even thoguh Options Ping can fix the issue I think changing the TCP timers is the best option. In IOS 12.4.15xz and beyond the timer can be extended to beyond three hours but I think 60-90 minutes should would work for most calls. Here is a description below that should fix that issue. Although it doesnt mention hold it still is part of the same issue. Of course the TCP part refers to the SIP portion of the call not RTP:-)

     

    IOS 12.4(15xz)

    Versions of Cisco IOS before 12.4(15xz) do not support re-invite messages from Callmanager or OCS and will drop calls when the re-invite is issued. The use of the command “midcall-signaling passthru” overcomes this limitation and is only available in 12.4(15xz) and beyond.

    Option-ping command available in the 12.4(15xz) removes the need to extend TCP session timers by refreshing sessions before they reach the default 5 minute expire time. If the TCP timer expires mid call signaling (e.g. on-hold) may cause calls to be prematurely terminated by the IP-IP GW. For IOS earlier the following commands allow the extension of TCP timer beyond the default of 5 minutes.

    sip-ua

     timers connection aging 30

     

    Cheers

    Chris

     

    Friday, September 26, 2008 3:34 PM
  • A quick update on thoughts and experiences

     

    This section is really about how to get call manager to talk to OCS.

    I think the "Setting up the Cisco Call Manager 4.2.1 for “Direct SIP with IP-PBX” article by Microsoft has much to recommend it. In my lab testing it appear to work even with CCM 4.13SR5B. (It did not work with CCM 4.13SR5B)

     

    The only area which is yet to be fixed is for example

    If I call +7001 the PBX phone rings. MOC says calling +7001. On answer moc shows connected number as 7001 and the recent contacts list +7001 and 7001 (on answer)

     

    With the Cube we are going OCS (SIP) <=> Cube <=> CCM 4.13 (H323)

    We have yet to test but a TAC case has located the potential cause of our dropped calls being h.323 keepalives between the Callmanager cluster and the CUBE

    We have yet to test but have been told that the following setting should clear it

    Call Manager Service Parameter (Advanced Settings) ‘Allow TCP KeepAlives for H323’ to False

    (This is probably only be an issue because we have a firewall between CCM and the Cube)

     

    On the IOS version

    We are currently running

            c2800nm-spservicesk9-mz.124-15.XZ.bin with no issues other then random dropped calls

     

    In our limited testing we have found the following

    Tested _ quickly eleimiated these for the following reasons

           c2800nm-spservicesk9-mz.124-15.T6.bin _DTMF Issue. Only occurs if on mute. The first DTMF digit would be repeated

           c2800nm-spservicesk9-mz.124-9.T7.bin _DTMF Issue. Only occurs if on mute. The first DTMF digit would be repeated

           c2800nm-spservicesk9-mz.124-20.T.bin _ If a call was established from OCS  and then tried to place another call both would fail

           c2800nm-spservicesk9-mz.124-15.XZ1.bin _ If a call was established from OCS  and then tried to place another call both would fail

     

    Wednesday, October 8, 2008 7:57 AM
  • Hi Alistair,

     

    Nice summary of your issues you have found. I concur with your direct SIP trunking results but with 4.2.3sr4a. The problem with MOC recent contacts is a pain but much less painful than dropped calls:-)

     

    Cheers

    Chris

    Wednesday, October 8, 2008 3:02 PM
  • I've got a Cisco2821 used as CUBE connected via h323 to CallManager 4.2(3)SR1 and on the other side connected via SIP to Microsoft Mediation Server.

    When I call from OCS to a CiscoPhone, sometimes there is no voice and when there is voice, it is not possible to take the call on hold at the OCS Client, it just mutes the microphone.

    When there is no voice, the call is disconnected after some seconds

    When there is voice, there are SIP messages, but no h225 messages on the CUBE.

    Attached you find a output of debug h225 q931 and a show call active media compact and the relevant configuration.

    What I'm wondering, from where comes the g729r8 codec in the show call active media output, as there is nowhere g729 enabled.

     

    On the Cisco2811 I'm running c2800nm-adventerprisek9_ivs-mz.124-15.XY3

    Any idea?

     

    Greetz

    Peter

    Wednesday, October 8, 2008 7:26 PM
  • Peter,

     

    I dont see your attachments for some reason. Try pasting them straight in the window. If you want to try something though change your IOS to 15.XZ and see if this changes the behaviour. I am not familar with XY3 and is not a version I would recommend for this purpose. Also please print your configuration with the debug.

     

    Cheers

    Chris

     

    Thursday, October 9, 2008 2:26 PM
  • Chris

     

    I changed to 12.4(15)XZ1, but still the same. Below you see a debug, show output and the conf.

     

    MOCS_Gateway11#
      Q931 Message IE Decodes
    Protocol Discriminator : 0x08
    CRV Length             : 2
    CRV Value              : 0x000E
    Message Type           : 0x05: SETUP
     Bearer Capability: Length Of IE=3
     Data 8090A3
     Calling Party Number: Length Of IE=5
     Data 8037373730
     Called Party Number: Length Of IE=5
     Data 8032323334
     User-User: Length Of IE=154
     Data 052080060008914A00042800B500001240013C050100008676043E947B11DD806FF801075D575700CD1D820007000A690B4C6786110086773C8E947B11DD8071F801075D57573402130000000C6013800B050001000A690B4C479F801E400000060401004C60138012150001000A690B4C479E000A690B4C479F8001000100018001800100118010010E60000110001000015504430000000180
      Q931 Message IE Decodes
    Protocol Discriminator : 0x08
    CRV Length             : 2
    CRV Value              : 0x800E
    Message Type           : 0x02: CALL_PROC
     User-User: Length Of IE=51
     Data 052180060008914A0002020120110086773C8E947B11DD8071F801075D57570AA001000F0140B50000120880C4000400010100
      Q931 Message IE Decodes
    Protocol Discriminator : 0x08
    CRV Length             : 2
    CRV Value              : 0x800E
    Message Type           : 0x01: ALERTING
     User-User: Length Of IE=51
     Data 052380060008914A0002020120110086773C8E947B11DD8071F801075D57570AA001000F0140B50000120880C4000400010100
    MOCS_Gateway11#
      Q931 Message IE Decodes
    Protocol Discriminator : 0x08
    CRV Length             : 2
    CRV Value              : 0x800E
    Message Type           : 0x6E: NOTIFY
     Notification Ind: Length Of IE=1
     Data F1
     Connected Number: Length Of IE=5
     Data 8032323334
     User-User: Length Of IE=33
     Data 0528501900060008914A00020086773C8E947B11DD8071F801075D57570A800100
    MOCS_Gateway11#
    MOCS_Gateway11#
    MOCS_Gateway11#
    MOCS_Gateway11#
    MOCS_Gateway11#
      Q931 Message IE Decodes
    Protocol Discriminator : 0x08
    CRV Length             : 2
    CRV Value              : 0x800E
    Message Type           : 0x07: CONNECT
     Bearer Capability: Length Of IE=3
     Data 8090A2
     User-User: Length Of IE=75
     Data 0522C0060008914A000200AC12010AD5BF02008676043E947B11DD806FF801075D57570900110086773C8E947B11DD8071F801075D57570AA001000F0140B50000120880C4000400010100
      Q931 Message IE Decodes
    Protocol Discriminator : 0x08
    CRV Length             : 2
    CRV Value              : 0x800E
    Message Type           : 0x6E: NOTIFY
     Notification Ind: Length Of IE=1
     Data F1
     Connected Number: Length Of IE=6
     Data 008132323334
     User-User: Length Of IE=33
     Data
    MOCS_Gateway11#0528501900060008914A00020086773C8E947B11DD8071F801075D57570A800100
    MOCS_Gateway11#
    MOCS_Gateway11#
    MOCS_Gateway11#
    MOCS_Gateway11#sh call act med com
     <callID>  A/O FAX T<sec> Codec       type        Peer Address       IP R<ip>:<udp>
    Total call-legs: 2
            43 ANS     T3     g711ulaw    VOIP        P+41323267770     10.105.11.74:62100
            44 ORG     T3     g729r8 pre- VOIP        P2234          0.0.0.0:0

    MOCS_Gateway11#
    MOCS_Gateway11#sh run
    !
    ip cef
    !
    !
    no ip domain lookup
    no ipv6 cef
    !
    multilink bundle-name authenticated
    !
    !
    !
    voice rtp send-recv
    !
    voice service voip
     allow-connections h323 to h323
     allow-connections h323 to sip
     allow-connections sip to h323
     allow-connections sip to sip
     supplementary-service h450.12
     supplementary-service media-renegotiate
     redirect ip2ip
     h323
      emptycapability
      h225 connect-passthru
      h245 caps mode restricted
     sip
      bind control source-interface GigabitEthernet0/0
      bind media source-interface GigabitEthernet0/0
      session transport tcp
      rel1xx supported "rel100"
      options-ping 90
    !
    !
    !
    voice class codec 1
     codec preference 1 g711ulaw
     codec preference 2 g711alaw
    !
    !
    voice translation-rule 1
     rule 1 /^\+4132326/ /0004132326/
     rule 2 /^\+41/ /00041/
     rule 3 /^\+/ /000/
     rule 4 /^\000/ /+/
    !
    voice translation-rule 2
     rule 1 /^\00/ /+41/
     rule 2 /^\.*/ /+4132326/
    !
    voice translation-rule 3
     rule 1 /^\+4132326/ //
    !
    !
    voice translation-profile FROM-MEDIATION-TO-CCM
     translate calling 3
     translate called 3
    !
    voice translation-profile FROM-MEDIATION-TO-ISDN
     translate calling 1
     translate called 1
    !
    voice translation-profile TO-MEDIATION
     translate calling 2
     translate called 1
    !
    !
    voice-card 0
     no dspfarm
     dsp services dspfarm
    !
    !
    username cassa privilege 15 password 7 095C4F1A0A
    archive
     log config
      hidekeys
    !
    !
    interface GigabitEthernet0/0
     ip address aaa.aaa.aaa.aaa 255.255.255.0
     duplex auto
     speed auto
     h323-gateway voip interface
     h323-gateway voip bind srcaddr aaa.aaa.aaa.aaa
    !
    interface GigabitEthernet0/1
     no ip address
     shutdown
     duplex auto
     speed auto
    !
    ip forward-protocol nd
    ip route 0.0.0.0 0.0.0.0 10.105.11.1
    !
    !
    ip http server
    no ip http secure-server
    !
    !
    control-plane
    !
    !
    sccp local GigabitEthernet0/0
    sccp ccm xxx.xxx.xxx.xxx identifier 1 version 4.1
    sccp
    !
    sccp ccm group 1
     associate ccm 1 priority 1
     associate profile 2 register MTP002255ca8980
     associate profile 1 register MOCS_GTW_11
    !
    dspfarm profile 1 transcode
     codec g711ulaw
     maximum sessions 12
     associate application SCCP
    !
    dspfarm profile 2 mtp
     codec g711ulaw
     maximum sessions software 100
     associate application SCCP
    !
    !
    dial-peer voice 97770 voip
     description outbound to MEDIATION21
     translation-profile outgoing TO-MEDIATION
     preference 2
     destination-pattern 777[0-6]
     session protocol sipv2
     session target ipv4:10.105.11.74
     session transport tcp
     dtmf-relay sip-kpml
     codec g711ulaw
     no vad
    !
    dial-peer voice 1 voip
     description outbound to CCM 4.2(3)
     translation-profile incoming FROM-MEDIATION-TO-CCM
     preference 1
     destination-pattern .T
     session target ipv4:xxx.xxx.xxx.xxx
     incoming called-number +41323261...
     dtmf-relay h245-alphanumeric
     codec g711ulaw
     no vad
    !
    dial-peer voice 3 voip
     description outbound to CCM 4.2(3)
     translation-profile incoming FROM-MEDIATION-TO-CCM
     preference 1
     destination-pattern .T
     session target ipv4:xxx.xxx.xxx.xxx
     incoming called-number +41323267[6-9]..
     dtmf-relay h245-alphanumeric
     codec g711ulaw
     no vad
    !
    dial-peer voice 8 voip
     description outbound from Mediation to ISDN
     translation-profile incoming FROM-MEDIATION-TO-CCM
     preference 1
     destination-pattern 00041.........
     session target ipv4:xxx.xxx.xxx.xxx
     incoming called-number +T
     codec g711ulaw
     no vad
    !
    dial-peer voice 10 voip
     description outbound to CCM 4.2(3) SIP
     translation-profile incoming FROM-MEDIATION-TO-CCM
     preference 1
     destination-pattern .T
     session protocol sipv2
     session target ipv4:xxx.xxx.xxx.xxx
     session transport tcp
     incoming called-number +41323262...
     dtmf-relay h245-alphanumeric
     codec g711ulaw
     no vad
    !
    !
    gateway
     timer receive-rtp 1200
    !
    sip-ua
    !
    gatekeeper
     shutdown
    !

     

     

    Regards

    Peter

    Friday, October 10, 2008 10:29 AM
  • Hi Peter,

     

    I am looking through your configuration at the moment and one thing I think may help is to separate your incoming dial peers from your outgoing dial peers to simplify your configuration. So for each dial peer only have one statement of either incoming called or destination pattern unless you are trying to achieve something here I am just not seeing. But you have an incoming translation profile named different to your description kind of makes it a little hard to read. I know you can combine the two but to me it just makes people confused especially when troubleshooting. I think in general you need to strip out anything that isn’t actually doing something to help your trouble shooting a little easier. In 12.4.15xz the incoming + sign on the called number is automatically stripped out. So any inbound configuration you have to compensate for the + could be removed.

     

    Your debug is kind of meaningless to me without the corresponding debug ccsip message information. So I am going to skip it.Sorry.

     

    Here is some configuration information you might like to try.

     

    Remove these two commands as they are not required unless you are doing transcoding and the second command does nothing;

    supplementary-service media-renegotiate
     redirect ip2ip


     It should look more like this:

    !
    voice service voip
      allow-connections h323 to h323
     allow-connections h323 to sip
     allow-connections sip to h323
     allow-connections sip to sip
     supplementary-service h450.12
     fax protocol pass-through g711ulaw
     h323
      emptycapability
     sip
      bind control source-interface FastEthernet0/0
      bind media source-interface FastEthernet0/0
     !

     

    Unless you are transcoding you can also remove:

     

    !
    dspfarm profile 1 transcode
     codec g711ulaw
     maximum sessions 12
     associate application SCCP
    !

     

    And any other configuration that revolves around these commands including configuration in the Callmanager for the transcoders.

     

    For your dial peers:

     

    Outbound to OCS

     

    dial-peer voice 206 voip

     description to To  OCS Mediation server

     translation-profile outgoing (to add the + to the called number and the calling number)

     destination-pattern 1206…….

     session protocol sipv2

     session target ipv4:XX>XX>XX>XX

     session transport tcp

     dtmf-relay rtp-nte

     codec g711ulaw

     ip qos dscp cs3 signaling

     no vad


     

    Outbound to Callmanager 4.2.3

    !

    dial-peer voice 906 voip

     description to Callmanager 4.X

     translation-profile outgoing (you may want ot remove digits here but removing the plus is not required)

     preference 1

     destination-pattern 1[2-9]..[2-9]...... (.T can cause issues and it is hard to control your dialpeers. This pattern matches NANP but you can change it to anythign you want)

     session target ipv4:XX.XX.XX.XX

     dtmf-relay h245-alphanumeric

     codec g711ulaw

     no vad

    !

    Inbound from OCS.  Remember no need to compensate for the + as it is automatically removed inbound in 15xz and beyond. Keep it simple and try to do digit manipulation outgoing on your outbound dial peer if you can. I say this becuase if you do it that way you no longer need to worry about the order of operations of dial-peers and transaltions which can get tricky if you dont remember.

    Dial-peer

    description inbound from  OCS Mediation server

    incoming called-number .

     session protocol sipv2

     session transport tcp

     dtmf-relay rtp-nte

     codec g711ulaw

    no vad


    Inbound from Callmanager. Main thing here is to call out your OCS dial patterns so that anything coming from callmaanger gets the correct DTMF commands.

    Dial-peer
    description inbound from  CUCM

     incoming called-number 1206.

     dtmf-relay h245-alphanumeric

     codec g711ulaw

     no vad

     

     

    Hope this helps. I can only think that this is a problem with your configuration as there are plenty of people out there doing this similar setup you have described (including my self and Alistair). Remember keep your IOS config as simple as possible and try to do fancy translations in the Callmanager or OCS before it get to the gateway if you can as it will help to make your configuration simpler.

     

    Cheers

    Chris

     

    Friday, October 10, 2008 7:57 PM
  • Hi Chris

     

    Thanks for your reply!

     

    I've the problem with the hold solved now, I removed the destination .T statement in a dial-peer.

    But now there is an other problem :-( When I call from PSTN I see my Microsoft Client ringing, but when I try to answer the call it gets disconnected and immediately (without doing something) my Microsoft Client is ringing once again and I can take the call without problems. Then I take the call on hold, resume it and there is no voice anymore and the call gets disconnected after a few seconds.

     

    It's really confusing me.

     

    Regards

    Peter

    Monday, October 13, 2008 4:01 PM
  • Hi Chris

     

    I got this resolved now as well, the only thing I still got is no ringback tone, when there is a call forward on MOCS to external numbers.

     

    Any idea?

    Regards

    Peter

     

    Tuesday, October 14, 2008 9:09 AM
  • Yes I have an idea:-) Its not a bug but an interopability issue between Cisco and Microsoft. OCS does not support haripinning early media therefore when the call forwarding is set you get no ringback. This may also affect simultaneous ringing in OCS when users are logged off. There is a fix available through your support contacts at MSFT, sorry I cant post it here. But i can describe it. Using MSPL you can create a false ring back message to indicate to the Callmanager that the call is proceding when you get an invite so Callamanger will generate the ringback.

     

    Cheers

    Chris

     

    Tuesday, October 14, 2008 3:37 PM
  • Chris

     

    I resolved this as well.

    We migrated about 100 users to this solution and they made the experience, that they get disconnected after arround 30 s.

    Do you have an idea why this happens?

     

    Regards

    Peter

     

    Monday, October 20, 2008 11:00 AM
  • Hi Peter,

     

    Thats a new one on me. Is this consistant behaviour. Like happens everytime they connect or is it hit and miss, where sometimes it happens and other times it doesnt? Also is it 30sec or minutes and is it exactly 30 seconds? What version of Callmanager are you running? Make sure you have the comman below enabled as it may or maynot be the cause but it will only help with another issue you havent run in to yet:-)

     

    !

    sip-ua

     timers connection aging 90

     

    And if you are running CCM version 5.x and beyond this command can help as well. Midcall-signaling will allow reinvites to pass through the cube.

     

    !

    voice service voip

     allow-connections h323 to sip

     allow-connections sip to h323

     allow-connections sip to sip

     supplementary-service h450.12

     sip

      bind control source-interface FastEthernet0/0

      midcall-signaling passthru

     

    Cheers

    Chris

    Monday, October 20, 2008 3:37 PM
  • Hi Chris

     

    thanks for the answer.

     

    At the moment I have no access to the systems, so I will have a look to these command you mentioned tomorrow.

     

    I'm running CCM 4.2(3)SR1 and on the cube 12.4(22)T. It happens not all the time, just sometimes. It mostly disconnects between 30 seconds and a minute. The disconnection occurs for calls between MOC and Cisco-Phone and between MOC and PSTN.

     

    Some users made also the experience, that there was no voice when they picked up the phone.

     

    In an other threat in this forum I read something about the h323 TCP keepalive timer has to be set to false in CCM.

    Might this be a reason?

     

    What I saw on CUBE is, that it is using some transcoding ressources, might it be that there are not enough ressources available? Currently it is enabled for 12 sessions. In CCM, CUBE is configured as MTP(transcoding).

     

    I've also raised a TAC Case for the problems I've got and for this we enabled some debugs on all systems involved. 

     

    Regards

    Peter

     

    Monday, October 20, 2008 9:42 PM
  • Chris

     

    can you provide me a running configuration of your CUBE and a screenshot of the h323 gateway within CCM?

     

    Greetz

    Peter

    Tuesday, October 21, 2008 4:39 PM
  • Hi Peter,

     

    The H323 gateway is pretty simple. Everything is default except fpr the MTP required which is selected. Ensure you also have a MRGL selected that also contain a MTP. Here is a pretty basic config for a CUBE to connect to 4.2.3 or 6.1 using H323 or SIP. MTP's are on board in software please refer to CCO on setting up MTP's in CCM. I havent supplied any complex routing rules to make it easier to understand. The IOS used for this configuration must be 12.4.15xz or later. 12.4.15T7 would also be fine.

     

    #sh run

    Building configuration...

     

    ip cef

    !

    !

    no ip domain lookup

    ip domain name

    ip name-server

    ip multicast-routing

    !

    !

    voice-card 0

     dspfarm

     dsp services dspfarm

    !

    !

    !

    voice service voip

     allow-connections h323 to sip

     allow-connections sip to h323

     allow-connections sip to sip

     supplementary-service h450.12

     sip

      bind control source-interface FastEthernet0/0

      midcall-signaling passthru

      !

    !

    !

    voice translation-rule 103

     rule 1 /^\(206.......\)/ /+\1/

     rule 2 /^\([2-9].........\)/ /+1\1/

     rule 3 /^\(...........\)/ /+\1/

    !

    !

    voice translation-profile 103

     description Adds + to outbound calling numbers for OCS

     translate calling 103

    !

    !

    interface FastEthernet0/0

     ip address X.X.X.X 255.255.255.0

     duplex auto

     speed auto

    !

    interface FastEthernet0/1

     no ip address

     shutdown

     duplex auto

     speed auto

    !

    ip route 0.0.0.0 0.0.0.0

    ip flow-export version 9

    ip flow-export destination

    ip flow-aggregation cache as-tos

    !

    !

    ip http server

    !

    !

    sccp local FastEthernet0/0

    sccp ccm X.X.X.X  identifier 2 version 4.1

    sccp ccm X.X.X.X  identifier 1 version 4.1

    sccp

    !

    sccp ccm group 1

     description SCCP CCM group

     bind interface FastEthernet0/0

     associate ccm 1 priority 1

     associate ccm 2 priority 2

     associate profile 101 register MTP_4.2.3

    !

    dspfarm profile 101 mtp

     codec g711ulaw

     maximum sessions software 100

     associate application SCCP

    !

    !

    dial-peer voice 65180 voip

    description to OCS mediation server

     translation-profile outgoing 103

     destination-pattern 1999......

     session protocol sipv2

     session target ipv4:X.X.X.X

     session transport tcp

     dtmf-relay rtp-nte

     codec g711ulaw

    !

    dial-peer voice 900 voip

     description to Callmanager 6.1

     preference 1

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

     session protocol sipv2

     session target ipv4:X.X.X.X

     session transport tcp

     dtmf-relay rtp-nte

    codec g711ulaw

     no vad

    !

    !

    !

    dial-peer voice 901 voip

     description to Callmanager 6.1

      preference 2

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

     session protocol sipv2

     session target ipv4:X.X.X.X

     session transport tcp

     dtmf-relay rtp-nte

    codec g711ulaw

     no vad

    !

    dial-peer voice 902 voip

    Description to Callmanager 4.X

    preference 3

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

     session target ipv4:X.X.X.X

     dtmf-relay h245-alphanumeric

     codec g711ulaw

     no vad

    !

    dial-peer voice 903 voip

     Description to Callmanager 4.X

      preference 4

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

     session target ipv4:X.X.X.X

     dtmf-relay h245-alphanumeric

     codec g711ulaw

     no vad

    !

    dial-peer voice 101 voip

     description inbound dial peer SIP

    session protocol sipv2

     incoming called-number .

     dtmf-relay rtp-nte digit-drop h245-alphanumeric

     codec g711ulaw

    !

    dial-peer voice 102 voip

     description inbound dial peer h323 inbound from CCM for OCS

     incoming called-number 1999.

     dtmf-relay h245-alphanumeric rtp-nte

     codec g711ulaw

    !

    !

    gateway

     timer receive-rtp 1200

    !

    !

    sip-ua

     timers connection aging 90

    !

    gatekeeper

     shutdown

    !

    !

    line con 0

    login authentication Router-console

     history size 25

     stopbits 1

    line aux 0

     stopbits 1

    line vty 0 4

     exec-timeout 0 0

     logging synchronous

     history size 25

    line vty 5 15

     exec-timeout 0 0

    !

    !

    end

     

    #

    Wednesday, October 29, 2008 8:50 PM
  • Hi Chris

     

    Thanks for your answer. It has been fixed now.

     

    Cheers,

    Bertrand

    Monday, November 10, 2008 1:50 AM
  • Hi Chris,

    You mention "There is a fix available through your support contacts at MSFT" do you have the KB article for this. I have tried contact Microsoft and they can not give me an information until I provide the KB article number.

    thanks in advance.
    Friday, January 9, 2009 6:41 AM
  • There is no KB article and like I said it is a MSPL script running on the front end servers. I am not able to hand out MSFT contact information but if you give me an email address I can pass you some information that will help you out.

    Cheers
    Chris


    Chris http://voipnorm.blogspot.com/
    Friday, January 9, 2009 7:30 PM