Subject: [Sipping] Comment on draft-ietf-sipping-cc-transfer-07

From: "Ian Elz \(CV/ETL\)" <[email-masked]>
Date: Thu, 26 Apr 2007 16:07:59 +0200

In section 7 of the draft (draft-ietf-sipping-cc-transfer-07) you
discuss transfer with a consultative call. In this discussion you refer
to the use of the Replaces header as defined in RFC3891.

You do not mention however that for the purpose of this draft the
original dialog between the transferor and the  transfer target must not
have an B2BUA in the message path as the use of the Replaces header in
the later INVITE between the transfer target and transferee as any B2BUA
may have resulted one or more components of the Replaces header
(call-id, from-tag, to-tag) may have been modified as shown below.

+------------+               +---------+               +-----------+
|            |               |         |               |           |
| transferor |-------------->| B2BUA   |-------------->| transfer  |
|            |               |         |               | target    |
+------------+               +---------+               +-----------+
Call-id = 1234                call-id                  Call-id = 4321
From-tag = ab12               mapped                   From-tag = ab12
To-tag = cd34                                          To-tag = cd34

Thus the Replaces header sent from the transferor to the transferee in
the REFER request Refer-to header would be Replaces
(call-id=1234,from-tag=ab12,to-tag=cd34). This would not be valid if
received in an INVITE at the transfer target and the INVITE would be
rejected as the Replaces header does not match an existing dialog.

Thus when mentioning the INVITE with the Replaces header you need to
explicitly state that the UAC generating the INVITE must know that there
was no b2bua in the original call or that no impacted header was mapped.

OR

Reference should be made to the appropriate routing algorithm which
indicates how routing should be performed when a parameter from another
dialog is used as part of the initiation of a new dialog.

Unfortunately SIP does not provide any information as to whether any
header has been mapped in a dialog or what node may have mapped any
header(s). As a result the first option is not practical as it would
require every user agent to know the topology of the entire network and
the message path of a dialog to understand whether the Replaces header
was valid.

As the other drafts currently being considered by the sipping WG:
draft-ietf-sipping-sbc-funcs-03 & draft-marjou-sipping-b2bua-00; both
reference b2bua capability and why it is used within the network
consideration must be given to the correct routing of Requests which use
a value obtained from one dialog as part of a subsequent dialog.

Ian Elz

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

_______________________________________________
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: Thu, 26 Apr 2007 11:47:15 -0400

inline

> (call-id, from-tag, to-tag) may have been modified as shown below.

In this case, the REFER would in fact be sent to the B2BUA, since that 
is remote contact of the dialog that the transferor has. The B2BUA will 
have to relay the REFER on to the transfer target. Since the B2BUA has 
decided to interfere in the call, it has the obligation to fix up the 
problems it has caused. In this case it has the responsibility to fix up 
the Replaces header.

> dialog is used as part of the initiation of a new dialog.

So far we have never specified how B2BUAs should work.

---

From: "Ian Elz \(CV/ETL\)" <[email-masked]>
Date: Fri, 27 Apr 2007 11:20:01 +0200

Paul,

Comments inline marked with [Ian Elz]

Ian Elz

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 26 April 2007 16:47
To: Ian Elz (CV/ETL)
Cc: [email-masked]
Subject: Re: [Sipping] Comment on draft-ietf-sipping-cc-transfer-07

inline

Ian Elz (CV/ETL) wrote:
> discuss transfer with a consultative call. In this discussion you 
> refer to the use of the Replaces header as defined in RFC3891.
> 
> original dialog between the transferor and the  transfer target must 
> not have an B2BUA in the message path as the use of the Replaces 
> header in the later INVITE between the transfer target and transferee 
> as any B2BUA may have resulted one or more components of the Replaces 
> header (call-id, from-tag, to-tag) may have been modified as shown
below.

