1S. WEYL – 31/01/2011

Basic Call Flows cases Basic Call Flows cases and and

analogic IMSloader subscribersanalogic IMSloader subscribers

AGW BelgacomAGW Belgacom

Synchronous Call establishment between two analogic subscribers supported by IMSloader + asterisk : Option has been found and activated in order to support end to end

synchronisation from SIP point of view between calling and called subscriber.

On calling side: Reception of 183 SIP Message corresponds to unhook opération.

From this point, the calling IMSLoader client receives an uninterrupted RTP flows (including background noise and ringing/dialing tones etc…).

180 SIP Message corresponds to the ringing indication received from the called side,

200 SIP Message corresponds to the detection of the unhook operation on called side (detection of end of ringing analogical information)

Ack SIP message closes from a SIP point of view the call establishment phase.

On the called subscriber side, end to end call establishment is detected from SIP point of view

Synchronous Call Release between two analogic subscribers supported by IMSloader + asterisk : On side of the first party which goes on hook: SIP BYE initiated by the

IMSloader corresponds to the on hook operation and directly leads to the call release (but only between the Client which goes on hook and the AGW of the other party)

On the other party side: End to end synchronisation is supported and based on the detection by asterisk/analogical Board of the hook tone

NB_1 please note that the client which goes on hook the first can be the calling or the called subscriber. In the next slide, the called subscriber goes on hook the first.

NB_2: even if some indications are delivered both by SIP and RTP (e.g. dial/ringing/on hook tone), only the indications delivered by SIP in these cases are processed by IMSloader clients

2

Analogic calling and called subscribers supported by Analogic calling and called subscribers supported by IMSLoader 1/2IMSLoader 1/2

AGWSUB1 Asterisk1

1a - SIP INVITE

3

Analogic calling and called subscribers supported by Analogic calling and called subscribers supported by IMSLoader 2/2IMSLoader 2/2

AGW Asterisk2 SUB2

Analogic SUB1 supported by IMSLoader Analogic SUB2 supported by IMSLoaderIMS Core

1b - SIP 183

1e - SIP ACK

2a - SIP INVITE

2c - SIP 200 ok

2d - SIP ACK

2b - SIP 180 ringing SUB2 unhooks(accepts the call

initiated by SUB1l)

Line unhooked

Dial tone

DTMF numbering

Ringing tone/Background noise

Background noise White noise

RT

P F

low

s

for

rec

eiv

ed

to

ne

s a

nd

w

hit

e n

ois

e

Speech RTP from SUB1 to SUB2

Speech RTP from SUB2 to SUB1

3a - SIP BYE

4a - SIP BYE 3b - SIP 200ok

4b - SIP 200ok

SUB2 on hooks the first

On Hook tone

SU

B1

unho

oks

and

dial

s S

UB

2#

1c - SIP 180

Line unhooked

1d - SIP 200

Syn

chro

nous

End

to e

nd c

all

esta

blis

hmen

tS

ynch

rono

us

call

rele

ase

Spe

ech

exch

ange

At the time being our reflexion concerning sending and reception/control of speech RTP flow can be summurized as follow: New « RTP flow » mechanism supported by IMSLoader (that allows to

control if received packets matched for each octets and for a whole content of a real speech flow that has be sent) seems not to be adapted to the transmission of a speech flow including an analogical path

IMSloader « Basic RTP » mechanism will apply to our need for the Belgacom project.

We will have to test in the next days following options for E2E spech sending/reception 1rst choice: sending of a full controled RTP motif in order to be

able, on the reception side, to distinguish this motif from noise/tone/DTMF

2cd choice: detection of complete noise sequences and so also detect speech sequences (see possible criteria in the NB below).

Other option: to be studied if necessary

NB_1: Observed background noise is not « perfect »: parasites have caused some interferences on the analogical line and received noise packets do not correspond to regular and predifined sequence of octets. However, we have note a large proportion of « FX » octets (particularly FF and FE octets but also 7F) in received noise RTP packets: may be a possible filtering criteria if we have to detect presence and the absence of noice (absence of noise = speech packet during the speech exchange phase)

