Sunday, October 26, 2008
Sunday, October 12, 2008
SIP Strict versus Loose Routing
The way how record routing works has evolved. Record routing according to RFC2543 rewrote the Request-URIii. That means the Request-URI always
contained URI of the next hop (which can be either next proxy server which inserted Record-Route header field or destination user agent). Because of that it was necessary to save the original Request-URI as the last Route header field. This approach is called strict routing.
Loose routing, as specified in RFC3261, works in a little bit different way. The Request-URI is no more overwritten, it always contains URI of the destination user agent. If there are any Route header field in a message, than the message is sent to the URI from the topmost Route header field. This is significant change--Request-URI doesn't necessarily contain URI to which the request will be sent. In fact, loose routing is very similar to IP source routing.
Because transit from strict routing to loose routing would break backwards compatibility and older user agents wouldn't work, it is necessary to make loose routing backwards compatible. The backwards compatibility unfortunately adds a lot of overhead and is often source of major problems.
contained URI of the next hop (which can be either next proxy server which inserted Record-Route header field or destination user agent). Because of that it was necessary to save the original Request-URI as the last Route header field. This approach is called strict routing.
Loose routing, as specified in RFC3261, works in a little bit different way. The Request-URI is no more overwritten, it always contains URI of the destination user agent. If there are any Route header field in a message, than the message is sent to the URI from the topmost Route header field. This is significant change--Request-URI doesn't necessarily contain URI to which the request will be sent. In fact, loose routing is very similar to IP source routing.
Because transit from strict routing to loose routing would break backwards compatibility and older user agents wouldn't work, it is necessary to make loose routing backwards compatible. The backwards compatibility unfortunately adds a lot of overhead and is often source of major problems.
Saturday, October 11, 2008
SIP layered protocol
(1)The lowest layer of SIP is its syntax and encoding. Its encoding is specified using an augmented Backus-Naur Form grammar (BNF).
(2)The second layer is the transport layer.
(3)The third layer is the transaction layer.
(4)The layer above the transaction layer is called the transaction user(TU). Each of the SIP entities, except the stateless proxy, is a transaction user.
(2)The second layer is the transport layer.
(3)The third layer is the transaction layer.
(4)The layer above the transaction layer is called the transaction user(TU). Each of the SIP entities, except the stateless proxy, is a transaction user.
Friday, October 10, 2008
SIP Record-Route
In some cases, it may be useful for proxies in the SIP signaling path to see all the messaging between the endpoints for the duration of the session.
For example, if the biloxi.com proxy server wished to remain in the SIP messaging path beyond the initial INVITE, it would add to the INVITE a required routing header field known as Record-Route that contained a URI resolving to the hostname or IP address of the proxy.
This capability is frequently used for proxies that are providing mid-call features.
A route set is a collection of ordered SIP or SIPS URI which represent a list of proxies that must be traversed when sending a particular request. A route set can be learned, through headers like Record-Route, or it can be configured.
For example, if the biloxi.com proxy server wished to remain in the SIP messaging path beyond the initial INVITE, it would add to the INVITE a required routing header field known as Record-Route that contained a URI resolving to the hostname or IP address of the proxy.
This capability is frequently used for proxies that are providing mid-call features.
A route set is a collection of ordered SIP or SIPS URI which represent a list of proxies that must be traversed when sending a particular request. A route set can be learned, through headers like Record-Route, or it can be configured.
SIP Via vs Contact
While the Via header field tells other elements where to send the response, the Contact header field tells other elements where to send future requests.
SIP dialog
http://tools.ietf.org/rfc/rfc3261.txt
A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identified by a call identifier, local tag, and a remote tag. A dialog was formerly known as a call leg in RFC 2543.
The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship between caller and callee and is referred to as a dialog.
A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identified by a call identifier, local tag, and a remote tag. A dialog was formerly known as a call leg in RFC 2543.
The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship between caller and callee and is referred to as a dialog.
Subscribe to:
Posts (Atom)