[Ian Elz] When the REFER is sent it will use the same B2BUA if the REFER
is used inside the dialog for the original INVITE. If the REFER is sent
in a separate dialog then the same B2BUAs may not be used. Even if the
REFER modifies the Replaces header parameter in the Refer-To then in the
subsequent INVITE the Replaces header must be correctly mapped back. The
correction of any mapping of the Replaces header can only be performed
in the path of the REFER, i.e. between the transferor and the
transferee. If there are B2BUAs in the path of the consultative call
between the transfer target and the transferor then there is nothing the
handling of the REFER can do with this leg of the call. Due to the
specification of the Replaces header in RFC3891 you cannot send the
Replaces information in the Refer-To if there are any B2BUAs in the path
of the REFER the Replaces applies to the dialog on the transfer target
side of the transferor. Passing the Replaces information on the
transferee side means that the INVITE Replaces may have to be passed
back via the B2BUAs on the transferee to transferor dialog where the
Replaces would not match an existing dialog and the INVITE would be
rejected. The INVITE Replaces header specifically needs mapping on the
dialog where the REFER is not applicable.

> explicitly state that the UAC generating the INVITE must know that 
> there was no b2bua in the original call or that no impacted header was
mapped.
> indicates how routing should be performed when a parameter from 
> another dialog is used as part of the initiation of a new dialog.

[Ian Elz] I understand that B2BUA functionality has not been specified
but from the draft from Marjou and SBC there are some headers which are
mapped by B2BUAs for specific reasons: privacy, topology hiding etc. In
the Transfer service the specific example is the Replaces header which
is why I used this as an example in my original comment. It is not only
the B2BUA functionality which needs to be specified and as long as the
B2BUA conforms to the basic UAC/UAS rules then much of this
functionality can actually be left to the specific implementation. The
key issue is the UA functionality in networks where B2BUAs exist. Where
there may be a B2BUA in the network and a new Request uses a header
value from a previous dialog then there is always the possibility that
the 'inherited' value has been mapped by a B2BUA in the previous dialog.
Key headers which I have identified are Replaces (call-id, from-tag,
to-tag), Target-Dialog (call-id, from-tag, to-tag), Contact (where the
contact URI is used as the Request URI in a new dialog or as a Refer-To
URI in a REFER). There are probably others but when any of these headers
is used then the new Request must follow the same B2BUA path as the
original dialog to ensure that the new dialog is associated with the
previous dialog and the headers are mapped correctly.

> require every user agent to know the topology of the entire network 
> and the message path of a dialog to understand whether the Replaces 
> header was valid.
> 
> consideration must be given to the correct routing of Requests which 
> use a value obtained from one dialog as part of a subsequent dialog.
> 
> Ian Elz
> 
> 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 11:48:28 -0400

inline

Ian Elz (CV/ETL) wrote:
> in a separate dialog then the same B2BUAs may not be used.

If the refer is intended for the transfer target then the transferor has 
only a few options of where to send it. Note that the transferor doesn't 
in general know there is a B2BUA in the call. Instead, it thinks it has 
a dialog with the transfer target. Practically speaking, the B2BUA *is* 
the transfer target.

If the refer is not sent within the existing dialog, then it must be 
addressed so that it will reach the transfer target. 3261 says that the 
remote contact must be globally routable. So in general the right thing 
to do is to send the refer out of dialog to the remote contact. That 
would be the contact address provided by the B2BUA. If the B2BUA didn't 
use a globally unique routable contact then there may be problems. In 
regular cases, without B2BUAs, we know that UAs often don't have 
globally routable contacts and so this strategy doesn't work. That is 
why GRUU was invented.

In lieu of gruu support, various work-arounds may be tried. The trouble 
is that none of them is entirely reliable. A common one is to send the 
out of dialog request to the To address of the original call. If that 
were tried here, its hard to say what would happen. Probably nothing good.

The above argues for the support of GRUU, for the B2BUA to use a contact 
with gruu properties, and for the transferor to send the out of dialog 
refer to the remote contact.

If you can't do that, then your best bet is to send the refer in-dialog.

The absolutely worst thing you could possibly do would be to have the 
transferor take some special action based on the assumption that there 
is a B2BUA in the call.

	Paul

> Even if the