1. 1 S. WEYL – 31/01/2011 Basic Call Flows cases and analogic IMSloader subscribers AGW Belgacom

2.  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 IMSLoader 1/2

3. AGW SUB1 Asterisk1 1a - SIP INVITE 3 Analogic calling and called subscribers supported by IMSLoader 2/2 AGWAsterisk2 SUB2 Analogic SUB1 supported by IMSLoaderAnalogic 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 RTP Flows for received tones and white noise 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 SUB1 unhooks and dials SUB2# 1c - SIP 180 Line unhooked 1d - SIP 200 Synchronous End to end call establishment Synchronous call release Speech exchange

4.  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 flow

5.  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/2

6. AGW SUB1 Asterisk1 1a - SIP INVITE 6 IMS Core eqtAS/MRF Analogic SUB1 supported by IMSLoaderIMS Core 1b - SIP 183 1e - SIP ACK MRF accepts the call Dial tone DTMF numbering Ringing tone/ Background noise Background noise RTP Flows for received tones and white noise 4a - SIP BYE 4b - SIP 200ok On Hook tone SUB2 unhooks and dials a service code 1c - SIP 180 Line unhooked 1d - SIP 200 Synchronous End to end call establishment Synchronous call release Speech exchange Analogic IMSloader subscriber and call to a MRF 2/2 MRF releases the call RTP Flows MRF announcement

7.  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/2

8. AGW1 SUB1 Asterisk1 1a - SIP INFO (R ou R2?) 8 AGW3Asterisk3 SUB3 SUB2 Analogical/SIP Environment 1b - SIP 200ok 2a - SIP INVITE 2c - SIP 200 ok 2d - SIP ACK 2b - SIP 180 ringing SUB3 unhooks (accepts the call initiated by SUB1l) Dial tone DTMF numbering Ringing tone/ Background noise Background noise Background noise RTP Flows for received tones and bacground noise SUB1 puts the active call on Hold by dialing R (or R2) Line unhooked Synchronous End to end call establishment Scenario with Hook flash invocation 2/2 AGW2Asterisk2SUB2 SUB1 Analogical/SIP EnvironmentSUB3 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 Only Background noise SUB1 dials SUB3 number Semaphore for synchronisation of call establishment indication to the calling side

9.  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/2

10. AGW1 SUB1 Asterisk1 10 AGW3Asterisk3 SUB3 SUB2 Analogical/SIP Environment 1a - SIP INVITE 1c - SIP 200 ok 1d - SIP ACK 1b - SIP 180 ringingCall Waiting Tone Background noise Line unhooked Call Waiting Scenario 2/2 AGW2Asterisk2SUB2 SUB1 Analogical/SIP EnvironmentSUB3 Analogical/SIP Environment Line unhooked Initial status: basic call established between SUB1 and SUB2 2a - SIP INFO (R2?) 2b - SIP 200ok Line unhooked SUB1 accepts the incoming waiting call Semaphore for INPUT synchronisation RTP Flows including call waiting tones Flash + DTMF From here, SUB2 is put to Hold (Hold tone or Hold announcement sent to SUB2?) Semaphore for OUTPUT synchronisation

11.  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/2

12. AGW1 SUB1 Asterisk1 12 AGW3Asterisk3 SUB3 SUB2 Analogical/SIP Environment Line unhooked ECT and Generic flash function2/2 AGW2Asterisk2SUB2 SUB1 Analogical/SIP EnvironmentSUB3 Analogical/SIP Environment Line unhooked Initial status 1/2: basic call established between SUB1 and SUB2 1a - SIP INFO (R?) 1b - SIP 200ok SUB1 initiates the ECT 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 Generic Flash procedure

13.  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/3

14. SUB1 Client (RTP flow sender) SUB2 Server 1 (RTP flow listener) End to End RTP Library 2/3 – End to End triple control (Two parties) SEM_Server1->Client SEM_Client->Server1 SEM_Server1->Client 1/ Background Noise Test (No speech RTP sentby the Client) Only Background Noise detected by the Server 2/ Speech RTP sent by the Client 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/ Background Noise Test (No speech RTP sentby the Client) Triple end to end RTP control 5 sec continuous RTP flow 3 sec flow monitoring Open RTP port Close RTP port Open RTP port Close RTP port Open RTP port Close RTP port

15. 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 3PTY parties) SUB3 Server 2 (RTP flow listener_2) SEM_Server2->CLient SEM_Server1->Client SEM_Client->Server2 SEM_Client->Server1 SEM_Server1->Client SEM_Server2->CLient 1/ Background Noise Test (No speech RTP sentby the Client) Only Background Noise detected by the Servers Open RTP port Close RTP port 2/ Speech RTP sent by the Client SEM_Client->Server2 SEM_Client->Server1 SEM_Server1->Client SEM_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/ Background Noise Test (No speech RTP sentby the Client) Triple end2end RTP control 5 sec continuous RTP flow 3 sec flow monitoring

16.  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/2

17. MRF SUB1 RTP Library for MRF flow detection 2/2 Speech RTP sent by the MRF Detection of Speech flow X sec flow monitoring Open RTP port Close RTP port Initial status: call established between SUB1 and the MRF

18.  Mapping table has to be defined according the Test scenarios that have to be automated 18 Events on the analogic interface and Asterisk mapping table SIP eventsDirectionAnalogic 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 Defined