Subject: [sipcore] Comments on draft-allen-dispatch-routing-out-of-dialog-request-00

From: [email-masked] (Dale R. Worley)
Date: Thu, 20 Mar 2014 21:59:50 -0400

To get back to the main item of business,
draft-allen-dispatch-routing-out-of-dialog-request-00:

In general, it would be useful to see examples of the failures that we
are trying to prevent, and examples of how the failures are prevented
by the new mechanism(s).  One reason is that failures often depend
fairly sensitively on the details of the intended call flow, so it's
difficult to know that one is addressing the same scenario that the
draft is.

Also, generally, it would be useful to perform some sort of
interoperability analysis on any new mechanisms to verify that they
don't impose a burden on entities that are outside of the
administrative domains that deploy a new mechanism.

   However, if REFER and SUBSCRIBE requests are sent outside the related
   existing dialog then the requests will not be routed by the
   manipulating B2BUA and thus will either [...] fail to arrive at the
   remote UA due to URI manipulations or fail at the remote UA because
   parameters in the request (e.g Target-Dialog, Replaces, Refer-To URI,
   etc) do not match the values at the remote UAS.

Of course, if either (1) the B2BUA must be included in any additional
dialog, or (2) the B2BUA changes the dialog identifiers, then the
B2BUA has to place one of its URIs as the Contact URI.  But if it does
so, it will then see any out-of-dialog requests, it can then adjust
the request appropriately before passing it along.

For instance, set up a call from A to B:

    A           EP              B
    ----------->
     INVITE sip:[email-masked]
     Call-Id: P
     Contact: sip:[email-masked]
                --------------->
                  INVITE sip:[email-masked]
                  Call-Id: Q
                  Contact: sip:[email-masked]
                <---------------
                  200 OK
                  Call-Id: Q
                  Contact: sip:[email-masked]
    <-----------
     200 OK
     Call-Id: P
     Contact: sip:[email-masked]

Now A sends an out-of-dialog REFER to B to cause it to transfer to C.
The REFER gets routed to EP because A uses the alias for B that EP
provided.  Additionally, EP translates the Target-Dialog header.  And
if EP desires to be in the new dialog that will be created, it can
translate the Refer-To header as well:

    ----------->
     REFER sip:[email-masked]
     Call-Id: R
     Contact: sip:[email-masked]
     Target-Dialog: P;local-tag=xxx;remote-tag=xxx
     Refer-To: sip:[email-masked]
                --------------->
                  REFER sip:[email-masked]
                  Call-Id: S
                  Contact: sip:[email-masked]
                  Target-Dialog: Q;local-tag=xxx;remote-tag=xxx
                  Refer-To: sip:[email-masked]

                <---------------
                  INVITE sip:[email-masked]
                  Call-Id: T
                  Contact: sip:[email-masked]
                -------------------------------------->
                  INVITE sip:[email-masked]
                  Call-Id: U
                  Contact: sip:[email-masked]

Returning to the draft:

   One way B2BUAs have have addressed this problem is by acting as two
   UAs back-to-back with the Contact URI being overwritten to be the URI
   of the B2BUA.  However this means that GRUU of the UA is overwritten
   by the B2BUA and the meaning of the Contact header field parameters
   becomes obscure.  Do the Contact header field parameters reflect the
   capabilities of the Contact address (i.e the B2BUA) or do they
   reflect the capabilities of the remote UA?  If they relect the
   capabilities of the B2BUA then the identfication of the capabilities
   of the remote UAS has been lost.  If they reflect the capabilities of
   the remote UA then they falsely identify that the B2BUA contact
   address has the capabilities of the remote UA.

(BTW, aren't Contact header field parameters described by RFC 3840
rather than RFC 6809 (which is your reference)?)

Assuming that the B2BUA is largely transparent to SIP requests and
SDP, then the capabilities of the B2BUA contact address *are the same*
as the capabilities of the remote UA.  If the remote UA advertises
"video" then the B2BUA contact also has video capabilities, etc.

Of course, if the B2BUA is somehow restricting or editing what passes
through, then it must properly edit the Contact parameters to remove
any capabilities that it is blocking.

Dale