Subject: [sipcore] B2BUAs and Contact header field parameters

From: [email-masked] (Dale R. Worley)
Date: Thu, 3 Apr 2014 16:55:40 -0400

> From: Andrew Allen <[email-masked]>
> 
> In addition as I state in my draft modifying the Contact header
> field means either the media feature tags of the remote UA are lost
> or the B2BUA is saying if you send a request to this address
> (including potentially after this session has ended) you can expect
> that this feature is supported.
> 
> Having B2BUAs only include feature tags they understand to my view
> means no innovation and no new services. B2BUAs have then become the
> switches of old needing all to be updated or reconfigured to support
> any new services.

> From draft-allen-dispatch-routing-out-of-dialog-request-00:

   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
   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.

Looking again at
draft-allen-dispatch-routing-out-of-dialog-request-00, I don't think
you explicitly describe a mechanism to fix this problem.  I believe
that the implied solution is that in the new dialog, the contact URI
remains the same as that of the far end of the original dialog, and
the media feature tags of the contact URI are maintained, that is,
they describe the far end of the original dialog.

It seems to me that the "natural" way to avoid this problem is that
when a B2BUA passes through a dialog, it needs to provide as its
contact URI in the new dialog a URI which is connected in some manner
with the contact URI of the far end of the original dialog.  That is,
different outgoing dialogs are going to need different contact URIs,
precisely so that the B2BUA can forward incoming OOD requests to the
correct destination.  I've been calling these URIs "contact aliases",
and I think that is what Hadriel means by "global contacts" (when they
aren't also marked as GRUUs).

Within this context, the media feature tags on different contact URIs
can be different (since the other entities should not be confusing the
media future tags of different contact URIs).

Which media feature tags the B2BUA passes through from the original
request should depend on its policies and the support that it provides
for the various media features.  That is, the media feature tags on
the outgoing request describe the media feature tags of the original
far end *as they are accessible through the B2BUA*.

However, I've not had to deal with this problem in practice.  Are
there impediments to this "natural" solution?  Do you have specific
examples of problems that need to be avoided?

Dale