locked
Call does not disconnect when the pstn user hangs up RRS feed

  • Question

  • The issue is when a call is placed out onto the PSTN from an OCS user.

    When the PSTN user hangs up OCS continues as showing being connected. The OCS user has to manually close the call.

     

    Is this expected behavior or is there a way to close the OCS call when the PSTN user hangs up?

     

    The mediation server is connecting to a dialogic 2000 gateway.

    The gateway correctly shows the End Reason of TDM: Normal but OCS doesn't seem to pick up on the fact.

    I am not sure if I need to configure something on the dialogic gateway to inform or kill the connection to the mediation server?

     

    Thanks for any hints.

     

    Regards

    Alistair

     

    More Info _ sip trace

    020:14:336 [VoIP      ] Prot     ---->BYE sip:+445555555555@xxx.xxx.xxx.xxx:5060;transport=tcp SIP/2.0
    020:14:336 [VoIP      ] Prot     FROM: <sip:+444444444444@xxxxeucc013.xxx.xxx;user=phone>;epid=D67235C224;tag=ffe8d1d3a4
    020:14:336 [VoIP      ] Prot     TO: <sip:+445555555555@xxx.xxx.xxx.xxx;user=phone>;tag=06FD324631353641006916A4
    020:14:336 [VoIP      ] Prot     CSEQ: 592 BYE
    020:14:336 [VoIP      ] Prot     CALL-ID: 30474e34-8d50-463c-bd99-be67c20ec320
    020:14:336 [VoIP      ] Prot     MAX-FORWARDS: 70
    020:14:336 [VoIP      ] Prot     VIA: SIP/2.0/TCP xxx.xxx.xxx.185:1763;branch=z9hG4bK97ff830
    020:14:336 [VoIP      ] Prot     CONTENT-LENGTH: 0
    020:14:336 [VoIP      ] Prot     USER-AGENT: RTCC/3.0.0.0 MediationServer
    020:14:336 [VoIP      ] Prot    
    020:14:336 [VoIP      ] Prot    
    020:14:336 [VoIP      ] Prot     <----SIP/2.0 481 Call Leg/Transaction Does Not Exist
    020:14:336 [VoIP      ] Prot     Call-ID:30474e34-8d50-463c-bd99-be67c20ec320
    020:14:336 [VoIP      ] Prot     CSeq:592 BYE
    020:14:336 [VoIP      ] Prot     From:<sip:+444444444444@xxxxeucc013.xxx.xxx;user=phone>;epid=D67235C224;tag=ffe8d1d3a4
    020:14:336 [VoIP      ] Prot     To:<sip:+445555555555@xxx.xxx.xxx.xxx;user=phone>;tag=06FD324631353641006916A4;tag=67CA324631353641006918E1
    020:14:336 [VoIP      ] Prot     ViaTongue TiedIP/2.0/TCP xxx.xxx.xxx.185:1763;branch=z9hG4bK97ff830
    020:14:336 [VoIP      ] Prot     Content-Length:0
    020:14:336 [VoIP      ] Prot  

    Thursday, December 6, 2007 2:46 PM

Answers

  • The issue is caused by me having two NICS in the server both on the same network (subnet).

    Using two nics on different networks or a single NIC\IP stops the issue occuring.

     

    More Detail

    "

    When OCS initiates a voice call out to the PSTN via a gateway it sends a SIP invite in the form

    CONTACT: <sip:Mediationservername.com:5060;transport=Tcp;maddr=192.168.10.1;ms-opaque=ba203bbfbffd3f5f>

    When a gateway sends a bye,it will attempt to send it to the IP address specified in the maddr in the Contact address at port 5060.

    The MS best practises is to use two NICs on a mediation server. One card faces the gateway; the second card faces the Communications Server 2007 server that acts as the Mediation Server’s internal next hop. The IP address that you select from the Communications Server listening IP address must match the address that is returned by a DNS query on the Mediation Server’s FQDN. (It is possible to configure both edges on a single adapter card, but not recommended)

    However if both NICs are on the same subnet the mediation server uses the NIC highest in the Binding Order. Typically this is the Communications Server listening IP and it will reject traffic from the gateway. (Gateway attempts to open a TCP socket to port 5060 at the IP address specified in the maddr in the Contact address, but the destination is responds with an RST/ACK, which rejects the socket open. Because of this gateway cannot send the BYE)

     

    Effectively when it comes to production the NICs should be on different networks. (The Mediation server <=> gateway should be a closed vlan or potentially a cross over cable)

    For now the issues have been resolved by configuring both edges on a single adapter card

    "

    Monday, January 14, 2008 10:51 AM

