Notes as Recorded by Steve Donovan for Day 1

Thursday Feb 8th

08:00  Logistics and Agenda Bashing                                   Dean Willis

No changes to the agenda.

Observation that many items will not take as long as scheduled but conferencing will eat anything left.

08:30  SUBSCRIBE/NOTIFY (split with presence docs, forking)            Adam Roach

topics:

• out of band subs
• pint compatibility
• throttling
• state fetching
• holes, problems, inconsistencies in current draft
• event agents

Goals for meeting

• Consensus on topics
• Raise previously missed open issues
• Robert – need to have process discussion on forming group and when we can get it done.

Mailing list announcement at yahoo groups

Probably need to move all mailing lists off of yahoo groups

Dynamicsoft has offered to host various lists

Discussion topics:

Event Agents –

Jonathan – it is already generalized in the simple drafts.  Types of presence agents - UA, registrar, b2bua.

Jonathan drew a picture explaining how we can all know about the presence state of George W.  Concept of a server in foo.com handling all subs in its domain for george w., sending single sub for the domain and propagating the notifies within foo.com.

Rohan- should this be a baseline protocol question or defined for each event group.  Jonathan – just define event agent as a logical role to make it part of the baseline spec.

Consensus that we should add concept of event agent.  No real change to the protocol. 

Issue whether we should support the migration of event agent support.  Comment from Jonathan is this is just something that happens with sip.

Proposal that event package definition should address how migration happens.

Topic – forking of subscribe –

Rohan- question on forking of subscribe, i.e., can I subscribe to sales and get a notify from each of the members of the sales force.

Jonathan – there are problems with forking subscribes because of record-route will only take refreshes to the first to respond with a 200 OK.

SRD – can be handled with a b2bua.  This fixes record route problem and composition of multiple notifies becomes an application.

Adam – What do we do with generic proxy that forks a subscribe.

Options

1 - subscriber 481s extra notifies

2 – notifies bring call leg into existence like 200 ok ack

doesn’t work because we can’t refresh subscription to all presentities

3 – ignore record route – same as not refreshing subscribes. 

another option would be to include request disposition in each subscribe.  This won’t work because there will be proxies that don’t support caller preferences.

Roberts proposal is to document 1 as the default behavior and document 3 in a paragraph of the document.

Jonathan is concerned that it is presents multiple ways of doing things and will increase complexity.  Also concern if same CallID is used and what proxies will do.

Agreement to write up Roberts proposal with an issue as to whether the call-id should be changed for option 3.

Topic – out of band subscriptions –

Definition – receipt of a notify without an explicit subscription.

Wording in the draft would be that user agents may accept notifies that have not resulted from use of the subscribe method.  Subscription sessions can start from out of band method.

Consensus is that the behavior should be allowed in the spec.

Jonathan suggests a security section that addresses dos attack that would try to take advantage of an amplification of subscriptions to get a third party to send notifies to the target of the attack.  This will be added with wording on how to handle this attack.

Topic – PINT -

Consensus that current wording on PINT is good.

Topic – Throttling of Notifications -

The ability to control the frequency that notifications are sent.

Jonathan – make it event package dependent

Adam – likely to need a general purpose mechanism

Rohan – have first event package to need it define an extension to the sip events package

Consensus is that wording should be added to the draft that event package definition should consider throttling

Topic – State fetching  -

Sub, 200ok, Notify, 200 ok is needed for doing a fetch.

Consensus is that this is good.

Topic – process –

Robert – there are multiple things that are dependent on sip events (refer, simple)

Needs to be a part of the overall SIP WG priorities/working process.

Prioritization of working group tasks -

Rakesh Shah presented his spread sheet showing the drafts that are being worked on.

Attempted to identify the dependencies between drafts.

General frustration expressed with the general lack of progress.

Pushback has occurred from the IESG on a number of work items.

More discussion required.

11:00  Call Control Models (3pcc vs. phonectl vs. peer-to-peer 3pcc)   Rohan

what is appropriate role of:

• protocol translation cases (323<->SIP,RTSP<->SIP, http<->sip…)
• phonectl: tight control/cooperation relationship (comment that mbus does similar things)
• fully distributed call control

What are the primitives involved?

Authorization for call control

Call blob diagrams

• replace (contrived)
• transfer (replace myself)
• take (unreplace myself)
• attended transfer

For conferencing

