Answered by:
Call does not disconnect when the pstn user hangs up

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 ViaIP/2.0/TCP xxx.xxx.xxx.185:1763;branch=z9hG4bK97ff830
020:14:336 [VoIP ] Prot Content-Length:0
020:14:336 [VoIP ] ProtThursday, 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)
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
!
endWednesday, 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.shtmlThursday, 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.Friday, March 28, 2008 11:27 AM