DMG2000 - Outgoing Calls to Mobile Network are disconnected

rated by 0 users
This post has 2 Replies | 2 Followers

Not Ranked
Posts 3
Points 45

I have an issue with outgoing calls from Lync Server user to mobile network. 

Lync Server is connected through Direct SIP connection to a DMG2000 (2060). The Media Gateway connects to PSTN Mobile Network through an E1 interface card with ISDN protocol.

SCENARIO:

Lync user makes an outgoing call to a PSTN mobile user. The SETUP message is sent successfully to the PSTN Mobile Operator, and it responds with a CALL PROCEEDING message. If the PSTN Mobile Operator takes more than 2000 milliseconds to respond with an ALERTING message, the call fails. The DMG2000 starts a timer of 2000 milliseconds when it receives the CALL PROCEEDING message. When ALERTING message takes longer than 2 seconds, the DMG2000 disconnects the call, and sends a SIP CANCEL to Lync Server

Mobile Telephony Operators typically take longer to send the ALERTING message, since they have to locate the user. So this is a typical situation.

TRACE OF AN UNSUCCESSFUL CALL:

In this case, the ALERT message does not arrive before timer expires. The DMG2000 disconnects the call, and sends a SIP CANCEL to Lync Server (337:59.616 - 337:57.456 = 2160 milliseconds)