All replies

  • I have the same issue using an AudioCodes media gateway. It would really be great if there was a way to have it hang up automatically when the user on the remote end hangs up. If there is some way to make this work I would sure like to know.

    Friday, December 7, 2007 5:00 PM
  • I have logged an MS call as digging around a bit more the error code 

    <----SIP/2.0 481 Call Leg/Transaction Does Not Exist

    Call-ID:30474e34-8d50-463c-bd99-be67c20ec320

     

    Would seem to indicate that OCS is loosing track of the call which I can see was setup correctly.

     

    CSEQ: 591 INVITE

    CALL-ID: 30474e34-8d50-463c-bd99-be67c20ec320

    (I just hope the extra space isn't causing confusion)

    Friday, December 7, 2007 5:59 PM
  • Correction.

    OCS is operating correctly.

    The sequence is the PSTN user is closing the call.

    No BYE is being sent by the gateway to OCS to signal this.

    The OCS user then tries to close the call manually but it is the gateway responding <----SIP/2.0 481 Call Leg/Transaction Does Not Exist

     

    This would seem to indicate that the gateway is aware that the PSTN call has been closed.

    It is not sending a bye to the mdiation server but it is tearing down the call-id etc

    When the OCS user finally manually hangs up the mediation server is sending a bye to the gateway which is responsing with "Call Leg/Transaction Does Not" because it has already torn it down without telling OCS.

     

    I am talking to dialogic about this and will post a response.

     

    Wednesday, December 19, 2007 1:11 PM
  • The issue is caused by me having two NICS in the server both on the same network (subnet).

    Using two nics on different networks or a single NIC\IP stops the issue occuring.

     

    More Detail

    "

    When OCS initiates a voice call out to the PSTN via a gateway it sends a SIP invite in the form

    CONTACT: <sip:Mediationservername.com:5060;transport=Tcp;maddr=192.168.10.1;ms-opaque=ba203bbfbffd3f5f>

    When a gateway sends a bye,it will attempt to send it to the IP address specified in the maddr in the Contact address at port 5060.

    The MS best practises is to use two NICs on a mediation server. One card faces the gateway; the second card faces the Communications Server 2007 server that acts as the Mediation Server’s internal next hop. The IP address that you select from the Communications Server listening IP address must match the address that is returned by a DNS query on the Mediation Server’s FQDN. (It is possible to configure both edges on a single adapter card, but not recommended)

    However if both NICs are on the same subnet the mediation server uses the NIC highest in the Binding Order. Typically this is the Communications Server listening IP and it will reject traffic from the gateway. (Gateway attempts to open a TCP socket to port 5060 at the IP address specified in the maddr in the Contact address, but the destination is responds with an RST/ACK, which rejects the socket open. Because of this gateway cannot send the BYE)

     

    Effectively when it comes to production the NICs should be on different networks. (The Mediation server <=> gateway should be a closed vlan or potentially a cross over cable)

    For now the issues have been resolved by configuring both edges on a single adapter card

    "

    Monday, January 14, 2008 10:51 AM
  • I have the same problem. I have a 2800 series Cisco Router with Voice Card. Single ISDN PRI. Mediation Server. Mediation Server is on same subnet as OCS farm and Gateway is on subnet that handles the PSTN demarks (phone room which is across campus from the datacenter). So i know they are on different subnets but i have tested in both a dual nic (different subnets) and single nic on different subnets and nether config works.

     

    Some notes:

     

    I have used a Dialogic 2000 GW in same single NIC config and it does not do it.

     

    The problem looks like the Cicso is sending a CANCEL and not a BYE since the call is never picked up and connected. This would make sense in this scenerio.

     

    I plan to do packet captures on the dialogic and see if it is sending a BYE instead of a CANCEL.

     

    My question is, are there people using Cisco GW's and if so did you have to change any SIP settings on the router that were not default.

     

    With the Dialogic working just fine and the Cisco (using exact same network details) experiences this behaviour.

     

    We are mainly a Cisco shop and i have would like to stay standardized. The cisco actually seems to sound better too.

     

    Any Cisco Gateway users out there and if so what kind of config did you use to get it working? This is the only issue so far with the Gateway. Everything else is great.

     

    Rick Phillips

    University of Kentucky

     

     

    Thursday, February 21, 2008 3:00 PM
  • Microsoft won't support this scenario at the moment however we have it working in a lab & I know Microsoft are looking into it also.

     

    Have a look at. (This document isn't great but it is a start)

    http://www.cisco.com/en/US/solutions/ns340/ns414/ns728/networking_solutions_products_genericcontent0900aecd805bd0e4.html

    See Microsoft Office Communication Server 2007 version RTM to Cisco IOS Voice Gateway using SIP with E1 ISDN

     

    What we have is a 2811 router in the lab. It did not work until we upgraded the IOS to 12.4(11)T4

    We are actually using it as an IP to IP gateway talking to CCM 4.13.

     

    We have done quite a few tests and overall it seems to work well. We have only one slight glitch with

    Cisco phone diverts a call so the end result is two ocs users being connected after about 60 seconds the call is dropped. All the other call transfers, holds, conference etc seem to work well. However if you are not using CCM you won't come up against this.

     

    Hope this helps.

     

    Regards

    Alistair

     

    Thursday, February 21, 2008 5:14 PM
  •  

    Hi Guys,

     

    Can i check with you your integration design?

     

    pstn ------>router---------> CM 4

       \---e1--> Dialogic GW----sip---> Mediation

     

     

    Is your design like this? Is it possible for you to post your router configuration? I can't seems to get the connection working between the router and the Dialogic GW.

     

    Thanks.

     

    Regards,

    Lee WH

    Wednesday, March 26, 2008 3:23 AM
  • For our lab we had

    pstn => router 1 => CCM4.13 => router 2 - e1 -> Dialogic => Mediation

    For production I left it to the Voice Team

    On CCM. the gateway will be a standard MGCP type with the following changes

    Interface information

     

    PRI Protocol Type = PRI QSIG E1

    Protocol Side = Network, as the TMG will be set to terminal as default

    PCM type = A-law

     

    Key parts of router config _ this is an old version (We are trying to use the router as an IP to IP gateway _ ie no dialogic required with some success.)

     

     

    card type e1 1 1
    !
    no aaa new-model
    !
    resource policy
    !
    network-clock-participate slot 1
    network-clock-select 1 E1 1/0
    ip subnet-zero
    !
    ip cef
    !
    no ip domain lookup
    isdn switch-type primary-4ess
    isdn voice-call-failure 0
    isdn gateway-max-interworking
    !
    voice-card 0
     dspfarm
    !
    voice-card 1
     dspfarm
    !
    voice rtp send-recv
    !
    voice service voip
    !
    username all
    !
    controller E1 1/0
     pri-group timeslots 1-31 service mgcp
    !
    interface Serial1/0:15
     no ip address
     isdn switch-type primary-qsig
     isdn overlap-receiving
     isdn protocol-emulate network
     isdn incoming-voice voice
     isdn T310 120000
     isdn bind-l3 ccm-manager
     no cdp enable
    !
    control-plane
    !
    voice-port 1/0:15
     cptone C1
    !
    ccm-manager fallback-mgcp
    ccm-manager mgcp
    ccm-manager music-on-hold
    ccm-manager config server xxxxxxxx
    ccm-manager config
    ccm-manager download-tones
    !
    mgcp
    mgcp call-agent xxxxxxxxxxx 2427 service-type mgcp version 0.1
    mgcp dtmf-relay voip codec all mode out-of-band
    mgcp rtp unreachable timeout 1000 action notify
    mgcp modem passthrough voip mode nse
    mgcp package-capability rtp-package
    no mgcp package-capability res-package
    mgcp package-capability sst-package
    no mgcp package-capability fxr-package
    mgcp package-capability pre-package
    no mgcp timer receive-rtcp
    mgcp sdp simple
    mgcp rtp payload-type g726r16 static
    !
    mgcp profile default
    !
    dial-peer cor custom
    !
    dial-peer voice 9 pots
     destination-pattern 33..
     progress_ind alert enable 8
     progress_ind progress enable 8
     progress_ind connect enable 8
     direct-inward-dial
     forward-digits all
    !
    dial-peer voice 3300 voip
     destination-pattern 330[0-5]
     progress_ind setup enable 3
     progress_ind alert enable 8
     progress_ind progress enable 8
     progress_ind connect enable 8
     session target ipv4:xxxxxxxxxxxxxxxxxx
     incoming called-number .
     dtmf-relay h245-alphanumeric
     codec g711ulaw
     no vad
    !
    dial-peer voice 10 pots
     destination-pattern 330[5-9]
     port 1/0:15
     forward-digits all
     prefix +44xxxxxx
    !
    scheduler allocate 20000 1000
    ntp master
    !
    end

     

     

    Wednesday, March 26, 2008 1:28 PM
  • Hi Alistair,

     

    Thanks a lot.

    I will work on this and let you know the result.

     

    rgds,

    lee

    Wednesday, March 26, 2008 1:39 PM
  • Hi AlistairK,

     

    I have a mediation server in our lab with both Nics on the same subnet and it works fine. I think a key to it is to ensure that the Nic that connects to the OCS front end is registered in DNS and the other nic that is used for talking to the PSTN gateway is NOT regisitered in DNS. This can be done in the TCP/IP properties under the Nic configuration in Windows. Just unselect the register in DNS check box for the PSTN nic. I know its a little late but it may help anyway.

     

    Cheers

    Chris

     

    Wednesday, March 26, 2008 2:31 PM
  • In the scenario I had, problems would only occur under certain instances. Like you I set the NIC to not register in DNS.

    The issue was that OCS would use the NIC\IP highest in the binding order to connect to the dialogic gateway.

    When the PSTN user terminated the call the dialogic gateway would notify the IP address which had initated the connection.

    If this IP was not the gateway listening IP the mediation server would reject the connection.

     

     

    Wednesday, March 26, 2008 2:49 PM
  • Hi Alistair,

     

    May I know what cable are you using for connection from router 2 to dialogic? I am using a RJ45 straight cable.

     

    Rgds,

    Lee WH

    Thursday, March 27, 2008 1:21 AM
  • Ahh you will need a special cable.

    RJ45 cable but pin out for E1\T1 CSU/DSU Cross-Over Pinout

    http://www.cisco.com/en/US/products/hw/routers/ps233/products_tech_note09186a00800a3f09.shtml

     

    Thursday, March 27, 2008 9:02 AM
  • i have it working after changing the cable. it was the cable that causing the problem all this while. thanks a lot. Smile

     

    Friday, March 28, 2008 11:27 AM