SIPPING 73 Friday 9am Bruce Lowekamp Note well presented question on draft-drage-sipping-service-identification-02. still pending on Keith closing an open issue. ---------------------------------------- Updates to PAI John Elwell 9:23 ok with removal on pai in response? consensus call with no responses so removed. Cullen ok with change. Hadriel believes this is needed. late objections were received so polling again about whether this is OK. discussion about IETF process and completing discussion on mailing list 9:29 drage: 3325 has an ambiguity about responses. this draft doesn't need to address that ambiguity and make a change in 3325's applicability. it's not authenticating responses. it's how can take authentication from an existing message and note that same circumstances apply 9:33 proposal to include service URNs. No ruffled feathers, but cullen points out that if it's included in the draft, how it works needs to be defined. Currently the draft has wiggle room that tells an implementation not to reject it, but if included it needs to be specified. Andrew Allen: discussion that URN is OK if it comes from the PSAP Hannes: there is no clear requirement here from ecrit yet Brian Rosen: there is a charter item to deal with the callback, and this should be addressed in that item AA: this should be allowable, but let's not need to revise it again Christer: ABNF can allow, but don't have a use gc: action point bring to list and decide there 9:39 Brett Tate proposes disallow PAI in ACK and CANCEL. Is this OK? Hadriel: why would we disallow it? receiver should not be trusting it, no reason to disallow in a message if we list which messages it can be included in, need to update table 2 of 3261 sparks: will send text that applicability is irrelevant in circumstances such as CANCEL which is only hop-by-hop issue isn't pai in a register message through a proxy as much as changing the authorization mechanism specified in 3261. now believe tha this isn't really in a draft, but JE believes a sentence needs to be changed to make this clear, so take it to the mailing list. ---------------------------------------- Overload design team status Volker Hilt current draft is stable and heading toward wglc. want to make precise what requirements are before giving to sip. Also want to document what needs to be in draft for ietf and protocol people ---------------------------------------- profile datasets Martin Dolly 9:55 need to update this because of the dependencies. needs feedback ---------------------------------------- Christer How to document O/A conclusions? 10:02 Andrew: there's a backward compatibility problem here. if you stop retransmission, uac may perceive a change if it isn't updated elwell: how do you know where responses came from uas and not proxy? christer: uac will have to send new prack without an offer if it got 488 for example. this draft is informative, but there are normative changes that need to be identified and put into a new draft 10:07 Andrew: this will require anew option tag because previous spec didn't allow a 4xx response to a prack paul kyziat: always could have gotten a 4xx response from an intermediary, we just never defined what they mean drage: now isn't the time to debate a new option tag. please get comment on list and explicitly describe how behavior would be different w w/out option tag 10:14 Francois: why would we change 3262 requirement that first reliable response must have sdp? sparks: this was there to avoiding glare? gc (as chair): we need to have a reason to look at changing it elwell: this may impact 3261 if changed francois: if this is changed, there needs to be backward compatibility work process clarification: mb/kd: sipping will identify problems and has a proposed solution, then sent to sip kd: since this is likely to be 3262bis, please identify all issues ---------------------------------------- event-throttle krisztian kiss kd: this needs to be reviewed and discussed on the list. need to decide whether this is to stay in sipping or move to sip mb: please read and discuss. brian rosen to review elwell: is this becoming a wg item? mb: call made after we have feedback gc: hum on interest clear consensus on general interest sparks: geopriv is expecting work from sipping/sip on this effort ---------------------------------------- context-id-requirements Salvatore Loreto Alan Johnston: do you need to know correlation at establishment or sometime later? affects mechanisms required a: don't have any specific requirement on when needs to start hadriel: does this apply across everything including b2buas a: yes 10:39 hadriel: re-asking when you need to know the dialog-ids. what are requirements to solve use-cases? a: need to know at time you want your conversation to be presented on a different device gc (as chair): main goal is to gather interest whether something that correlates different dialogs makes sense. observation is that drafts in different groups have a similar requirement but with many use cases elwell: requirements seem to be halfway to mechanism anyway. can't get from figure on "dua clients" slide that we need a mechanism for correlating dialogs. 10:43 Laura Liess: need dialog correlation for sip dialogs belonging to same sip calls across b2buas. can this be added to draft? Paul Kyziat: don't have problem with wording of use cases, but there is more in here. don't know if they are media or signal lines needing to correlate. only need dialog correlation if signaling. fluffy: really interested in use-case where rhs is high capability media terminal and on lhs is b2bua having multiple individual-feature lightweight device roni: aware of implementations of this, but what is described is not enough b/c of q how audio device can tell video device to connect to same device that is not known until later. call flow needs to be specified before requirements. kd: if this goes forward, there is a lot to do in sipping before this goes any further. need to clearly understand semantics of correlation. local vs global, scoped only to dialog correlation or impact on applications using dialogs, and how many correlations can I have with dialog 1:1, 1:n, n:n? gc: many different use cases, need to figure out semantics of all of currently existed use-cases gc: much interest, need to work on identifying range of interests and then address that ---------------------------------------- cc-uui Alan Johnston looking for feedback whether 7 requirements make sense kd: sip is looking for consensus call to confirm that people are interested in working on call hum that sipping will agree on requirements and then give to sip strong consensus ---------------------------------------- siphandover Jan poll for who is interested in working on this issue with authors? two hands elwell: interested in problem space, but can't commit resources 11:01 Loreto: issue with draft is to work properly with 3gpp ---------------------------------------- Debugging SIP Networks Kar Ann Chew Hadriel: this is important work, but sip seems like the wrong level to address this. how do you debug sip with sip? seems to need to be vertical rather than horizontal. 11:13 gc: there is an ipr disclosure related to this draft and to other drafts posted to list dan york: concerned about security with this draft triggering sending information somewhere dale worley: the event package itself isn't the interesting thing, it's the procedures around it. You can trigger logging, but you probably want to use a filtering mechanism, which may be non-trivial to do well. Then retrieval mechanism is needed. These details aren't in there. 11:21 scott lawrence: would be very useful to begin to create a catalog of document(s) describing best practices for debugging sip using sip (implementers don't typically understand what is actually already possible). Also other techniques. Pointed to an expired draft for debugging. Andrew Allen: what is the scope of this. is this intended to be a general solution? or just run within a single operator's trusted domain? Peter Dawes: intended as 3gpp, but interest seems general Hadriel/Allen: this is already agreed to in 3gpp Hadriel: topic incredibly important, but mechanism entirely wrong sparks: procedurally, this could advance to an rfc without discussion/agreement in the room. It is entirely possible for an idea to be created and progress to an rfc between meetings. read what hits the list kd: for all the people who've said this is useful, please send that comment to the list