Iñaki,
AFAIK there is little in the way of standards for B2BUAs.
The problem with standardizing B2BUAs is that they can be used for many
different purposes. There is virtually nothing that you can say *in
general* that will apply to all B2BUAs beyond what 3261 says - that they
must satisfy all the rules for UAC and UAS.
To provide any meaningful standards/guidance, it is necessary to narrow
the scope. There are some instances of this:
- conference controllers: there are standards for a conference focus,
which is one sort of B2BUA.
- presence server: this is *loosely* a B2BUA connecting presence
publishers and presence subscribers.
- exploders: there are some standards for these, to do 1:many
message sending.
- mobility: some of the mobility stuff is really describing B2BUA
behavior.
What has not been specified much is SBC behavior. I guess that is really
what you are asking about. This isn't very much defined, and I suspect
many like it that way. SBC's are deployed for the purposes of
protecting, hiding, and fixing things. They tend to be highly
configurable as to what they do/don't propagate, etc. based on the whims
of the operator deploying them. It seems that often an operator will
*intentionally* want to break certain kinds of usage, and so may do
things that seem wrong. These things are often deployed in environments
where only certain kinds of usage are expected, and so breaking other
sorts of usage is not considered a problem. For instance, rewriting
various URIs can be done many ways if your only goal is to support
signaling based on "phone numbers".
But the net effect is that lots of "novel" usage that would work fine in
a system where there are only proxies between the UAC and UAS will *not*
work in networks containing SBCs. In each case it might eventually be
possible to *make* something new work by tweaking the SBCs to support
it. But it thus puts the SPs deploying those SBCs in the position of
being gatekeepers for what technology is usable.
Thanks,
Paul
Iñaki Baz Castillo wrote:
> Hi, the only reference to B2BUA concept I find in RFC 3261 is:
>
>
> Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a
> logical entity that receives a request and processes it as a
> user agent server (UAS). In order to determine how the request
> should be answered, it acts as a user agent client (UAC) and
> generates requests. Unlike a proxy server, it maintains dialog
> state and must participate in all requests sent on the dialogs
> it has established. Since it is a concatenation of a UAC and
> UAS, no explicit definitions are needed for its behavior.
>
> Well, the fact is that the real world uses B2BUA's and session border
> controllers and not just proxies to communicate with others. For
> example, Company_A and Company_B use SIP internally and the same SIP
> provider for PSTN calls. If an user in Company_A calls Company_B PSTN
> number the call will do:
>
> [EMAIL PROTECTED] B2BUA_A SIP_PROVIDER B2BUA_B [EMAIL PROTECTED]
> INVITE B_PSTN ----------> -----------> -----------> --------->
>
> So I really don't understand why all the SIP related RFC's imagine a
> happy world plenty of proxies that is (and will be) false forever.
> However, I don't find any documentation or references about the
> behaviour of a B2BUA. For example:
>
> - Is legal for a B2BUA to change completely the "From" in the second leg?:
>
> User1 B2BUA User2
> INVITE --->
> From: user_1
> INVITE --->
> From: bob
>
> - Should a B2BUA allow unknown headers from leg 1 to leg 2? or should
> it create a completely new request from scratch?
>
> - Can be problems if B2BUA copies in leg 2 the same "Call-Id" and "From_tag"?
>
>
> Thanks.
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
