Trick question: all three are can use forking equally well because each requires that a single SIP INVITE request be sent to each of the prospective session members. It may be that mesh networking causes an excessive number of invite requests, or that bridging provides the most efficient use of invite requests, but those are not properties of SIP forking itself, but in how it's used.
The answers, in no particular order and approximately verbatim:
The three ways of providing multiparty sessions are 1. full mesh in this you can send to max 3 points at a time. 2. In this server receives and sends msgs to each by making copies. 3. In this you can send and receive msg to and from endpoints. Forking is being able to send msg to two or more points at once or serially. I feel second method will make best use of SIP's forking capability is it can replicate the msg any number of times and send to all nodes on the network (multicast) or to a chosen few.
There are three ways: 1. Connecting to each endpoint to all parties. 2. Connecting through a central server. 3. Connection in a tree-like graph approach (broadcast). Connecting by method one is inefficient for all but the smallest multi-party session. It's harder to implement method two w/o forking because forking helps reduce the addressing challenge (by using virtual addresses). Broadcasting is simply less of a challenge, even through geometrically it is a perfect fit.
Use of SIP's forking capabilities, gatekeeper sends multiple request to end user required in session and keep sending invitation until get response from end users agent. Once user agent receives ok signal that it sent ACK signals and establish session. Forking capabilities of SIPs also useful providing more features like, call waiting, call forwarding, etc.
Networks can make the best use of SIP's forking capabilities. Other types like full mesh etc do not make the best use.
SIP provides anycasting-like routing by allowing a URI to map to several possible URLs. When asked to resolve a URI, SIP can use extra information - such as the time of day the request was made, or the source of the request - to help it determine which of the corresponding URLs to return.
The answers, in no particular order and approximately verbatim:
SIP messages have domain names of the destination. These domain names maintain the list and from here location of the end client can be reached. For example: abc@monmouth.edu SIP works in similar way as e-mail. SIP messages also have a via field in their headers. This way they provide an anycasting-like routing service.
The SIP gateways and gatekeepers are responsible for establishing a session between two nodes. The gateway domain is just like the Internet domain. For e.g., if you want to send an e-mail to someone you have a unique e-mail id. The routers hop by hop find the domain of use. Anycast is like you want to find out a particular restaurant in a particular area. Consider an example. a@alice.com wants to send an e-mail to Bob in macrosoft.com domain at b.macrosoft.com. So the e-mail first comes to macrosoft.com then it finds b.macrosoft.com i.e., you don't need to multi-cast msg to everyone in macrosoft domain.
SIP provides anycasting through proxy and redirection servers. Since SIP uses one layer of abstraction to describe a user, flexibility is achieved where caller can switch locations during a one-on-one session. Callees and callers have banks of addresses that are each tested by priority when a connection is made. This “virtual registry” is used by both proxy + redirection servers. Proxy servers contain addresses that are sequentially checked. Redirection servers contain rerouting info. Forking is used in anycasting. The same flexibility with virtual addressing allows multiple end points in anycasting.
Using proxy in session can provide an anycasting like routing service. Proxy also talk to each other and passes information about available bandwidth at different through different router/gateway. As user moves from location to location, it may change proxy based on available bandwidth also proxy help to navigate through busy domain, etc.
| This page last modified on 24 June 2008. |
|