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 http://www.nostrum.com/~rjsparks/sip-bis http://www.digitalari.com/alan/bis/ http://66.124.93.238/intro.doc http://66.124.93.238/ua.doc http://66.124.93.238/register.doc http://66.124.93.238/security.doc http://66.124.93.238/iana.doc Minutes of Bis Editors Conference Call October 1, 2001 Agenda ------ 0. overall impressions 1. assign reviews 2. assess which sections Jean can look at Brian: still too much duplication replication between Gonzalo and Jonathan's section (via) to avoid replication: authors of sections should look for sections where they see duplicative information, and negotiate that with the folks who have the duplication. The goal is to define once, reference elsewhere. Goal is readability. Forward references are worse than backwards references. Need to cleanup "changes to -05". (ACTION: Jonathan R.) 1. Introduction Brian Rosen Robert 2. Overview Brian Robert 3. Terminology Brian Robert 4. Brian Robert 5 Brian Robert 6. URLs Jon Jonathan 7. SIP Messages Henning Alan 8. SRV Jonathan Brian 9. Transactions Gonzalo Jon 10. HL Behavior Gonzalo Robert 11. Registrations Henning Robert 12. options JOnathan Brian 13. Proxy Gonzalo Jonathan Jon P 14-17. Alan Jonathan 18 Security Brian Robert 19. Header Robert Jon 20. Response codes Gonzalo Robert 21. Examples Jonathan Henning 22. BNF Robert Alan 23. iana Jonathan Gonzalo Acknowledgements send names of people to Henning Author List send information to Henning Jonathan will send email to Eve and Mark about co-authorship GOAL: try to build next rev next Monday with all comments incorporated. Go for the big parts first try and have all comments in by Thursday morning Sections Jean can start at now: URLs Header fields response codes Terminology Definitions Registrations http://www.nostrum.com/~rjsparks/bis-04-num.txt http://www.cs.columbia.edu/~jdrosen/sipv03.pdf This is my understanding of the schedule: Oct 22 - Fix xrefs, fix MUST/MAY/SHOULDs, fix interfacing, fix terminology, text figures by Monday evening. Oct 23 - Review draft Oct 24 - Submit changes in the morning. Submit to SIP list? (it wasn't clear when it would go to the list) Oct 24-31 - tech writer edits (This time works for me, but the weekend will be tied up with family obligations) What happens to the rest of the schedule? Mon, Oct 29 - bis06 available Thr, Nov 15 - bis07 available, start of working group last call Sat, Dec 01 - Deliver bis08 to IESG SIP security task force sip-security-dt@marconi.com threat analysis text for bis mechanisms Jan. 15 - bis06 34 open issues Routing Robert Message-Length Henning Overlapping INVITE Jon Heterogeneous error response problem 3-way handshake offer-answer Jonathan TLS vs. IPsec which is MUST, MAY UAS challenges previous-hop proxy session keys (BYE = INVITE) TBD: Separate bibliographies Mon, 07 Jan 2002 12:12:34 -0500 From: Jonathan Rosenberg Enclosed are notes from the meeting. Fortunately, Jean took notes, which the below is based on. Attendees: Jonathan, Allan, Robert, Jean, Jon, Henning, Brian Agenda and Minutes: 1. Status Jonathan - IMS is in jeopardy in 3GPP. It is the end of the world if IMS falls out of 3GPP. Have received Alison's comments. 100s of comments on the first 40 pages. Bibliography needs to be changed to have separate normative and non-normative references. We also may need to trim the author list. Still problems with bugzilla emails. Next time someone assigns a new bug to robert, shoot him an email to let him know so we can check. CVS emails now working again. Please indicate in your commits what bugs are being resolved by it, and who did it. 34 open issues - many relate to source routing. 6 major open issues - Message length, overlapping INVITEs, Heterogeneous forking, 3-way handshake, TLS vs IPsec, Routing Robert - a day or two out on releasing a draft on routing. Integration will go very quickly (2-3 hours) Henning and Brian will be traveling Brian on security - No due dates yet, but clear deliverables - threat analysis and requirements, bis text, ID. A month for delivery. Bis-06 could go to IESG before this is done. General agreement amongst team that iesg is not likely to be done with it without security. Jonathan - has 20 pages on threat analysis. Will share it with the security team. Jean - reviewed stable sections in November. 2. Milestones Timeline: Jan 15 - bis-06 Last Call bis-06 without security. We won't issue bis-06 until major issues are resolved. We will work towards the above date and slip a week as needed. Action Items: Jonathan - compile an internal version COB today. Jonathan - send out summary of major open issues to list, and request people focus on those. DUE: today. Jonathan - assign rest of the bugs, the pre-05 bugs are not really assigned to the right people. DUE: today Robert - release routing draft on Wednesday. Jonathan - will handle Alison's comments. Minor ones will just be added without placing them in Bugzilla. DUE: done by end of week. Henning - will figure out how to split the bibliography in latex. DUE: asap. Jean - start editing during last call. All - check in your changes based on bugzilla bugs by Jan 13. All - resolve as many major issues as possible. TO do this, we will split up the 6 major open issues, and assign an owner. They are: Henning - owns Message Length issue. Jonathan - owns 3-way handshake issue. Jon - owns overlapping INVITE issue. Alan - owns heterogeneous forking issue. Robert - owns routing issue TLS/IPsec war assigned to security team "own" means: * within next day or two, formulate a solution based on the feedback on the lists, think it through, etc. * post the solution on the list * DRIVE it through, which means you must promptly answer questions or address comments, prod people that you need feedback from. MAKE IT HAPPEN. SDP options: Need a way to define it. Current plan - yet another mmusic doc. Brian was concerned its too many docs. Jonathan owns trying to figure out a better way, perhaps include in simcap. 28Jan -- release bis06, call for "WGLC-like" scrutiny, caveats that loose-routing may be incomplete. 4Feb -- incorporate comments, release bis07, issue WGLC 18Feb, -- end WGLC, incorporate comments 19Feb -- release bis08, send to iesg for IESG last call 26Feb -- incorporate all comments from IESG 27Feb -- submit updates in bis-09, that goes on IESG agenda 7Mar -- IESG meeting. Accept, send RFC editor, send RFC# to 3GPP History of document size: RFC2543 331k bytes -02 381k bytes -04 449k bytes -05 510 k bytes -06 667k bytes (Largest RFC published to date - 585k bytes) I looked at H.225v2 (RAS) and H.245v3. This is a non-standard document I found http://standards.pictel.com/ftp/avc-site/till_0012/9706_Her/APC-1182.zip For RAS, the terminal can tell the gatekeeper in ARQ (admission request for the call either incoming or outgoing) whether the reservation is controlled by terminal or should be controlled by gatekeepr and sends a bandwidth estimate. The gatekeeper can respond with success or failure (resourceUnavailable) and responds back with bandwidth for the call. There is no connection to RSVP parameters in H225 message itself other than the bandwidth value. This is essentially used to find out who will do resource reservation. For H.245: The terminals convey there RSVP capabilities in initial capability exchange (fields in RSVPParameters are qosMode=guaranteed or controlledLoad token rate, bucket size, peak rate, min policed and max packet size.) Then in every open logical channel (OLC) the RSVP parameters can be present. OLC reject or close logical channel can have reason as insufficientBandwidth or reservationFailure. I did not find any reference to RSVP in Q.931 call setup. But if fast connect is used (when H.245 OLC parameters are carried in Q.931 setup) it is possible to get the resorce reservation infomation (success/failure) during call setup. BUT: since the transport address of receiver is needed to initiate resource reservation, the caller can not initiate reservation until it gets the OLC Ack. And after OLC Ack if resource reservation fails it may close the logical channel. What exactly are you looking for? About the last line you mentioned "it waits for reservation to complete before call setup (Q.931) is comlplete", I think it won't be possible in H.323 v2 even with fast connect, because sender will not know the media transport address of callee until Q.931 connect. Assuming media transport are not passed earlier in Alerting/Call proceeding. Or probably they meant that call setup is the complete Q.931-H.245 procedure. And if the reservation fails they teardown the call. Monday, 9:30 US CST, 1530 GMT. Bridge call-in number +1 877 769 6228 or +1 706 679 6523 passcode 972 473 5455 August 4, 1999. You can find the entire thing online, of course. Its US patent #6,324,279: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='6,324,279'.WKU.&OS=PN/6,324,279&RS=PN/6,324,279