337:57.424 [teldrv-2  ] Prot     [  1] NLS->SETUP: 08 02 00 01 05 A1 04 03 80 90 A3 18 03 A9 83 81 6C 0C 41 80 37 36 38 33 36 30 37 31 34 36 70 0A A1 36 31 32 34 34 33 38 38 38 
337:57.424 [Gcc       ] Code     gccCallOriginate() Call 3c14fb0
337:57.424 [Gw        ] Code     (382f8d4) eGW_ST_ORIGINATE<-eGW_ST_ROUTE_METHOD -1
337:57.424 [Gcc       ] Code     (3c14fb0) gccCallGetInfo() |pri1|
337:57.456 [teldrv-2  ] Prot     [  1] NLS<-CALL_PROC: 08 02 80 01 02 18 03 A9 83 81 
337:57.456 [Tel-2     ] Event    l4_appl N_CALL_PROC_IN connid:246 cause[00:00] datalen:0
337:57.456 [Tel-2     ] Code     isdnLiAppOnProceeding(246,1)
337:57.456 [Tel-2     ] Code     ISDN Task(1) eISDN_MSG_IND_PROCEEDING
337:57.456 [Tel-2     ] Code     (3c14fb0) eISDN_MSG_IND_PROCEEDING in eSTATE_OUTBOUND_PENDING
337:57.456 [Tel-2     ] Code     isdnGccReportCallFuncAsyncCmplt: 1 0(3c14fb0)
337:57.456 [Gcc       ] Event    (3c14fb0) eGCC_EVENT_CALL_ASYNC_FUNCTION_TERMINATED [pri1] CallOriginate eGCC_ERROR_SUCCESS
337:57.456 [Tel-2     ] Code     _actSetCallProceeding
337:57.456 [Tel-2     ] Code     isdnGccChangeCallState: 3c14fb0 PROCEEDING
337:57.456 [Gcc       ] Event    (3c14fb0) eGCC_EVENT_CALL_STATE [pri1] = PROCEEDING
337:57.456 [Tel       ] Code     (3c14fb0) Connection has new timeout -1
337:57.456 [Tel-2     ] Code     _entryWaitOutboundProceedingState
337:57.456 [Tel       ] Code     (3c14fb0) Connection has new timeout 2000
337:57.456 [Tel-2     ] Code     (3c14fb0) eSTATE_OUTBOUND_PROCEEDING from eSTATE_OUTBOUND_PENDING
337:57.456 [Gw        ] Code     (382f8d4) eGW_EV_GCC_SUCCESS in eGW_ST_ORIGINATE.
337:57.456 [Gw        ] Code     (382f8d4) _actSetMediaUpdateCallIdTdm
337:57.456 [Gw        ] Code     (382f8d4) eGW_ST_PROCEEDING<-eGW_ST_ORIGINATE -1
337:57.456 [Gcc       ] Code     (3c14fb0) gccCallGetInfo() |pri1|
337:57.456 [Gw        ] Code     (382f8d4) eGW_EV_PROCEEDING in eGW_ST_PROCEEDING.
337:57.456 [Gw        ] Code     (382f8d4) _condInbVoipOutbTdmPotsOrCas=No
337:59.616 [Tel-2     ] Code     ISDN Task(1) eISDN_MSG_TIMEOUT
337:59.616 [Tel-2     ] Code     (3c14fb0) eISDN_MSG_TIMEOUT in eSTATE_OUTBOUND_PROCEEDING
337:59.616 [Tel-2     ] Code     _condIsTransferReroute: NO
337:59.616 [Tel-2     ] Code     (3c14fb0) remaining in eSTATE_OUTBOUND_PROCEEDING
338:00.080 [VoIP      ] Code     [TCP_UDP_CONVERGENCE_LAYER 0x75:0] k://scimitar//pimg//sw//src//pbn//trl//tucl_1.5//hi_ptui.c:1251 HiUiHitDatInd(pst, suId(0), suConId(53834), mBuf(0x4595384))
338:00.080 [VoIP      ] Code     [SIP_LAYER 0x99:0] k://scimitar//pimg//sw//src//pbn//trl//so//so_li.c:982 SoLiHitDatInd(pst, suId(0), suConnId(53834), mBuf(0x4595384)
338:00.080 [VoIP      ] Code     [SIP_LAYER 0x99:0] k://scimitar//pimg//sw//src//pbn//trl//so//so_tmr.c:326 TIMER: Evnt 66 Action 3 Value 900 CB 0x493e3a4
338:00.080 [VoIP      ] Prot     
338:00.080 [VoIP      ] Prot     ---->CANCEL sip:612443888@172.17.222.140;user=phone SIP/2.0
338:00.080 [VoIP      ] Prot     FROM: "User01"<sip:+34972977146;ext=3607146@wkcfias.fi.es;user=phone>;tag=af5cb7f845;epid=B2FBDCC4A7
338:00.080 [VoIP      ] Prot     TO: <sip:612443888@172.17.222.140;user=phone>
338:00.080 [VoIP      ] Prot     CSEQ: 59662 CANCEL
338:00.080 [VoIP      ] Prot     CALL-ID: 3dd5fd21-5902-4e51-a0db-b979eb9350d2
338:00.080 [VoIP      ] Prot     MAX-FORWARDS: 70
338:00.080 [VoIP      ] Prot     VIA: SIP/2.0/TCP 172.18.255.211:64799;branch=z9hG4bK51b75539
338:00.080 [VoIP      ] Prot     CONTACT: <sip:WKCFIAS.fi.es:5068;transport=Tcp;maddr=172.18.255.211>
338:00.080 [VoIP      ] Prot     CONTENT-LENGTH: 0
338:00.080 [VoIP      ] Prot     USER-AGENT: RTCC/4.0.0.0 MediationServer

 

TRACE OF A SUCCESSFUL CALL

In this case, the ALERT message arrives before 2000 milliseconds after receiving CALL PROCEEDING message.  (337:24.096 - 337:22.720 = 1376 milliseconds)

