Subject: [Sipping] b2bua and cc-transfer

From: "Xavier Marjou" <[email-masked]>
Date: Fri, 27 Apr 2007 18:14:54 +0200

I renamed the thread, as I think that this topic should be left out of
the draft-ietf-sipping-cc-transfer-07. Such a b2bua topic may affect
any SIP-related draft or RFC.

> So far we have never specified how B2BUAs should work.

Indeed: the draft-ietf-sipping-sbc-funcs looks at some b2buas in order
to investigate some missing functions in SIP. The
draft-marjou-sipping-b2bua is an individual draft, which means that it
is not an IETF working item. This later draft tries to catch best
practices about some type of B2BUA (the so-called transparent B2BUA
type) because many of them exist in the nature and because there is no
existing document on this topic. To sum-up, the situation with SIP and
B2BUA is very similar to the situation with SIP-RTP and NAT: NATs make
life harder for everybody and solutions to cope with them are not
easy.

> Since the B2BUA has decided to interfere in the call, it has the
> obligation to fix up the problems it has caused.
I agree with Paul.

For the following call-flows, a B2BUA may be located in different
places. I think it is important to look for which UA the B2BUA is
acting for. (cf 3 examples below for the following regular call-flow).
I would say that if someone deploys a B2BUA acting on the behalf of a
UA, he needs to make sure that the B2BUA is in the path of all SIP
flows for this UA and that the B2BUA will also correct the discrepancy
it introduces (I know this is heavy, but I do not see any other
solutions).

Cheers,
Xavier

transferor(b)             transfereree(a)               t-target(c)
|                                |                                |
|                                |                                |
| INV d1                         |                                |
|<-------------------------------|                                |
| INV d2                                                          |
|---------------------------------------------------------------->|
| REF dx Replaces:d2             |                                |
|------------------------------->|                                |
|                                |INV d3 Rpl:d2                   |
|                                |------------------------------->|

transferor(b)             transfereree(a)    b2bua_c    t-target(c)
|                                |               ||               |
|                                |               ||               |
| INV d1                         |               ||               |
|<-------------------------------|               ||               |
| INV d2                                         || INV d2'       |
|------------------------------------------------||-------------->|
| REF dx Replaces:d2             |                                |
|------------------------------->|                                |
|                                |INV d3 Rpl:d2  || INV d3'Rpl:d2'|
|                                |---------------||-------------->|

transferor(b)  b2bua_a    transfereree(a)    b2bua_a    t-target(c)
|               ||               |                                |
|               ||               |                                |
| INV d1'       || INV d1        |                                |
|<--------------||---------------|                                |
| INV d2                                                          |
|---------------------------------------------------------------->|
| REF dx  Rpl:d2                 |                                |
|------------------------------->|                                |
|                                |INV d3 Rpl:d2  || INV d3'Rpl:d2 |
|                                |---------------||-------------->|

transferor(b)  b2bua_b    transfereree(a)               t-target(c)
|               ||               |                                |
|               ||               |                                |
| INV d1'       || INV d1        |                                |
|<--------------||---------------|                                |
| INV d2        || INV d2'                                        |
|---------------||----------------------------------------------->|
| REF dx  Rpl:d2|| REF dx' Rpl:d2'                                |
|---------------||-------------->|                                |
|                                |INV d3 Rpl:d2'                  |
|                                |------------------------------->|

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Apr 2007 15:56:33 -0400

Xavier,

Thanks for reorganizing this. I agree with you that there have been 
*some* works on B2BUAs, and maybe it is time for some further work on 
topics such as this. I definitely think such work should be addressed as 
additional clarification on B2BUA behavior, rather than rules for 
everybody else so that they may work around what a B2BUA might do to them.

However I don't think it is possible to provide guidelines for this kind 
of behavior for B2BUAs in general, because the concept of B2BUA is too 
general. There can be many kinds of B2BUA, and not all should behave in 
the same way. For instance, an SBC and a conference focus are both 
B2BUAs. But the way they handle a REFER is likely to be quite different.

In most cases when people ask questions about B2BUAs they are assuming 
the B2BUA acts much like a proxy, as an SBC typically does. So it might 
be worthwhile to focus on that kind initially.

	Paul

---

From: "Ian Elz \(CV/ETL\)" <[email-masked]>
Date: Mon, 30 Apr 2007 15:40:28 +0200

Paul, Xavier,

I have been looking at this in a little more detail and have drawn a
couple of example flows with and without b2buas.

