Agenda for IETF: Topic: Dialog event package Goal: To get UA vendors to produce dialog event packages with all of the fields needed to support call control features. Actions: Revise Internet-Draft to match our current usage of dialog event packages. (done) Request time at the Sip working group meeting to harangue. Update interop.pingtel.com dialog event analysis CGI page to match latest needs. (done) Update interop.pingtel.com to gather dialog event information about all registered UAs. (waiting for RLS) Topic: Response codes improvements needed for multiple path routing Goal: To get IETF to split certain response codes into two response codes (one for situations detected by UA and one for situations detected by proxies), so that sipX can handle multiple path routing cleanly. And to get UA and proxy vendors to adhere to the new response codes. Actions: Write Internet-Draft describing the problem and recommending definition of new response codes to disambiguate certain cases. (done) Request time at the Sipping working group meeting to present the problem. Topic: Stop using 6xx response codes. Goal: To get UA vendors to stop using 6xx response codes because those codes muck up forking and routing of calls. Actions: Write Internet-Draft describing the problem. Request time at the Sipping working group meeting to present the problem. File bug reports with Polycom, Snom (if needed), LG Nortel (if needed). Topic: Straighten out the "number not found" response codes. Goal: To ensure that there is a common understanding of the significance of the "number not found" response codes (404, 410, and 480), and then to ensure that sipX adheres to that understanding, in order to prevent interoperability failiures. (Check out 403 as well.) Actions: Write Internet-Draft describing the problem. Poll participants to identify other vendors' understanding of these response codes, especially in regard to how SIP agents respond to the different response codes; establish consensus. Revise Internet-Draft to document consensus. Identify sipX tasks (if needed) to make sipX conformant. Topic: BLA Goal: To get BLA standardized and supported by UAs. Actions: Survey IETF and Sip-Implementors to determine degree of BLA support. Suggest improvements to BLA Internet-Draft as necessary (with an eye toward our implementation). Encourage Sip working group to approve the BLA Internet-Draft. Convey Pingtel's commitment to BLA support. Topic: MOH Goal: To get the sipX-compatible music-on-hold method recognized as the standard way to implement MOH. Actions: Lobby to amend Internet-Draft service-examples-12 to include our MOH scheme, describing its advantages. Lobby representatives of UA vendors to adopt our MOH scheme. ** sip-dialog mail to RAI Sinnreich will take it to P2P. sip-gruu-implement ** redundancy-response request time at Sipping to Sipping ** dialog events for instrument to Sipping? to sip-implementors ** authentication problems to Sipping request time at Sipping scoping (aborted) appears that feature tags / caller prefs is sufficient for this ** BLA 6xx 404, 410, 480 * draft-worley-resource-lists-00 Status: being written * draft-worley-sip-dialog-03 Status: posted * draft-worley-sip-gruu-implement-02 Status: posted Updated to match -11. * draft-worley-sip-many-refers-01 Status: expired Re-submit. Check for new uses. (Consider REFER with Replaces.) * draft-worley-sip-redundancy-response-00 Status: posted Remember to post in sipping as well as sip. * draft-worley-sipping-forking-02 Status: posted * draft-worley-sipping-pickup-03 Status: posted * narrow vs. wide scoping Status: aborted, taken over by callerprefs * dialog events for instrument * Authentication problems * Subscribe duration * URI equivalence amendment From: Paul Kyzivat You make a good point in this case. But we need to step carefully before making sweeping changes. You say you don't find any *use* of URI comparison in 3261. Actually there is at least one, in section 10.3, step 7. It is used to compare Contact URIs in the request to those already registered. It seems to me that there is simply a need for multiple comparison rules for different circumstances. Paul Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-multiple-refer-01.txt X-Name: Miguel Garcia From: Miguel Garcia To: dale.worley@comcast.net Date: Thu, 11 Jan 2007 23:40:14 +0200 CC: sip@ietf.org, jaiminp@huawei.com, Gonzalo Camarillo X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070111233901-14F4EBB0-15A6AEF7/0-0/0-1 X-Nokia-AV: Clean Jaimin, Dael: The draft speaks about repeated URIs, meaning equivalent URIs. I see the point that Dale wrote on equivalent URIs, which has been already discovered by GRUU. I also agree that we should have similar considerations here. If we need such text, it should be written in the framework for URI-list services, since it applies to any draft, not only the REFER draft. http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-services-06.txt /Miguel sip-bounces@ietf.org wrote: > From: Jaimin Pancholi > > As per the draft: > If the URI-list of the REFER request contains a repeated URI, the > REFER-Recipient MUST behave as if that URI appeared in the URI-list > only once. The REFER-Recipient uses the comparison rules specific to > the URI scheme of each of the URIs in the URI-list to determine if > there is any URI which appears more than once. > > Now if URI is appearing twice with different copy control or other > attribute, which URI should [be used?] > > The problem is worse than this. Due to the strange rules for SIP URI > equivalence, these are equivalent: > > sip:foo@example.com > sip:foo@example.com;parameter=value > > and these are equivalent: > > sip:foo@example.com > sip:foo@example.com;parameter=other-value > > but these are *not* equivalent: > > sip:foo@example.com;parameter=value > sip:foo@example.com;parameter=other-value > > So if all three are present in a URI-list, it's not even clear how > many should be used. > > I seem to remember having a similar problem in the GRUU discussion, > and the outcome was that the GRUU I-D needed to define a new > comparison between SIP URIs that was stricter than 3261's > "equivalence". > > It appears that we need that same comparison here. > > This leads me to ask if we should entirely replace the definition of > "equivalent URIs" in section 19.1.4 of RFC 3261. I did a quick search > of the text of 3261, and it doesn't appear that the equivalence of > URIs is *used* anywhere.