Hi, Jose, thanx for the call flow, I will have a look at the draft too.
Is the following example the exception or will it become the rule ? The presence event package (draft-rosenberg-impp-presence-01) gives an example where it is a requirement to switch logical behavior on a dialog by dialog basis. For one dialog the software is a B2BUA, for another the software behaves like a proxy. Implementing a 'stand alone' B2BUA seems much simpler than implementing a flexible combined B2BUA - Proxy - Redirect server - Registrar thanx, Francois Jose Antonio Navarro Garcia wrote: > 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 -- Francois Lessing Trillium Digital Systems, an Intel Company Los Angeles, USA Tel: +1 310 481 5937 Fax: +1 310 481 5558 _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
