Inbound calls to SM fail...

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • shaff2
    Member
    • Jun 2014
    • 4

    Inbound calls to SM fail...

    Hi,

    I installed Session Manager (SM 6.3 SP 8) for testing before it is deployed in production to replace our SES.

    I've been able to provision and register SIP endpoints to the SM and make calls between these SIP endpoints.

    I've setup a SIP trunk to our CM and wanted to test inbound calls from the CM to the SM. One extension is configured on the CM to be be routed across the SIP trunk to the SM.

    When I make an inbound call to this extension, a SIP Invite is send from the CM to the SM (verified from traceSM on SM). However, the SM ultimately responds with "404 Not Found (originating user not found)" to CM, despite the SIP extension being called to is SIP registered to the SM when the inbound call is placed.

    Furthermore, if I perform a Call Routing test from SMGR using the Called Party URI, Calling Party URI, Calling Party Address for the failed call obtained extracted from traceSM on the SM and use the appropriate Called Session Manager Instance, Session Manager Listen Port, and Transport Protocol, the result of the executed Call Routing Test indicates the call would be forwarded to the enduser, i.e., "Proxying the request to endpoint 89584..." which is what I want to happen for the failed call.

    I haven't been able to figure out why the SM returns the "404 Not Found (originating user not found)". I've tried to pare down the routing configuration on the SM to what's minimally necessary to make the work. Note, at this point CM should just be viewed as the other end of a SIP trunk and not an evolution or feature server.

    How can I make the SM not care about the originating user of an inbound call from a SIP trunk to the SM?

    Any advice would be greatly appreciated. I can supply any relevant information as requested.

    Thanks,
    -Scott
    Last edited by shaff2; 06-27-2014, 10:42 AM.
  • mlombardi1
    Legend
    • Sep 2010
    • 533

    #2
    Make sure IMS is disabled on the SIP signaling group used by the CM SIP trunk to SM. Enabling IMS triggers CM to act as a feature server for that trunk and will only break things.

    Despite the endpoint being registered to SM, CM still needs a SIP station object, off-PBX entry, and AAR routing for that extension to direct it to the SIP trunk to SM.
    Meridian IT - Senior Engineer

    Comment

    • shaff2
      Member
      • Jun 2014
      • 4

      #3
      Hi,

      Thanks for the reply. IMS was always set to disabled on the CM SIP trunk and a CM SIP station object and AAR routing were setup on the CM. The inbound call does get redirected to the SM but SM ends up dropping the call after performing its route processing. The error, "originating user not found" is returned back to CM (I included traceSM output for this in my original post).

      I really just want SM to view the link from CM as a SIP trunk (not even a evolution or feature server at this point) and route calls coming from it destined to SIP endpoints registered to SM without questioning the "originating user'.

      Thanks,
      -Scott

      Comment

      • mlombardi1
        Legend
        • Sep 2010
        • 533

        #4
        In the SM user profile, is CM selected as both the origination and termination application sequence?
        Meridian IT - Senior Engineer

        Comment

        • shaff2
          Member
          • Jun 2014
          • 4

          #5
          (None) is selected for both origination and termination application sequence for the user profile, the reason being is that I configured the CM as a SIP entity of "SIP trunk" because for the initial phase, I wanted it to be treated as such. I thought this would be a simpler setup and later I would migrate to a CM as Evolution Server configuration.

          If I wanted the CM to be used as Evolution Server (with H.323 phones registering it to), I'm guessing I would have to configure it as a SIP Entity of "CM" and then it would be applicable to configure the CM for origination and terminate sequences for the user profile. Do you know if setting up the CM as an Evolution Server requires setting up the SMGR to sync up with the CM via ssh port 5022, or is that optional only if you want to manage CM via SMGR's web GUI?

          When SM uses origination and termination application sequence, this is done via SIP between SM <--> CM, is that correct?

          Sorry for all the questions, I just haven't found any good documentation that outlines migrating from CM 5.x and SES toward SMGR and SM and CM 6.x. Most documents I've come across seem to deal with greenfield installs.

          Thanks,
          -Scott

          Comment

          • mlombardi1
            Legend
            • Sep 2010
            • 533

            #6
            Yeah, the documentation is very rough. SIP in the Avaya world requires SM and CM to constantly talk to one another. The systems are very much intertwined.

            Add CM as a SIP entity of type CM. Then add CM as an inventory element in SMGR so the translations sets will sync. I usually make a separate login in CM for SMGR to utilize for this purpose. 5022 or 5023 is fine.

            Create a CM application sequence and assign it to the user profile. Test and report back. Make sure the SIP extension in CM is in the off-PBX table as an OPS (off premise station) object.
            Meridian IT - Senior Engineer

            Comment

            • shaff2
              Member
              • Jun 2014
              • 4

              #7
              I added CM as a SIP entity of type CM and added CM as an inventory element in SMGR and synched them up.

              I created a CM application sequence and assigned it to the user profile in question. I also had to configure the CM Endpoint Profile as well and it was mostly pre-populated as a result of adding CM as an inventory element and synching it up to SMGR.

              The SIP extension was already configured in CM's off-PBX table as an OPS object.

              After waiting for all changes to propagate, the call still fails on the SM with the same error message, "404 Not Found (originating user not found)".

              Comment

              Loading