1. SIP and ’call flows’ A special type of MSC as used by IETF This differ from the MSC-standard Z.120 as thought in ttm4115 Lill Kristiansen

2. SIP RFC 3261 figure 1 atlanta.com.. …… biloxi.com …… proxy proxy... Alice's...................................... Bob's softphone SIP Phone | | | | | INVITE F1 | | | |---------------> | INVITE F2 | | | 100 Trying F3 |---------------> | INVITE F4 | | | | | | | Media Session | | | | BYE F13 | | | Figure 1: SIP session setup example with SIP trapezoid (from RFC

3. Notes on ’race condition’ A B C | | | | | F1 | | | ------------------> | | F2 | | |----------------------->| F3 | | F4 |-------------------> | |----------------------------------------------->| Depending on conventions (IETF vs Z.120) we may or may not know whether F3 or F4 arrives first at C With “IETF convention”: F3 may even dissapear While F4 arrives anyway If F2 dissapears ‘by network’ then F3 will not be submitted In Z.120 (ttm4115) one can know that: F1 arrives before F3 and none of them are lost (otherwise alternatives must be drawn in Z.120) In Z.120: If there is an option that a message is lost by ‘network’, then network must be drawn as a sepatate entity showing two alternatives (forward or ‘eat’) I will not focus on Z.120 here, we will use the IETF conventions when drawing MScs

4. Notes on ’mixed initiative’ = 2 messages ’bypass each other’ B (or C) may try to call A ’at almost same time as F1’ – A message G1 may be sent from B(/C) towards A and G1 receive at A Before F1 is sent, Between F1 and F3 (on Alice’s time line) Later (on Alice’s time line) Both A and B (and intermediate nodes) must handle this situation (e.g. ignore one of the calls or handle both) As an external view with a global clock we may argue that ’almost at same time’ does not happen – This is ’true’ in our lab, but not on a global scale – Not so as a distributed system in geneal – Each actor/process / vertical line sees only their own time

5. On lost packages see fig. 1 After sending INVITE A s waiting for (some 1xx) and a final 200 OK If 200 OK does not arrive at A for some time – INVITE may be delayed/ lost by network – INVITE may be lost because a Proxy failed/died – 200 OK may be delayed/ lost by network – 200 OK may be lost because a Proxy failed/died Can A tell the difference between these situations? What can A do? Homework: – Read Audestad-book ch. 6.1.6 and relate to SIP

6. More on lost packages Because 200 OK may be lost an ACK is sent – Fig. 1 shows that ACK is sent end-end – Another option is that ACK is sent via proxies If ACK does not arrive at B, – Then B will resend 200 OK – We will test this in the lab!

7. Notes to figure 1 on time F1, F2,….F12 seems to illustrate a time sequence – But in distributed systems such sequence is ’false’ – The only things we know is: A message is sent before it can be received! In ttm4115 (Z.120) the following is true – On each vertical line there is a local time sequence In ttm4115 a message is always delivered, not so in IETF In MSCs as made in IETF, not so! – Network may cause delay – a message may be lost by network (packet loss) (not shown in fig. 1 but all nodes must handle such situations)