Hi Ian! I have done that and on the SIP side the negotiation is looking good: From Mirial: Sip Invite (with SDP) to SIP side looks OK Sip Trying, Sip Ringing OK Sip OK (with SDP) from SIP looks ok, with audio and media Sip Ack to SIP should confirm the call setup. Since it is the gnugk that is disconnecting the call (sending a disengageRequest to Mirial) it is hard to send this as a error report to Mirial. L I can see the drop reason and google’d on it: DisengageReason ::= CHOICE { forcedDrop NULL, -- gatekeeper is forcing the drop normalDrop NULL, -- associated with normal drop undefinedReason NULL, ... } Not sure if it is possible to squeeze any more information from the gnugk (-tttttttt right now) but even thou I get lots of: 2011/11/29 16:29:04.714 6 yasocket.cxx(845) ProxyH(4) waiting... 2011/11/29 16:29:05.711 6 yasocket.cxx(845) ProxyH(1) waiting... 2011/11/29 16:29:05.711 6 yasocket.cxx(845) ProxyH(0) waiting... 2011/11/29 16:29:05.712 6 yasocket.cxx(845) ProxyH(3) waiting... 2011/11/29 16:29:05.712 6 yasocket.cxx(845) ProxyH(2) waiting... 2011/11/29 16:29:05.714 6 yasocket.cxx(845) ProxyRTP(0) waiting... 2011/11/29 16:29:05.714 6 yasocket.cxx(845) GkStatus waiting... I get nothing more about that disengageRequest with forcedDrop made by gatekeeper. L I appreciate a comments and suggestions. J Best Regards, Mikael Från: Ian Blenke [mailto:ian@xxxxxxxxxx] On Tue, Nov 29, 2011 at 3:57 PM, Mikael Grehn <mikael.grehn@xxxxxxxx> wrote: Hi Ian and thank you! Could be a compatibility issue BUT calls from one primary gatekeeper through Mirial and to SIP side is working perfectly. It is when I add a second (neighborhood) gatekeeper on a separate IP for an second customer but need to use only one Mirial H3232SIP gateway that this second customer runs into problems with disconnected calls after approx. 20 seconds. So I feel that there is something else with this 2 gnugk setup and neighborhood-thing that is causing this! Am I correct and what can cause problems with 2 gnugk’s that I want Mirial to register to? Thanks for your help! If you do not have vendor support with Mirial, your next step is really to fire up wireshark and take a look at the signaling to see what isn't being fully negotiated correctly that is causing the 20 second timeout. Without a packet capture to look at (which really isn't a good idea to post on a mailing list), it's really mostly guessing. -- |
------------------------------------------------------------------------------ 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@xxxxxxxxxxxxxxxxxxxxx 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/