• add
• insert
• drop
• split
• local join
• “far” join
• local fork
• “far” fork

What’s needed

• Explicit INVITE semantics
• Replaces (invitee sends bye)
• Join-with?
• Fork-with
• What if I can’t mix? Refer the appropriate call legs to a mixer, or refuse the invite

Rohan’s proposal is to add semantics into INVITE messages for things like call center supervisor coaching, operator barge in, etc.

Dean – can be done by having the requestURI identify the role that the UA should take.  This is because it is really an application in the phone.  For instance, a user@host is a basic call, coach@host is a supervisor coach call, etc.

Jonathan – can we get down to a single 3pcc approach?

Question: Should we create a requirements document or extend the CC framework document to reflect Rohan’s discussion?

Rohan – do we want to have a method for fully distributed call control (i.e.; doesn’t depend on 3pcc)?

Does anyone disagree with peer-to-peer call control for transfer? No one objects

Jon – problem is on the extremes

Rick Dean – wants to have central control, what do you do in distributed case when end-points disagree/fight? Answer: build the protocol to prevent it from happening.

Push back in having SIP group solving complex fully distributed call control problem.

Dean – we can solve Rohan’s problem with basic SIP.

Jonathan – conferencing draft and refer should handle everything we need.  What other problems need to be addressed?

Rohan – conferencing draft is missing primitives

Rohan proposed writing a draft to reflect the new primitives he thinks need to be added.

13:30  REFER issues                                                    Robert Sparks

Reporting the results of the REFER

• The notify should reflect the to, from, and call-id headers from the refer as if they had arrived in a subscribe
• If the reference succeeded, the notify must contain event refersuccess
• If the reference failed for any reason, or was attempted after being accepted, the notify must contain event referfailure
• The notifying UA should send exactly on notify with an event from the profile (refersuccess, referfailure).  If multiple notifications are sent, perhaps including events from other extension drafts, the ua must not send both refersuccess and referfailure events.
• Analogous to the case for subscribe described in 3, the agent that issued the refer must be prepared to receive a notify before the refer transaction completes

Discussion about information that comes in the notify request.  Should the content of the response be included? Does this expose too much information.  Probably not the entire message but enough of the message to identify the original refer.

Ben: issue if there is a NAT/firewall between the referor and referee.  Need to add this risk to the security section.

Rick: want to be able to include a SIP message in INVITE and/or BYE messages. 

Rick drew scenario on the pad.

Discussion of requirements for Rick’s scenario.

One of the goals is to be able to have the transfer experience be the same as the current PSTN model.  Need to make sure that in doing so that this does not prevent new or better experiences.

Rick wants to decrease the number of messages and decrease the complexity of the code (in the number of states the ua needs to understand).

Question is whether or not we should optimize for this failure case.

Jonathan: this is not a refer problem but a 3pcc problem that needs to have ringback for an existing session.  A potential solution is to use the RTP DTMF tones approach.

Back to Robert

Add message body of type message/sip to communicate the results.

Other open issues:

-          should refer expire? Better stated as should we be able to expire the referred action? Not an issue for the draft.  The expiration of the referred action can be handled by parameters in the refer-to URL.

-          Should refers be accepted with a 202 or a 200? Conclusion was that a 202 is a little more descriptive and is being used in sip events so it will be used here.

Discussion of what can be included in the refer-to URL.  Rick – concern that refer is too general and will cause interop problems.  Jonathan – need to put rules around what can be there.  Adam – all implementations have the option of rejecting refers with a 403 if it does not want to process the parameters.

Question: what if the triggered request results in more than one 200 ok response.  Proposal is to send a NOTIFY for each.

Robert question: should refer be split into two drafts, a normative REFER draft and how to implement transfer.  General response is yes.

Question from Tom: need to fix syntax of referred-by signature part is options.

Jonathan: need to specify that REFER can be record routed.

Need to make sure that contact is mandatory in REFER.

Question on specification of tags from Rohan: should bis draft be modified to discuss tags more generally than just for INVITE?  Or should refer draft and others that need tags specify handling?  Probably need to add discussion of this in the extensions draft.  Also some wording in bis saying that no other methods in bis draft have tag handling but extensions might.

When do we restart work on join/replaces?  Could stand alone as its own draft.  I think this was the agreed to approach.