NB_2 (To be confirmed): Speech exchanges phase between two end clients supported by IMSLoader (see call flow in the previous slide) will be synchronized via IMSLoader Semaphore mechanism. 4

End to End Speech RTP flowEnd to End Speech RTP flow

From a theoretical point of view, no more problem for the call establishment and release between an IMSloader analogical client and a MRF since end to end call establishment/release is synchronized via SIP protocol (see the previous slides 2 and 3)

From IMSLoader analogical client point of view, the criteria for reception of speech packets sent by the MRF is the reception (when the call is established from a SIP point of view) of packets that does not correspond to background noise packets

5

Analogic IMSloader subscriber and call to a MRF 1/2Analogic IMSloader subscriber and call to a MRF 1/2

AGWSUB1 Asterisk1

1a - SIP INVITE

6

IMS Core eqt AS/MRF

Analogic SUB1 supported by IMSLoader IMS Core

1b - SIP 183

1e - SIP ACK

MR

F a

ccep

ts th

e ca

ll

Dial tone

DTMF numbering

Ringing tone/Background noise

Background noise

RT

P F

low

s

for

rec

eiv

ed

to

ne

s a

nd

w

hit

e n

ois

e

4a - SIP BYE

4b - SIP 200ok

On Hook tone

SU

B2

unho

oks

and

dial

s a

serv

ice

code

1c - SIP 180

Line unhooked

1d - SIP 200

Syn

chro

nous

End

to e

nd c

all

esta

blis

hmen

tS

ynch

rono

us

call

rele

ase

Spe

ech

exch

ange

Analogic IMSloader subscriber and call to a MRF 2/2Analogic IMSloader subscriber and call to a MRF 2/2

MR

F r

elea

ses

the

call

RT

P F

low

s M

RF

an

no

un

cem

ent

Scenario described in the next slide can be summaried as follow: Initial state: call already established between SUB1 and

SUB2 SUB1 puts the active call on Hold SUB1 establishes a second call to SUB3 Switch between the call on hold and the call in active

conversation

ILMSLoader library has to be adapted in order the scenario described above is supported if initial SUB1/SUB2 call was initiated by SUB1 or if initial SUB1/SUB2 call was initiated by SUB2

SIP INFO messages are subsequent requests of the INVITE session, as well as the BYE request. Client and Server IMSLoader libraries have to be written in a symetric manner.

7

Scenario with Hook flash invocation 1/2Scenario with Hook flash invocation 1/2

AGW1SUB1 Asterisk1

1a - SIP INFO (R ou R2?)

8

AGW3 Asterisk3 SUB3

SUB2 Analogical/SIP Environment

1b - SIP 200ok

2a - SIP INVITE

2c - SIP 200 ok

2d - SIP ACK

2b - SIP 180 ringing

SU

B3

unho

oks

(acc

epts

th

e ca

ll in

itiat

ed b

y S

UB

1l)

Dial tone

DTMF numbering

Ringing tone/Background noise

Background

noise

Background noise

RT

P F

low

s

for

rec

eiv

ed

to

ne

s a

nd

b

acg

rou

nd

n

ois

e

SU

B1

puts

the

activ

e ca

ll on

Hol

d by

dia

ling

R (

or R

2)

Line unhooked

Syn

chro

nous

End

to e

nd c

all

esta

blis

hmen

t

Scenario with Hook flash invocation 2/2Scenario with Hook flash invocation 2/2

AGW2 Asterisk2 SUB2

SUB1 Analogical/SIP Environment SUB3 Analogical/SIP Environment

Line unhooked

Initial status: basic call established between SUB1 and SUB2

From here, SUB2 is put to Hold(Hold tone or Hold announcement sent to SUB2?)

Flash + DTMF

