[cc: changed to serusers, which is publicly archived]
There is no B2BUA support in SER. You can try to use some existing B2BUA implementation. You can use SER along with B2BUA too -- they interact using SIP. You just need to set SIP routing accordingly to your scenario.
You should be perhaps warned of some side-effect of use of the B2BUA technology. The root reason is B2BUAs break the end-to-end model, in which intelligence lives in end-devices. With B2BUA, you put a fair amount of work on a network entity. That breaks e2e security, degrades scalability and robustness -- B2BUA's failure affect all existing calls.
-Jiri
At 01:18 PM 12/4/2002, Igor Vasiliev wrote:
-- Jiri Kuthan http://iptel.org/~jiri/
At 02:21 PM 12/4/2002, Igor Vasiliev wrote:
Requests are redirected in SER using sl_send_reply with a 3xx code in it. That has nothing to do with B2BUAs, though.
You can proxy requests too -- again, how you route them depends on what you want to accomplish. For example, you can look at URIs and route all requests with nummerical usernames to a B2BUA, whereas everything else will be routed using a user location database. There are really no limits on what your routing policy may be.
From SER to B2BUA?
Please give me an example of their interaction.
http://www.iptel.org/ietf/callprocessing/apps/draft-rosenberg-sipping-app-in... and http://www.iptel.org/ietf/callprocessing/apps/draft-rosenberg-sip-app-compon... give examples of server interactions.
Could I use B2BUA without SER(and without any SIP proxy)?
Yes. There is BTW many other things which you can do without any SIP proxy -- skiing, playing chess, having phone conversation, and many more.
-Jiri
Does it mean that some request(e.g. depends on caller name) I can redirect to B2BUA?
Is such scenario correct? caller --->SER --->B2BUA ----> callee
:) I just mean, could caller send INVITE directly to B2BUA?
Regards Igor Vasiliev
At 03:57 PM 12/4/2002, Igor Vasiliev wrote:
Does it mean that some request(e.g. depends on caller name) I can redirect to B2BUA?
Yes. You can proxy SIP servers in long chains, in which each element adds some value. A proxy server in the middle of a chain can decide what the next hop for a request would be. For example, you can make such a SIP-routing decison with SER:
# prefix for germany -- route over b2bua.germany.bar if (uri="^sip:+49[0-9]*@foo.bar) t_relay_to("b2bua.germany.bar", "5060"); # anything else is routed using userloc database else { if (!lookup("location")) { sl_send_reply("404", "Not Fond"); } else { # forward to the destination in UsrLoc database t_relay(); } }
SER is then acting as a "switch", switching by request URI.
Is such scenario correct? caller --->SER --->B2BUA ----> callee
Such a scenario can be correct to. How you construct the chains depends mainly on how you want to concatenate values added by each element in the path. One element can add authentication, another one user location, yet another firewall control, etc... Alternative, all the functionality can be merged in a single server. That is the freedom of choice when building SIP networks.
:)
Yes -- a B2BUA could be certainly built in such a way, which delivers all features a proxy server does.
-Jiri