337:22.688 [teldrv-2  ] Prot     [  1] NLS->SETUP: 08 02 00 01 05 A1 04 03 80 90 A3 18 03 A9 83 81 6C 0C 41 80 37 36 38 33 36 30 37 31 34 36 70 0A A1 36 31 32 34 34 33 38 38 38 
337:22.688 [Gcc       ] Code     gccCallOriginate() Call 3c1447c
337:22.688 [Gw        ] Code     (382f8d4) eGW_ST_ORIGINATE<-eGW_ST_ROUTE_METHOD -1
337:22.688 [Gcc       ] Code     (3c1447c) gccCallGetInfo() |pri1|
337:22.720 [teldrv-2  ] Prot     [  1] NLS<-CALL_PROC: 08 02 80 01 02 18 03 A9 83 81 
337:22.720 [Tel-2     ] Event    l4_appl N_CALL_PROC_IN connid:245 cause[00:00] datalen:0
337:22.720 [Tel-2     ] Code     isdnLiAppOnProceeding(245,1)
337:22.720 [Tel-2     ] Code     ISDN Task(1) eISDN_MSG_IND_PROCEEDING
337:22.720 [Tel-2     ] Code     (3c1447c) eISDN_MSG_IND_PROCEEDING in eSTATE_OUTBOUND_PENDING
337:22.720 [Tel-2     ] Code     isdnGccReportCallFuncAsyncCmplt: 1 0(3c1447c)
337:22.720 [Gcc       ] Event    (3c1447c) eGCC_EVENT_CALL_ASYNC_FUNCTION_TERMINATED [pri1] CallOriginate eGCC_ERROR_SUCCESS
337:22.720 [Tel-2     ] Code     _actSetCallProceeding
337:22.720 [Tel-2     ] Code     isdnGccChangeCallState: 3c1447c PROCEEDING
337:22.720 [Gcc       ] Event    (3c1447c) eGCC_EVENT_CALL_STATE [pri1] = PROCEEDING
337:22.720 [Tel       ] Code     (3c1447c) Connection has new timeout -1
337:22.720 [Tel-2     ] Code     _entryWaitOutboundProceedingState
337:22.720 [Tel       ] Code     (3c1447c) Connection has new timeout 2000
337:22.720 [Tel-2     ] Code     (3c1447c) eSTATE_OUTBOUND_PROCEEDING from eSTATE_OUTBOUND_PENDING
337:22.720 [Gw        ] Code     (382f8d4) eGW_EV_GCC_SUCCESS in eGW_ST_ORIGINATE.
337:22.720 [Gw        ] Code     (382f8d4) _actSetMediaUpdateCallIdTdm
337:22.720 [Gw        ] Code     (382f8d4) eGW_ST_PROCEEDING<-eGW_ST_ORIGINATE -1
337:22.720 [Gcc       ] Code     (3c1447c) gccCallGetInfo() |pri1|
337:22.720 [Gw        ] Code     (382f8d4) eGW_EV_PROCEEDING in eGW_ST_PROCEEDING.
337:22.720 [Gw        ] Code     (382f8d4) _condInbVoipOutbTdmPotsOrCas=No
337:24.096 [teldrv-2  ] Prot     [  1] NLS<-ALERT: 08 02 80 01 01 1E 02 84 88 27 01 E0 

 

I am sure that if I could set this timer to a value greater than 2000 milliseconds, the calls would not drop. Is there any possibility to increase this timer to a value greater than 2000 milliseconds?

This timer is equivalent to T310 timer.

I will appreciate any help

 

Top 10 Contributor
Male
Posts 2,265
Points 30,972
Dialogic Employee

That Cancel is actually sent by Lync to the DMG, ie its Lync who is clearing the call, the DMG is not going to clear the call :

337:59.616 [Tel-2     ] Code     (3c14fb0) remaining in eSTATE_OUTBOUND_PROCEEDING

Then approx 400ms later Lync sends a cancel:

338:00.080 [VoIP      ] Prot     ---->CANCEL sip:612443888@172.17.222.140;user=phone SIP/2.0

Have a look and see if Lync has a timer for receiving Alerting messages and see if you can increase it.

The other option is to force early media on in the DMG, then the DMG will send a 183 progress message to Lync as soon as it gets the Call Proceeding from ISDN so I wouldn't think that Lync will drop the call then.

 To enable early media on the DMG go to VoIP/Media and set "RFC3960 Early Media support" to Always".

Early media means that the voice channel between the DMG and Lync is connected as soon as the DMG receives a call proceeding.

Note that this will change the user experience as now the Lync users will hear the real network tones and messages and not Lync's artificial ring tone. In most cases this is better as Lync users will be able to hear network announcements such as 'that number does not exist' etc but in this case with the delayed ringback they will hear silence until the actual ringback is sent from the mobile operator. This is the same as they would hear when making the same call from a pstn phone of course.

  • | Post Points: 20
Not Ranked
Posts 3
Points 45

Thanks for the answer.

You are right. DMG sends a disconnect after receiving SIP CANCEL.

We think that the source of the problem could be in the firewall port configuration between Front End Servers and Edge Servers (ICE protocol and MRAS)

  • | Post Points: 5
Page 1 of 1 (3 items) | RSS