[17:01:28] brian1lindsay joins the room [17:57:28] JohnElwell joins the room [17:59:27] Gonzalo joins the room [18:02:13] BERNARDA1 joins the room [18:02:21] Slides are at: http://aboba.drizzlehosting.com/MARTINI/April-Interim-IV/ [18:02:31] Adam Roach joins the room [18:03:16] Dean Willis joins the room [18:04:40] HKAPLAN1 joins the room [18:05:27] spencerdawkins joins the room [18:07:03] On your own attendant list, you can double-click on the "call-in user" entries and assign them correct names (once you figure out who they are) [18:07:44] Yes, you can do that on your own screen, but I think you cannot spread those updates to other users... [18:07:58] Unfortunatlely, no. [18:08:17] In any case, "Call-in User_7" has not yet declared him/herself [18:08:59] It seems we have a spy on the call :) [18:09:05] Spooky! [18:09:20] We also have callinuser 9, now. [18:09:33] This is terrible! :) [18:17:13] christianschmidt joins the room [18:33:05] Telephone numbers are conveyed either as TEL URIs or as SIP URIs. SIP URIs based on E.164 telephone numbers have the property that the domain part is irrelevant, since the fully qualified E.164 number in the user part is globally unique. This makes it easier for both the SIP-PBX and the SSP to share responsibility for routing requests targeted at such a URI: the SSP can perform contact routing for a request targeted at a URI with the SSP domain name, and can change the domain name when forwarding the request to the SIP-PBX; the latter can then perform contact routing to reach a UA registered with the SIP-PBX. Name-based SIP-URIs do not have this property, and an SSP would not be able to change the domain part when forwarding the request with a target URI having the SSP's domain name, yet would be unable to perform contact routing on a request with a target URI having the SIP-PBX's domain name (without some means of acting as a host for the SIP-PBX's domain name). Non-E.164-based telephone numbers (e.g., private numbers) can be conveyed either as TEL URIs or as SIP URIs, and can be made globally unique by means of the phone-context parameter. In this case the domain part of a SIP URI might again be irrelevant. The use of non-E.164-based telephone numbers as AORs is far less common, and therefore this document does not require that support be available. However, it is likely that the solution will not preclude such AORs. [18:33:19] These are the paragraphs under discussion.... in Issue #39. [18:50:55] who is call-in user #3? [19:11:46] I'm also in favor of painting bike sheds [19:33:54] What's so funny to me about this debate on reg-event is I feel like we're each taking the opposite side from our "normal" positioning [19:34:41] Hadriel: I kind of noticed the same thing. :) [19:55:52] Dean: in a terminal, type in "dig MX opensigcomp.com" [19:55:58] Then type in "dig MX estacado.net" [19:56:01] Compare the results. [19:57:31] It's not reasonable to ask how estacado.net forwards information to opensigcomp.com. It doesn't. They both go to vicuna.estacado.net. [19:58:18] Right. But there might be multipe PBXes with the same domain registering to the SSP. [19:58:38] dig MX estacado.net ; <<>> DiG 9.6.1-P3 <<>> MX estacado.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1278 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;estacado.net. IN MX ;; ANSWER SECTION: estacado.net. 432000 IN MX 0 vicuna-alt.estacado.net. estacado.net. 432000 IN MX 0 vicuna.estacado.net. ;; Query time: 241 msec ;; SERVER: 208.67.222.222#53(208.67.222.222) ;; WHEN: Thu Apr 29 13:56:49 2010 ;; MSG SIZE rcvd: 80 baboba@daisy:~> dig MX opensigcomp.com ; <<>> DiG 9.6.1-P3 <<>> MX opensigcomp.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56024 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;opensigcomp.com. IN MX ;; ANSWER SECTION: opensigcomp.com. 432000 IN MX 10 vicuna.estacado.net. ;; Query time: 175 msec ;; SERVER: 208.67.222.222#53(208.67.222.222) ;; WHEN: Thu Apr 29 13:57:02 2010 ;; MSG SIZE rcvd: 68 dig MX estacado.net ; <<>> DiG 9.6.1-P3 <<>> MX estacado.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1278 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;estacado.net. IN MX ;; ANSWER SECTION: estacado.net. 432000 IN MX 0 vicuna-alt.estacado.net. estacado.net. 432000 IN MX 0 vicuna.estacado.net. ;; Query time: 241 msec ;; SERVER: 208.67.222.222#53(208.67.222.222) ;; WHEN: Thu Apr 29 13:56:49 2010 ;; MSG SIZE rcvd: 80 baboba@daisy:~> dig MX opensigcomp.com ; <<>> DiG 9.6.1-P3 <<>> MX opensigcomp.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56024 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;opensigcomp.com. IN MX ;; ANSWER SECTION: opensigcomp.com. 432000 IN MX 10 vicuna.estacado.net. ;; Query time: 175 msec ;; SERVER: 208.67.222.222#53(208.67.222.222) ;; WHEN: Thu Apr 29 13:57:02 2010 ;; MSG SIZE rcvd: 68 [19:58:51] hey, I'm taking notes; cna't debate here. [19:59:04] Yep. It still works. the range of associated contacts are based on the To header field in the REGISTER [19:59:07] It all woeks [19:59:09] Okay. Later [20:18:35] Yes, Spencer, I appreciate that [20:18:47] christianschmidt leaves the room [20:19:11] Gonzalo leaves the room [20:22:04] JohnElwell leaves the room [20:53:18] spencerdawkins leaves the room [21:01:05] brian1lindsay leaves the room [21:53:56] Adam Roach leaves the room [22:02:09] brian1lindsay joins the room [22:10:40] brian1lindsay leaves the room [23:02:18] HKAPLAN1 leaves the room