1. July 28, 2008BLISS WG IETF-721 The Multiple Appearance Feature using the Session Initiation Protocol (SIP) draft-johnston-bliss-mla-req-02 Alan Johnston Mohsen Soroushnejad Venkatesh Venkataramanan Paul Pepper Anil Kumar

2. July 28, 2008BLISS WG IETF-722 Status Most changes relate to appearance selection (appearance) Continuing work by Design Team. In addition to the co-authors, they are: –Martin Dolly –Andrew Hutton –Raj Jain –Fernando Lombardo –Derek MacDonald –Bill Mitchell –Michael Procter –Theo Zowzouvillys

3. July 28, 2008BLISS WG IETF-723 Appearance Selection Issue Most UAs don’t need to pre-select appearance number –Can learn appearance number for incoming calls from Alert-Info parameter –Can learn appearance number for outgoing calls at time of alerting (18x response) Some UAs do have a user interface requirement to “seize” an appearance prior to “dialing” –Two step process: appearance selection, then call placed - each step requires confirmation –Usually only hard SIP phones with lamp/buttons, etc

4. July 28, 2008BLISS WG IETF-724 Appearance Selection Options PUBLISH/NOTIFY approach –Proposal in -01 version and discussed at IETF-71. –Similar to deployed systems Floor Control approach –Discussed at IETF-71 –New text in -02 version INVITE overlap dialing approach –Not discussed before –New text and call flows in -02 Note: these methods only apply to UAs that require pre-selection of appearances Need to decide which approach to move forward with

5. July 28, 2008BLISS WG IETF-725 PUBLISH/NOTIFY Approach UAs send PUBLISH/NOTIFY to Appearance Agent prior to sending the INVITE (“dialing”) –Publish state of “100 Trying” A race condition can be detected immediately by the Appearance Agent and indicated to UA in response to PUBLISH/NOTIFY –Appearance Agent would send 4xx to UA and also send a NOTIFY with new dialog state –UA would then publish again with another appearance number INVITE sent after a 2xx response to PUBLISH/ NOTIFY is received Requires a special appearance-aware Event State Compositor.

6. July 28, 2008BLISS WG IETF-726 Floor Control Approach Models each appearance number as a separate floor. UAs use BFCP (RFC 4582) to select an apearance (request a floor) INVITE sent after positive reply from Floor Control server. Uses standard SIP Event State Compositor for dialog package Requires a floor control server and a moderator application that understands the multiple appearance feature and can communicate with the Proxy server for call state information.

7. July 28, 2008BLISS WG IETF-727 INVITE Approach UA sends an INVITE to proxy to select an appearance –The appearance number selected would be carried in the INVITE (Request-URI or header field) –If appearance is available, proxy sends 484 Address Incomplete (similar to overlap dialing RFC 3578). –If appearance is not available, proxy sends another 4xx response and the UA tries again. UA sends a new INVITE, this time with dialed URI, to proxy and this reserves the appearance number for this dialog. UA publishes appearance number in dialog state.

8. July 28, 2008BLISS WG IETF-728 INVITE Call Flow Alice Proxy 1 Proxy 2 Bob | | | | | INVITE (app=2) F1 | | |--------------->| | | | 403 F2 | | | |<---------------| | | | ACK F3 | | | |--------------->| | | | INVITE (app=3) F4 | | |--------------->| | | | 484 F5 | | | |<---------------| | | | ACK F6 | | | |--------------->| | | | INVITE F7 | | | |--------------->| INVITE F8 | | | 100 F9 |--------------->| INVITE F10 | | | | |<---------------| | | | | 180 F12 | | | 180 F13 |<---------------| | 180 (app=3) F14|<---------------| | |<---------------| | 200 F15 | | | 200 F16 |<---------------| | 200 F17 |<---------------| | |<---------------| | | | ACK F18 | | | |--------------->| ACK F19 | | | |--------------->| ACK F20 | | | |--------------->| | Both Way RTP Media | | |

9. July 28, 2008BLISS WG IETF-729 Comparison PUBLISH/NOTIFY has deployments and supporters, but others claim it violates RFC 3265. Floor Control doesn’t seem to have any supporters, but is a clean architectural fit. –UAs likely to implement multiple appearance feature seem unlikely to implement BFCP for other reasons, so this is an extra protocol and burden on implementations –Requires an extra offer-answer exchange to establish TCP session with Floor Control Server INVITE approach stretches the approach used for overlap dialing, but does not require any new protocols or offer-answer exchanges Consensus of Working Group??

10. July 28, 2008BLISS WG IETF-7210 Plan Revise document with only one approach for appearance selection Refine approach, adding call flows