1c - SIP INFO (SUB3#)

1b - SIP 200ok

Line unhooked

On

ly B

ac

kg

rou

nd

no

ise

SU

B1

dial

s S

UB

3 nu

mbe

r

Semaphore for synchronisation

of call establishment indication to the calling side

Scenario described in the next slide can be summarized as follow: Initial state: call already established between SUB1 and

SUB2, SUB3 initiates a call to SUB1 who has call waiting

capacities, SUB1 accepts the second call, Switch between the call on hold and the call in active

conversation

The IMSLoader library evololution allows the initial SUB1/SUB2 call was initiated by SUB1 or the initial SUB1/SUB2 call was initiated by SUB2

SIP INFO messages are subsequent requests of the INVITE session, as well as the BYE request.

9

Call Waiting Scenario 1/2Call Waiting Scenario 1/2

AGW1SUB1 Asterisk1

10

AGW3 Asterisk3 SUB3

SUB2 Analogical/SIP Environment

1a - SIP INVITE

1c - SIP 200 ok

1d - SIP ACK

1b - SIP 180 ringingCall WaitingTone

Background noise

Line unhooked

Call Waiting Scenario 2/2Call Waiting Scenario 2/2

AGW2 Asterisk2 SUB2

SUB1 Analogical/SIP Environment SUB3 Analogical/SIP Environment

Line unhooked

Initial status: basic call established between SUB1 and SUB2

2a - SIP INFO (R2?)

2b - SIP 200ok

Line unhooked

SU

B1

acce

pts

the

inco

min

g w

aitin

g ca

ll

Semaphore for INPUT synchronisation

RT

P F

low

s

incl

ud

ing

c

all

wa

itin

g

ton

es

Flash + DTMF

From here, SUB2 is put to Hold(Hold tone or Hold announcement sent to SUB2?)

Semaphore for OUTPUT synchronisation

Scenario described in the next slide can be summarized as follow: Initial state: two ongoing calls with SUB1 (SUB1/SUB2 and

SUB1/SUB3). At least one of these two calls is an incoming call (To be confirmed that this constraint issued from Belgacom fixed CN also applies to Belgacom IMS core)

SUB1 initiates a Call transfer using the generic flash function,

The SUB1 leg is released

« Flash generic » Library feature should cover main needs for Register Recall operations as shown in the table below

11

ECT and Generic flash function1/2ECT and Generic flash function1/2

AGW1SUB1 Asterisk1

12

AGW3 Asterisk3 SUB3

SUB2 Analogical/SIP Environment

Line unhooked

ECT and Generic flash function2/2ECT and Generic flash function2/2

AGW2 Asterisk2 SUB2

SUB1 Analogical/SIP Environment SUB3 Analogical/SIP Environment

Line unhooked

Initial status 1/2: basic call established between SUB1 and SUB2

1a - SIP INFO (R?)

1b - SIP 200ok

SU

B1

initi

ates

the

EC

T

Flash + DTMF

Initial status 2/2: basic call established between SUB1 and SUB3

Final status : after the ECT, a call is established between SUB2 and SUB3 via AGW1 and SUB1 leg is released

2a - SIP BYE

2b - SIP 200ok

Gen

eric

Fla

sh p

roce

dure

Since the voice flow transits via analogical pathes, we are not able to compare (e.g. octet to octet comparison) the received RTP flow with the sent one,

RTP library is able to detect reception of RTP packets

corresponding to background noise, and reception of RTP packets that does not correspond to background noise,

In this context, reception of « no background noise RTP packets » is considered as reception of speech packets,

End to end RTP library is based on a triple control procedure according to the three successive stages below: Detection of « RTP background noise packets »(before the

origin side sends speech flow) Detection of « RTP no background noise/speech packets»

(during the period, the origin side sends the speech flow) Detection of « RTP background noise packets »(after the

period, the origin side has sent the speech flow)

RTP IMSLoader library has been written in a symetric manner. The end party that sends the RTP speech flow (respectively the end party that listens to the RTP speech flow) can be indistinctly the calling or the called party (idem in case of double/call waiting calls etc…)

The same RTP IMSLoader library is alo adapted to 3 PTY speech control (e.g. SUB2 and SUB3 receives speech sent by SUB01).

13

End to End RTP Library 1/3End to End RTP Library 1/3

SUB1 Client (RTP flow sender)

SUB2 Server 1(RTP flow listener)

End to End RTP Library 2/3 – End to End triple control (Two End to End RTP Library 2/3 – End to End triple control (Two parties)parties)

SEM_Server1->Client

SEM_Client->Server1

SEM_Server1->Client1/

Bac

kgro

un

d N

ois

e T

est

(No

spee

ch R

TP

sen

tby

the

Clie

nt)

Only Background Noise detected by the Server

2/ S

pee

ch R

TP

sen

t b

y th

e C

lient

SEM_Client->Server1

SEM_Server1->Client

SEM_Client->Server1

SEM_Server1->Client

Only Background Noise detected by the Server

Speech flow detected by the Server

3/ B

ackg

rou

nd

No

ise

Tes

t

(No

spee

ch R

TP

sen

tby

the

Clie

nt)

Tri

ple

en

d t

o e

nd

RT

P c

on

tro

l

5 se

c co

ntin

uous

RT

P f

low

3 se

c flo

w

mon

itorin

g

Open RTP port

Close RTP port

Open RTP port

Close RTP port

Open RTP port

Close RTP port

SUB1 Client (RTP flow sender)

SUB2 Server 1(RTP flow listener_1)

Starting Synchro

End to End RTP Library 3/3 – End to End triple control (Three End to End RTP Library 3/3 – End to End triple control (Three 3PTY parties)3PTY parties)

SUB3 Server 2(RTP flow listener_2)

SEM_Server2->CLientSEM_Server1->Client

SEM_Client->Server2

SEM_Client->Server1

SEM_Server1->Client

SEM_Server2->CLient

1/ B

ackg

rou

nd

No

ise

Tes

t

(No

spee

ch R

TP

sen

tby

the

Clie

nt)

Only Background Noise detected by the Servers

Open RTP port

Close RTP port

2/ S

pee

ch R

TP

sen

t b

y th

e C

lient

SEM_Client->Server2

SEM_Client->Server1

SEM_Server1->ClientSEM_Server2->CLient

Open RTP port

Close RTP port

SEM_Client->Server2

SEM_Client->Server1

SEM_Server1->Client

SEM_Server2->CLient

Only Background Noise detected by the Servers

Open RTP port

Close RTP port

Speech flow detected by the Servers

3/ B

ackg

rou

nd

No

ise

Tes

t

(No

spee

ch R

TP

sen

tby

the

Clie

nt)

Tri

ple

en

d2e

nd

RT

P c

on

tro

l

5 se

c co

ntin

uous

RT

P f

low

3 se

c flo

w

mon

itorin

g

3 se

c flo

w

mon

itorin

g

Based on detection of RTP packets corresponding to « no background noise » (Has to be verified that current procedure used to determine background noise also matches for MRF announcements)

The duration of the monitoring period and « Background Noise » Threshold has to be configurable independently for each scenario

16

RTP Library for MRF flow detection 1/2RTP Library for MRF flow detection 1/2

MRF SUB1

RTP Library for MRF flow detection 2/2RTP Library for MRF flow detection 2/2

Sp

eech

RT

P s

ent b

y th

e M

RF

Detection of Speech flow

X s

ec fl

ow m

onito

ring

Open RTP port

Close RTP port

Initial status: call established between SUB1 and the MRF

Mapping table has to be defined according the Test scenarios that have to be automated

18

Events on the analogic interface Events on the analogic interface and Asterisk mapping tableand Asterisk mapping table

SIP events Direction

Analogic events

SIP INVITE with request URI

SIP -> Analogic Unhook + dial tone + DTMF dialing of the numbers/characters of the URI

??? SIP -> Analogic Unhook without dialing

SIP INFO + R ??? SIP -> Analogic

SIP INFO + R2 ??? SIP -> Analogic Flash + ???

SIP INFO + R2 ??? SIP -> Analogic

SIP INFO + R3 ??? SIP -> Analogic

SIP INFO + R4 ???TO BE

TO BE

Defined

Defined