Hi Francois, my comments at the end...
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Francois Lessing Sent: Tuesday, January 15, 2002 7:30 AM To: Implementors Subject: [Sip-implementors] B2BUA role in SIP network, example application Lots of questions concerning the B2BUA, The RFC defines a B2BUA, but I am not clear on the role a B2BUA will play in the SIP signalling network, or how it will interact with other logical entities. draft-rosenberg-impp-presence-01 describes behavior where a SIP network element becomes a B2BUA (for a SUBSCRIBE recieved), OR the element behaves like a proxy, depending on some conditions. Does anyone know of other examples where a network element may become a B2BUA ?? I looked around and could not find a term for the SIP network entity that may have a number of logical behaviors: B2BUA, proxy or redirect. How about Network Server ? What is the advantage of this 'switching' behavior ?? (e.g. between B2BUA, and proxy) Are there examples of a stand alone B2BUA ?? (no switching possible) Are there restrictions on the type of header information a B2BUA is allowed to copy between sessions ?? (when does it start to look like a proxy ...) Line 671 - 676 of bis 05 describe how the same software can behave like one of the logical entities - proxy - redirect server - UAC - UAS on a transaction by transaction basis. Can I include a B2BUA in this list ? Does anyone have good examples of B2BUA applications or call flows ? Is it a 'MUST' to generate other SIP requests in order to gather information on how to respond to a received request ?? Can the B2BUA do something else ... like consult a user.... Why does the RFC state in the B2BUA definition that it keeps state "unlike" a proxy ?? It seems that a proxy may also keep state, of a complete call if it likes. -- Francois Lessing Trillium Digital Systems, an Intel Company Los Angeles, USA Tel: +1 310 481 5937 Fax: +1 310 481 5558 -----End of Original Message----- ... The B2BUA is what we call an 'Application Server' or 'Application Services Broker', it is necceary when a call has to be controlled from a central point. It is neccesary to offer complex services, for example, if you implement a prepaid telephony service over SIP, when you initiate a call from a public telephone, probably you have to identify yourself, then, how can you do that with a simple SIP call? The better way is by means of a B2BUA. In the following scenario a user starts a pre-paid call, during the call, if the credit expires, the services need the credit-card numbers in order to recharge the credit, then the call is directed to a Media-Server (the node that collects digits), the Media-Server sends the digits to the B2BUA and then, when the digits are checked, the call is directed to the final destination again: A B2BUA B MS 1. ----------------> INVITE (SDP A1) 2. <---------------- 180 Ringing 3. -------------------> INVITE (SDP A1) 4. <------------------- 200 OK (SDP B) 5. -------------------> ACK 6. <------------------ 200 OK (SDP B) 7. ------------------> ACK 8. <====================> Media Session 9. ----------------------> INVITE (SDP 0 - HOLD) 10. <---------------------- 200 OK (SDP B) 11. -----------------------> ACK 12. <------------------ INVITE (no SDP) 13. -------------------> 200 OK (SDP A) 14. -----------------------------------------> INVITE (SDP A) 15. <----------------------------------------- 200 OK (SDP C) 16. <------------------- ACK (SDP C) 17. -----------------------------------------> ACK 18. <======================================> Dialogue requesting digits 19. <================== Digits 20. -----------------------------------------> BYE 21. <---------------------------------------- 200 OK 22. --------------------> INVITE (no SDP) 23. <-------------------- 200 OK (SDP B) 24. <---------------------- INVITE (SDP B') 25. ----------------------> 200 OK (SDP A) 26. ---------------------> ACK (SDP A') 27. <---------------------- ACK 28. <======================> Media Session 29. <--------------------- BYE 30. ----------------------> 200 OK 31. <--------------------- BYE 32. ----------------------> 200 OK 1. User A sends an INVITE to the Controller, the INVITE contains A's SDP 2. The B2BUA sends back the 180 Ringing message to user A. 3. The B2BUA then sends an INVITE to user B. If the B2BUA was a Proxy-Server, the INVITE would be exactly the same received from A with the addition of a second Via header stamped with the address of the Proxy. So for the Proxy behavior the INVITE message would be: INVITE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP proxy.alcatel.com:5060 Via: SIP/2.0/UDP here.com:5060 From: AUser To: BUser Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Contact: AUser Content-Type: application/sdp Content-Length: 147 v=0 o=UserA 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Instead of that, the controller would send to B an INVITE as if the controller was the originator of the call, but with the SDP of user A, for example: INVITE sip: [EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP proxy.alcatel.com:5060 From: Proxy To: BUser Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Contact: Proxy Content-Type: application/sdp Content-Length: 147 v=0 o=UserA 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 The effect of that manipulation will be that user A will talk to user B (will establish an RTP channel with user A), but signaling messages will go through the controller. 4. User B answers to the controller with the 200 OK message, that contains B's SDP (In this example the 180 Ringing has not been sent, but is a normal behavior in SIP calls). SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.alcatel.com:5060 From: Proxy To: BUser Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Contact: BUser <[EMAIL PROTECTED]> Content-Type: application/sdp Content-Length: 147 v=0 o= UserB 2890844527 2890844527 IN IP4 destination.com s=Session SDP c=IN IP4 110.111.112.113 t=0 0 m=audio 42345 RTP/AVP 0 a=rtpmap:0 PCMU/8000 5. The Controller sends an ACK message to user B. 6. The controller now sends the 200 OK message to user A, but including B's SDP data. SIP/2.0 200 OK Via: SIP/2.0/UDP here.com:5060 From: AUser To: BUser Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Contact: Proxy <[EMAIL PROTECTED]> Content-Type: application/sdp Content-Length: 147 v=0 o= UserB 2890844527 2890844527 IN IP4 destination.com s=Session SDP c=IN IP4 110.111.112.113 t=0 0 m=audio 42345 RTP/AVP 0 a=rtpmap:0 PCMU/8000 7. User A sends ACK message to the controller. 8. Now a RTP session is established between the end points defined in the SDP data. 9. When the credit expires the controller needs the Credit-Card number to recharge the Pre-Paid account. In order to collect the CC digits it is necessary to connect the caller to a dialog server. First of all, we need to put the called party on hold, this is achieved by sending a standard INVITE, with a special SDP [4], that contains single audio media line, with one codec, a random port number (but not zero), and a connection IP address of 0.0.0.0. 10. to 11 The called party answers with 200 OK and the controller sends an ACK message. 12. The controller sends an INVITE without SDP to the pre-paid caller. 13. The caller answers with the 200 OK that contains his SDP. This SDP (that has to be same SDP sent in the initial invite of point 1) will be used in an INVITE to the Media Server. 14. An INVITE is sent to the Media Server with the SDP coming from A in order to establish a RTP session between A and the MS. 15. The MS answers with the 200 OK message, that contains the MS's SDP. 16. The controller sends an ACK to the pre-paid user using the SDP returned from the MS. 17. to 18 The result is that now, the MS and the pre-paid caller have their media streams connected. The MS plays an announcement, and prompts the user to enter a Credit Card number. 19. After collecting the number, the digits are passed to the controller. 20. to 21 Upon reception of the digits, the controller can hung up the call to the MS. 22. After hanging up with the MS, the controller reconnects the user to the original called party. To do so, it is necessary to send an INVITE without SDP to B. 23. B can answer with his SDP. 24. The SDP of B is passed to A in a new INVITE. 25. A answers with his SDP. 26. A's SDP is passed to B in an ACK message. 27. An ACK message is sent to A in order to complete the RTP stream connection. 28. to 32 Now the call follows until of the users decides to finish the conversation. Now we see what a B2BUA means, it is a node that acts as a user Agent for both ends, so it is possible to control the call from the beginning to the end. That would be impossible with a Proxy or Redirect server. This call flow is based on draft "Third party call control in SIP," draft-rosenberg-sip-3pcc-02.txt Best regards Jose Antonio _____________________________________ Jose Antonio Navarro Garcia System Engineer IN Systems Design Team ALCATEL-NAD / CDC-BARCELONA Numancia, 46 1o, 08029 Barcelona, SPAIN e-mail: [EMAIL PROTECTED] Phone (+34) 93 495 23 52 Alcanet 2431 9352 Fax (+34) 93 495 24 07 _____________________________________ _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
