We have Mirial HSGWs in our infrastructure. We only use them in a
SIP->H.323 capacity, as we ran into interoperability issues when we tried
H.323->SIP calling through them.

I'll agree with Jan, it is very likely that there is a SIP SDP <> H.245
interworking issue on the HSGW that isn't completing successfully.

Mirial support is pretty good about fixing interoperability issues,
however: get a problem report from the HSGW and mail it in with your call
scenario, I'm sure they'll spot the underlying problem.

- Ian

On Tue, Nov 29, 2011 at 2:55 PM, Jan Willamowius <j...@willamowius.de> wrote:

> Again, audio and video is no indication that the call has connected
> (and would be past most of the message timeouts). You have to check
> for the Connect message and check if the H.245 connection negotiated
> properly.
>
> Regards,
> Jan
>
>
> Mikael Grehn wrote:
> > Hi Jan and thanks for the rapid response.
> >
> > The calls are perfectly connected and they run with audio and video for
> about 25 seconds (perhaps 20 seconds after fully being connected). Then the
> primary gatekeeper is sending this disengageRequest to Mirial and Mirial
> disconnects both sides. Primary gatekeeper has been "quiet" for about 20
> seconds before this so something is absolutely happening!
> >
> > If I make a call to the other customer (directly to primary Gk) the call
> is not disconnected at all and are working perfectly. :)
> >
> > Any ideas what can trigger this?
> >
> > Thanks for you kind help!
> >
> > Best Regards,
> > Mikael
> >
> >
> > -----Ursprungligt meddelande-----
> > Från: Jan Willamowius [mailto:j...@willamowius.de]
> > Skickat: den 29 november 2011 20:21
> > Till: openh323gk-users@lists.sourceforge.net
> > Ämne: Re: [Openh323gk-users] Question about disengageRequest
> >
> > Hi Mikael,
> >
> > are your calls being terminated before or after they connect ? (Hearing
> voice may just mean that the call was using FastStart.)
> >
> > If GnuGk actively terminates a call it usually detected ran into a
> timeout (it tries to detect stale calls). When you have multiple
> gatekeepers involved, make sure each gatekeeper that handles the call sees
> all messages for that call.
> >
> > Regards,
> > Jan
> >
> >
> > Mikael Grehn wrote:
> > > Hi!
> > >
> > > I have a question about why a primary gatekeeper(out of 2 gatekeepers)
> > > is disconnecting calls after 25 seconds that first reaches the
> > > alternative gatekeeper on another machine. The H323 endpoint that is
> > > receiving the call is a Mirial gateway. :)
> > >
> > > We have two customers that use incoming H323 and SIP for their service.
> > >
> > > For the H323 we are using a H323 Gnugk for each customer (on two
> different IP's) that I have tried to setup as primary and alternative
> gatekeeper.
> > > To translate from H323 to SIP (which is the protocol mainly supported
> > > by our service) we have a Mirial H323 2 SIP in between. The H323 side
> > > of Mirial is registered in the primary gatekeeper at customer 1. We
> > > cant register it in the alternative as well. :)
> > >
> > >
> > > Customer 1: GnuGk(primary) IP1 <--registered Mirial IP3
> > >                              |reg
> > > Customer 2: GnuGk(alternative) IP2
> > >
> > >
> > > Calls from H323 clients to the first (primary) customer is working
> perfectly.
> > > Calls from H323 to the second customer (with the alternative
> gatekeeper gets the call to work for about 25 seconds. After this the
> primary gatekeepers decides to send disengageRequest directly to Mirial
> gateway, that is later disconnecting the calls.
> > >
> > > This is the log from the primary gatekeeper (207.183.111.122) when it
> is disconnecting a working call:
> > >
> > > (. . . about 20 seconds with no logs since the call was setup OK . .
> > > .) disengageRequest {
> > >     requestSeqNum = 104
> > >     endpointIdentifier =  9 characters {
> > >       0031 0034 0030 0038 005f 0065 006e 0064   1408_end
> > >       0070                                      p
> > >     }
> > >     conferenceID =  16 octets {
> > >       02 35 81 01 a4 43 d0 10  36 b3 e2 73 30 a9 2e cf
> .5...C..6..s0...
> > >     }
> > >     callReferenceValue = 51145
> > >     disengageReason = forcedDrop <<null>>
> > >     callIdentifier = {
> > >       guid =  16 octets {
> > >         02 35 81 01 a4 43 d0 10  36 b2 e2 73 30 a9 2e cf
> .5...C..6..s0...
> > >       }
> > >     }
> > >     gatekeeperIdentifier =  6 characters {
> > >      0047 0047 006e 0075 0047 006b             GGnuGk
> > >     }
> > >     answeredCall = false
> > >   }
> > > 2011/11/29 12:55:55.689 2             RasTbl.cxx(2642)  Gk
>  Disconnect Call No. 26
> > > 2011/11/29 12:55:55.689 2             RasTbl.cxx(4076)  CDR     ignore
> not connected call
> > > 2011/11/29 12:55:55.689 2             gkacct.cxx(955)   GKACCT
>  Successfully logged event 2 for call no. 26
> > > 2011/11/29 12:55:55.690 2             RasSrv.cxx(173)   RAS     Read
> from 207.183.111.224:1719
> > > 2011/11/29 12:55:55.690 3             RasSrv.cxx(223)   RAS
> > > disengageConfirm {
> > >     requestSeqNum = 104
> > >     usageInformation = {
> > >       nonStandardUsageFields = 0 entries {
> > >       }
> > >       alertingTime = 1322592922
> > >       connectTime = 1322592926
> > >     }
> > >   }
> > > 2011/11/29 12:55:55.690 1             RasSrv.cxx(355)   RAS     DCF
> Received from 207.183.111.224:1719
> > > 2011/11/29 12:55:56.689 3             RasTbl.cxx(2130)  Gk      Delete
> Call No. 26
> > > 2011/11/29 12:55:57.278 2             RasSrv.cxx(173)   RAS     Read
> from 207.183.111.224:1719
> > > 2011/11/29 12:55:57.278 3             RasSrv.cxx(223)   RAS
> > > disengageRequest {
> > >     requestSeqNum = 60528
> > >     endpointIdentifier =  9 characters {
> > >       0031 0034 0030 0038 005f 0065 006e 0064   1408_end
> > >       0070                                      p
> > >     }
> > >     conferenceID =  16 octets {
> > >       02 35 81 01 a4 43 d0 10  36 b3 e2 73 30 a9 2e cf
> .5...C..6..s0...
> > >     }
> > >     callReferenceValue = 18377
> > >     disengageReason = normalDrop <<null>>
> > >     callIdentifier = {
> > >       guid =  16 octets {
> > >         02 35 81 01 a4 43 d0 10  36 b2 e2 73 30 a9 2e cf
> .5...C..6..s0...
> > >       }
> > >     }
> > >     gatekeeperIdentifier =  6 characters {
> > >       0047 0047 006e 0075 0047 006b             GGnuGk
> > >     }
> > >     answeredCall = true
> > >     usageInformation = {
> > >       nonStandardUsageFields = 0 entries {
> > >       }
> > >       alertingTime = 1322592922
> > >       connectTime = 1322592926
> > >       endTime = 1322592952
> > >     }
> > >     terminationCause = releaseCompleteReason gatekeeperResources
> <<null>>
> > >   }
> > > 2011/11/29 12:55:57.279 1             RasSrv.cxx(355)   RAS     DRQ
> Received from 207.183.111.224:1719
> > > 2011/11/29 12:55:57.279 2             RasSrv.cxx(395)
> DCF|207.183.111.224|1408_endp|18377|normalDrop|02-35-81-01-a4-43-d0-10-36-b2-e2-73-30-a9-2e-cf;
> > > 2011/11/29 12:55:57.279 3             RasSrv.cxx(235)   RAS     Send
> to 207.183.111.224:1719
> > > disengageConfirm {
> > >     requestSeqNum = 60528
> > >   }
> > >
> > > Any ideas why it does this and how I can configure it away?
> > > I am adding the gnugk.ini file from primary gatekeeper. It is very
> > > similar on the alternative one. :)
> > >
> > > Primary Gk: 207.183.111.222
> > > Alternativ Gk: 207.183.111.223
> > > Mirial h323 2 SIP gw: 207.183.111.224
> > >
> > > [Gatekeeper::Main]
> > > FortyTwo=42
> > > Name=GGnuGk
> > > TimeToLive=600
> > > StatusTraceLevel=2
> > > AlternateGKs=207.183.111.223:1719:false:120:CGnuGk
> > > SendTo=207.183.111.223:1719
> > > SkipForwards=207.183.111.223
> > > CompareAliasCase=0
> > > CompareAliasType=0
> > > ExternalIP=207.183.111.222
> > > [GkStatus::Auth]
> > > rule=allow
> > > 127.0.0.1=allow
> > > default=allow
> > > Shutdown=allow
> > >
> > > [RoutedMode]
> > > GKRouted=1
> > > H245Routed=0
> > > CallSignalPort=1720
> > > AcceptUnregisteredCalls=1
> > > DropCallsByReleaseComplete=1
> > > SupportNATedEndpoints=1
> > >
> > > [Proxy]
> > > Enable=0
> > > ProxyForNAT=1
> > > ProxyForSameNAT=0
> > >
> > > [RoutingPolicy]
> > > default=explicit,internal,parent,neighbor,catchall,vqueue
> > >
> > > [RasSrv::RewriteAlias]
> > > customerdomain.com=0099999999
> > >
> > > [Routing::CatchAll]
> > > CatchAllAlias=PSEGateway
> > >
> > > [EP::PSEGateway]
> > > Capacity=30
> > > AddNumbers=0099999999
> > > AdditionalDestinationAlias=0099999999
> > >
> > > I have tried to change the real IP's into fictional ones, might have
> missed some!
> > > Any help is very appreciated! :)
> > >
> > > Best Regards,
> > > Mikael
>
> --
> Jan Willamowius, j...@willamowius.de, http://www.gnugk.org/
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________________
>
> Posting: mailto:Openh323gk-users@lists.sourceforge.net
> Archive:
> http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
> Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
> Homepage: http://www.gnugk.org/
>



-- 
- Ian Blenke <i...@blenke.com> http://ian.blenke.com
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________________

Posting: mailto:Openh323gk-users@lists.sourceforge.net
Archive: 
http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/

Reply via email to