Should we use bodies to carry headers for the referred action (instead of in the referred-to URL.  Henning: as body would be more of a pain because it would require multipart mime.

Jonathan: how do we resolve/reconcile differences between refer and handoff.

Rick – escaping complicates and decreases readability of sip.  Also increases the processing required.

Doing message body only reduces the number of levels of escaping by one.

Differences/issues

• Escaping in referred-to URI –

Consensus to go with refer draft approach.

• No method in referred-to URI -
• Keep refer inside call leg -
• General issue with complexity –

Adam – there is nothing forcing anyone to implement the complete scope of the refer draft. 

Robert – market pressure will define which pieces of refer will get implemented.

• Can refer carry SDP – as an implied re-invite to put on hold at the same time. 

Jonathan – breaks firewall proxies that need to look for re-invites.

Discussion of UA handling a refer when it can only handle one “line” or set of call resources.

Proposal: Referee gets a refer when the refer call-id is an existing call leg then the resulting invite should use the same “line”.  Opinion expressed that this is an implementation option. 

Robert agreed to add that refer in an existing session is related to the session, refer that is not in an existing session is not related to the existing session.

16:30  SIP device configuration                             Rick Dean

Goals:

• Simplify configuration of SIP phones
• Reduce user entry requirements
• Work among multiple vendors
• “plug and play”

Issues:

• Discovery
• Authentication
• Parameters
• Updates
• Syntax

SRD: should this be a WG item?

Might be worth discussing here but not formally make it a working group item.

If we don’t work quickly then we will miss the window of opportunity to have a consistent method for configuring sip phones.

Discussion of items to include discussed (from Henning’s draft).  Dan proposes that it be expanded to include thing like firmware upgrades.

Rick: items are specific to a phone but not appropriate in dhcp

Some parameters are user based on some are phone based.

Dan – need to define a framework with common things defined.  Don’t try to define everything.

Question: what is the end user allowed to change.

Henning: who much to people care about the format?  With NG-NG, we will likely have XML anyway.  As such we may want to consider XML for this.  Appears to be consensus.

Discussion continued.  I’m not sure that is important to include detailed notes as this is a discussion between a small group here and my brain has turned to mush.

17:30  SIP conferencing                               Henning

SIP conference modes

• Central mixer
• End system mixing – similar to central, but participant is mixer
• IP multicast for media
• Full mesh signaling – full-mesh media distribution, multicast media?

Membership notification

• RTCP SDES
• Works well for multicast
• Can be suppressed by participant in “stealth mode”
• Sip subscribe/notify – subscription to list of members in the conference using conference URL
• Works well for central server
• Not needed for mesh

Simply a way of knowing who is in the conference, not full conference control.

Billy – would be nice to have a call description language that could be used in general way, i.e. not just for conferences but also for 3 way calls, etc.  Henning agreed that this is in essence what he is proposing with the sub/not approach.

Transition between conference models

• Need to be able to move participants from central/ua mixer to multicast or form mesh to mixer or multicast
• Similar to (supervised?) call transfer

Conference Identification

• We have two identifier: sip call-id and SDP conference ID
• Doesn’t matter for ua mixer or multicast, as only mixer needs to know that call-legs are related
• Can use conference URL as identifier for notifications

• Call-out: only current participants can add new ones
• For callout, all conf participants can have the same id
• If call in allowed, neither call id nor SDP session id can identify conference
• Does call in make sense for mesh?

Full mesh conferencing

• Establish via
• INVITE with membership list or
• REFER with Refer-to list of members
• Rule: both UAC and UAS send membership list in request and 200
• Send INVITE to all new, recurse
• Allow joining of separated clouds(?)

Full mess conferencing cases

• Simultaneous out calls to two parties
• Departures and re joins
• Departures while other party joins
• Liveness detection of mesh?
• Single user participating in multiple simultaneous conferences

Question about whether this is even a model that should be approved.  Henning, at least useful in text chat scenarios.

Deleting members

• Member leaving group send bye to everyone
• May still be contacted by a new arrival that just joins before the bye arrives – just refuse the invitation
• Propagate member only once invite succeeded

Refer vs. invite

• Refer is in line with general arch, but more messages
• Use refer-to with multiple addresses
• However, here refer-to entries need to be skipped if already contacted – contradicts normal behavior needed for re-invite request
• Could use SDP session id, but meaning unclear for call-in (check unicast definition for both sides)

General feeling is that refer will not work.