The appear to show the following requirements:

1. b2buas MUST map the Contact header

2. when sending a Replaces header the UA MUST use the contact of the
dialog being replaced as the URI. 

i.e. For a REFER where the Refer-To is used with a Replaces parameter
header the Refer-to URI must be the Contact for the dialog being
replaced; in an INVITE Replaces the Request URI must be the Contact of
the dialog being replaced.

This will ensure that each b2bua will receive the new request based upon
the contact information they have inserted. This then allows them to map
the other headers as required (this could apply to Target-Dialog as well
as Replaces).

In addition to the requirements above the b2bua must be able to
recognise the call with a Request URI and be able to look for the fields
which need to be mapped that that is an implementation detail not a
protocol one.

I have checked the transfer draft (draft-ietf-sipping-cc-transfer-07)
and it shows the Contact being used in the REFER-To and Subsequent
INVITE in the consultation transfer example. RFC 3891 does not show this
however as it only shows one example without all of the message details.

The examples I have used are as follows: 

A simple transfer example, no b2bua.

Figure 1

+-----+             +------+                   +-----+
|UA -A|             | UA-B |                   |UB-C |
+-----+             +------+                   +-----+
         INVITE B
  --------------------->
    200 OK Contact B'
  <---------------------
         ACK
  --------------------->
 dialog established (D1)
........................
                     INVITE C
  ------------------------------------------------>
                     200 OK Contact C'
  <-----------------------------------------------
                     ACK
  ------------------------------------------------>
               dialog established (D2)
...................................................

    REFER B Refer-to: C'
       Replaces D2
  --------------------->
        202
  <---------------------

                           INVITE C' Replaces D2
                         ------------------------->
                              200 OK
                         <-------------------------
                               ACK
                         ------------------------->
                            dialog established (D3)
                         ..........................

This should work OK.

If there is a B2BUA in the path of the dialog to be replaced and the
b2bua maps the contact as well as the Replaces value(s).

Figure 2

+-----+             +------+           +------+            +-----+
|UA -A|             | UA-B |           |b2bua |            |UB-C |
+-----+             +------+           +------+            +-----+
                                     maps: call-id
                                           Contact
         INVITE B
  --------------------->
     200 OK Contact B'
  <---------------------
         ACK
  --------------------->
 dialog established (D1)
........................
                     INVITE C                 INVITE C
  ---------------------------------------> ------------------>
                200 OK  Contact X'          200 OK  Contact C'
  <--------------------------------------- <------------------
                     ACK
  ---------------------------------------> ------------------>
               dialog established (D2)     dialog  (D3)
.......................................... ...................

     REFER B Refer-to: X'
       Replaces D2
  --------------------->
        202
  <---------------------

                         INVITE X' Replaces D2
                         --------------->
                                            INVITE C' Replaces D3
                                            ------------------>    
 
This will work OK as the Refer-To URI is the Contact and the B2BUA and
mapped the Contact.

If the Contact is not mapped at the B2BUA the following will occur.

Figure 3

+-----+             +------+           +------+            +-----+
|UA -A|             | UA-B |           |b2bua |            |UB-C |
+-----+             +------+           +------+            +-----+
                                     maps: call-id
           INVITE B
  --------------------->
     200 OK Contact B'
  <---------------------
         ACK
  --------------------->
 dialog established (D1)
........................
                     INVITE C
  ---------------------------------------> ------------------>
                200 OK  Contact C'          200 OK  Contact C'
  <--------------------------------------- <------------------
                     ACK
  ---------------------------------------> ------------------>
               dialog established (D2)     dialog  (D3)
.......................................... ...................

     REFER B Refer-to: C'
       Replaces D2
  --------------------->
        202
  <---------------------

                               INVITE C' Replaces D2
                         ------------------------------------>

This will fail as C will reject the INVITE as the dialog D2 cannot be
matched. To ensure that the sequence works there needs to be a mechanism
to ensure that the INVITE Replaces is passed to the B2BUA which was in
the original dialog so that the correct mapping occurs.

Ian Elz

Office: + 44 24 764 35256
gsm: +44 7801723668
[email-masked]

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 27 April 2007 20:57
To: Xavier Marjou
Cc: Ian Elz (CV/ETL); [email-masked]
Subject: Re: [Sipping] b2bua and cc-transfer

Xavier,

everybody else so that they may work around what a B2BUA might do to
them.

	Paul

> This list is for NEW development of the application of SIP Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments of core SIP
>