Conference and MCU services (call-in): http://207.201.171.12/options.htm http://www.summons.com/typecall.htm http://www.yourcall.com/ *** SIP proxy REGISTER responses: - multicast address for user location - use for all outgoing calls (how?) - use for next outgoing calls - token to use for calls [?] - phone shortcut keys Proxy-Info: user-location=224.2.0.1; use=all *** Multiple responses: The basic problem is when you have one guy returning 603, and then some minute later somebody else picks up with 200. How long do you wait, since you don't know how many people are "out there"? What about delayed 200 -> generate ACK and add to call? *** Call Waiting In Israel, when A has Call Waiting, and A is one the phone with B and now C calls A: C hears a different distinctive ringing singal, and can decide if s/he wants to insist or just hang up. A hears a beep every few seconds. B hears nothing at all (since this is none of his business). *** H.323 http://info.dr.lucent.com/~ggf/newh323docs/ *** Payment and billing indicate amount owed in BYE response indicate payment schemes (with preference) verify identity per view, conference room, minute, byte Payment: scheme-name indicate charges: 0.1 DM / byte + 2 DM < 5 DM *** SIP STATUS invoke by Call-Disposition: status report on all Also calls via STATUS STATUS from SIP/2.0 Call-ID: Content-Type: message/sip ???: A how to indicate source of response: INVITE? Host: 181 Queued From: Need to indicate who status-reporting entity is calling. Scenarios: - A invites MCU A sends INVITE to MCU - MCU invites A, possibly triggered by Also: from somebody else MCU INVITE(A) - A invites B to use MCU A could send the OPTION request to B, with Also: MCU. A could also send INVITE to B with "Also: MCU" and send BYE to B when B connects to MCU. - mesh to MCU: mesh invitation, then MCU tells A,B,C,... that it now distributes A,B,C A invites MCU with Also: B,C,D. MCU INVITEs B, indicating replacement "Replace: A" B sends BYE to A, data stops flowing MCU INVITEs C, indicating replacement "Replace: A, B" C sends BYE to A and B, data stops flowing MCU INVITEs D, indicating replacement "Replace: D sends BYE to A, B and C, data stops flowing MCU updates INVITE to B, indicating replacement "Replace: A, B, C, D" - http://buttle.lcs.mit.edu/~mjh/sip.ps INVITE Call-ID: From: SDP conference version old old old old repeat, ignore old new old, unicast old add SDP IP address to list old new old, multic. old no action old * old, unicast new change parameters new * * * alert if not in session already * = old or new RFC 1893, 1894 services: - operator - attended call transfer - multicast call transfer - multicast camp-on: wait until group of people is available -> RTCP *** Branching of invitations Problem: may get several invitations for the same call. Branches proxy without forking: don't change 'To'; just request-URI forking: change 'To' Example: sales@company.com branches into alice@x.company.com and bob@y.company.com 1) x proxies alice into bob@z.y.company.com (Alice is on vacation0 2) returns to sales machine; 4) y just proxies bob@y bob@z.y.company.com 3) sales sends BYE to bob@y to terminate ringing 5) BYE terminates call? Invitation reaches bob@z; Bob returns Location: bob@z.y to (eventually) sales *** PGP headers.tex headers.tex.gz 11835 headers.tex.pgp 12602 -s headers.tex.asc -sta (can extract just signature) headers.tex.asc -sa (compressed, single blob) headers.tex.sig -sb (binary, detached from text) headers.tex.asc -sba (detached from text, ASCII) *** Timing Audix timeout: 22 seconds; answering machine: 20 seconds. *** Source routing: . ACK, BYE should travel the same route as INVITE to allow stateful CPL. . ACK has to select one of the targets if multiple 200s. . Possibilities: - Accept-Location - Source routing: Record-route: request-uri, request-uri, ... reflected to origin Route: request-uri, request-uri *** Forking: MCU/proxy waits for multiple 200, then modifies the session description in ACK and 200 upstream. *** Q.931: bearer capability: SDP called party #: To, with URL qualifiers calling party #: From Cause: status higher-layer compatibility: SDP keypad: gathered into To progress indicator: signal: dialing tone on: on picking up (if there) ringing tone on: on 180 reorder = failure transit network selection: additional parameter? *** ISUP IE Access transport automatic congestion level backward call indicators call reference Call-ID call party number To calling party category ? calling party number From Cause Status Continuity-indication ? Event information 100, 180 Forward call indicators Nature of connection ind. Original called number To redirecting number From, Via redirection information Via, add reasons *** Q.930-Q.940 (van Bosse, p. 249) 1 unassigned number 404 2 no route to transit 48x or 404 3 no route to destination 48x or 404 16 normal call clearing BYE 17 user busy 600 18 no user responding 408 19 user being alerted, no response 408 21 call rejected 603 26 clearing of non-selected user BYE 27 destination out of order 503 28 invalid or incomplete number 484 (address incomplete) 34 no trunk or B-channel 606 606.1 42 switching equipment congestion 503 57 requested bearer capability not authorized 403 65 bearer capability not implemented 501 102 recovery on timer expiration 408 connection to SIT (special information tones)/announcement => caller should enable voice reception upon INVITE Map SIT to 1xx; for announcements like "The number you have dialed has been changed. Please dial 12125551212. Please make a note of it", we would have to return 200 and treat it like a successful call. *** Number 6.022 141 99 Avogadro 3.141593 pi 2.718282 e 1.414213 sqrt(2) 662606876 Planck constant *** SDP problems pick one codec only (parameter) *** Fixes to do: globally unique branch-info retransmission 7 or 11 for request, responses, INVITE remove Via hiding (last call) http://www.sipwg.org/bugzilla username: hgs@cs.columbia.edu password: password