MGCP-stack

[Tom Uijldert]

Hi,

Quick question wrt. the MGCP-stack (MGCP-RA 1.0.1.GA):

- Will the stack try to send a command/transaction once or does it re-send
on timeout?

Thanks in advance,
Tom Uijldert.

[Sachin Parnami]

AFAIK
It sends it again on Time-Out

--
Regards,
Sachin Parnami

[Amit Bhayani]

It does resend. There is timer as 

[Amit Bhayani]

Sorry pressed send in mid.

As per RFC 3435 the re-transmission timers should be calculated as per TCP way. So you will say re-transmission happening depending on load and network congestion.

[Tom Uijldert]

Thanks for the swift reply, had trouble locating it in the code.

---

From: mobicent...@googlegroups.com [mailto:mobicent...@googlegroups.com] On Behalf Of Amit Bhayani
Sent: dinsdag 13 oktober 2009 16:54
To: mobicent...@googlegroups.com
Subject: [mobicents-public] Re: MGCP-stack

[Uijltje]

Hi,
The actual cause behind this question:
When there is no reply on a CRCX command (due to network problems),
the TRANSACTION_TIMEOUT is -maybe- fired, but the event is definitely
not delivered to my sbb.
Anyone an idea as to why?

The sbb is attached to the connection activity.
Is it fired on some other activity?

TIA,
Tom.

On 14 okt, 09:04, "Tom Uijldert" <tom.uijld...@gmail.com> wrote:
> Thanks for the swift reply, had trouble locating it in the code.
>
>   _____  
>

> From: mobicent...@googlegroups.com
> [mailto:mobicent...@googlegroups.com] On Behalf Of Amit Bhayani
> Sent: dinsdag 13 oktober 2009 16:54
> To: mobicent...@googlegroups.com
> Subject: [mobicents-public] Re: MGCP-stack
>
> Sorry pressed send in mid.
>
> As per RFC 3435 the re-transmission timers should be calculated as per TCP
> way. So you will say re-transmission happening depending on load and network
> congestion.
>

> On Tue, Oct 13, 2009 at 7:51 AM, Amit Bhayani <amit.bhay...@gmail.com>

> wrote:
>
> It does resend. There is timer as  
>

> On Tue, Oct 13, 2009 at 7:33 AM, Sachin Parnami <sachin.mob...@gmail.com>

> wrote:
>
> AFAIK
> It sends it again on Time-Out
>

> On Tue, Oct 13, 2009 at 7:59 PM, Tom Uijldert <tom.uijld...@gmail.com>

[Amit Bhayani]

Yes looks like its not firing the net.java.slee.resource.mgcp.TRANSACTION_TIMEOUT event

http://code.google.com/p/mobicents/issues/detail?id=1022

[Amit Bhayani]

This issue is for migrated MGCP 2.x.y RA
This works in MGCP 1.x.y RA.

In 1.x.y,make sure that your SBB is listening for

        <event event-direction="Receive" initial-event="False">
            <event-name>TxTimeout</event-name>
            <event-type-ref>
                <event-type-name>net.java.slee.resource.mgcp.TRANSACTION_TIMEOUT</event-type-name>
                <event-type-vendor>net.java</event-type-vendor>
                <event-type-version>1.0</event-type-version>
            </event-type-ref>
        </event>

[Tom Uijldert]

Hmmm, this happens in 1.0.1.GA and my Sbb listens for exactly _that_ event.

Possibly a diff between 1.0.1 and 1.0.3?

---

From: mobicent...@googlegroups.com [mailto:mobicent...@googlegroups.com] On Behalf Of Amit Bhayani

Sent: dinsdag 27 oktober 2009 6:25

[Amit Bhayani]

Possible for you to test it out from trunk or 1.0.3 (both are same) to confirm?

[Tom Uijldert]

Sorry, I stand corrected.

Made a test and it _does_ generate the timeouts.

 

So what I'm left with is something that looks like a network-problem but probably isn't.

My sbb creates and sends the command but no timeout (nor response) is received.

 

So something goes wrong or is lost between giving the 'sendMgcpEvents()' command by the sbb and actually sending it over the socket (which starts the timer).

 

Could it be that the ThreadPoolExecutor has a discard-policy when saturated or exceptions are hidden?

 

TIA,

Tom.

 

---

From: mobicent...@googlegroups.com [mailto:mobicent...@googlegroups.com] On Behalf Of Amit Bhayani

Sent: dinsdag 27 oktober 2009 9:28

[Amit Bhayani]

If there is any error (may be RejectedExecutionException if you have set the executorTableSize to 1 in mgcp-stack.properties and load is very high, but I really suspect this could be the case) it should propagate all the way to SBB.

A simple wire-shark trace can show you if the Request is going to network or not.

You should see the TRANSACTION_TIMEOUT even if the Request goes on wire but there is no response.

Please also enable the DEBUG for org.mobicents.mgcp.stack and attach

[Tom Uijldert]

Hi Amit,

 

Found the cause in a roundabout way, it's the old SLEE-problem: event handling is not serialized in an Sbb over multiple activities and RA's cannot use transactions.

Hence, a response could be handled in parallel with the request, which would have the effect as if losing events. :(

 

Can hardly wait for Mobicents 2.0 :)

 

Anyway, thanks for your suggestions and patience.

---

From: mobicent...@googlegroups.com [mailto:mobicent...@googlegroups.com] On Behalf Of Amit Bhayani

Sent: woensdag 28 oktober 2009 2:57