Rohan Mahy draft-ietf-sip-join and Semantics of REFER

Join draft finished WGLC last week: ZERO comments — Does anyone care? No open issues Who’s read it? Who’s implemented it? Who’s planning to implement it? Join Header Status

RFC 3515 says it is OK to put almost any arbitrary URI in a Refer-To header arbitrary schemes specific SIP methods in or out of a dialog preloaded SIP headers What does that mean? How do I authorize this? Semantics of REFER

REFER in a dialog, Refer-To method=INVITE REFER outside dialog, Refer-To method=INVITE REFER with other methods: REGISTER, SUBSCRIBE, MESSSAGE Nested REFERs Refer-To: (targeted to dialog) Refer-To: (not to a dialog) Refer-To: What semantics make sense? Transfer Click to Dial Move Sub Remote Transfer Fetch content Send Busy

Option 1: Send REFER on existing dialog Option 2: Use a separate GRUU per conversation. (This gets cumbersome very fast. Requires lots of target refresh requests.) Option 3: Use explicit Refer-To header parameters: Refer-To: ;call-id=123 ;remote-tag=abc;local-tag=xyz How do you put REFER requests in a context?

Most uses of REFER other than transfer are unlikely to work on today’s UAs Suggest that we define semantics of cohesive baskets of REFER functionality. Use option- tags to make sure these are supported. Propose that we add the explicit dialog parameters to Refer-To header Provide guidance: to what extent is remote call control, and remote UI invocation (app interaction) OK. How do we proceed?