A new specification that promises to change communication across the web yet it lacks a signaling protocol.
SIP benefit 1
Services on offers - Offers voicemail, video, call conferencing, IM, and SMS all for a small cost and sometimes NO cost to user.
SIP benefit 2
Mobility - Presence based services that allow users to control what is seen about them and control over where calls are routed based on their presence status
Price - drastically reduce LD costs. Calls are carried across the Internet or other networks for most of the journey.
Flexibility - in adding to or removing trunks as you need them without hardware changes
Features - help facilitate multiple forms of communication such as video and IM
What is SIP?
Session Initiation Protocol
Signalling protocol used for controlling multi-media sessions
Can setup, modify, and tear down sessions
Helps establish user presence and locate users when using mobile and desktop
IETF RFC 3261
SIP is an application layer control protocol
Can establish, modify, and terminate multimedia sessions (conferences) such as Internet telephony calls
Can invite participants to already existing sessions, such as multicast conferences.
Media can be added to and removed from an existing session
SIP transparently supports name mapping and redirection services - users can maintain a single externally visible identifier regardless of these network location
Request for Comments
- idea for the Internet
- crate a draft doc
- submit it to Internet Engineering Task Force
- proposed standard
- draft standard
- Internet standard
SIP based on HTTP
Is a textual based protocol, written in ASCII format
It is based on the client-server model
requests from a client device are sent to a server device which then responds to the client
This request invokes a method on the server which normally makes something happen
Are created by the Internet Engineering Steering Group to work on limited set of tasks described in its charter and will normally be closed one the work described in its charter is finished.
SIP on the OSI chart
SIP lives at the application layer above its transport protocol UDP that runs over IP. SIP carries SDP messages in its body to help describe the audio and media components of a session.
RTP (real time protocol) deliver the media after DNS has found out where the destination is
SIP User Agents
A UAC is an application or device that acts on behalf of a user. The UAC will initiate a call and the UAS will receive the call.
UAC are also UAS so that they can initiate and receive calls.
SIP HEADER - 200 Response
Via headers are inserted by servers into requests to detect loops and to allow responses to find their way back to the client 'VIA' the server.
Simple Call Session Setup
The user dial a destination number, the UAC will send an INVITE message to the destination device. If the destination device answers the call it also returns a '200 OK' message to say that this has happened. The caller will then acknowledge this event. Voice, video, or whatever can pass between the two devices.
When one device hangs up, it sends a 'BYE" message which is responded to with a '200 OK' message.
SIP System Architecture
User Agents - SIP VoIP phone, wireless PDA, softphone
SIP Proxy - assist in the Discovery and Setup of the sessions between the UA
SIP Registrar - UA use the Register their current location on a Network
SIP Location Server - contains the registered location info. Usually the Registrar and Location services run on the same server.
SIP gateway - translates Signaling and probably media as well so that SIP devices can communicate with legacy devices.
What is the 1st SIP message of Method sent out when a SIP US wants to setup a call with another SIP device?
is a string that identifies some kind of resources
URI is an identifier, an email address but it does not tell you how to move emails to this address
General form is User@Host
User = name, telephone number
Host = Domain name, IP address
Main types of URI
Service, Device, and User
- With a Service, the URI could point to a conferencing unit that SIP users can reference and join
- With a Device, the URI represents a single device or app
- With a User, the URI can be static. This URI or AOR - address of record will map to as many other SIP URIs as the user wants or needs
is a form of a URI that not only identifies a resource but tells you how to reach the resource
URL tells you the address of the web server and that a HTTP request should be sent to retrieve a web page
Goal of SIP addressing
To provide all users with a single URI, which when used in conjunction with DNS will reveal all the other info relating to user or agent, such as email address, voice, data, video capabilities
SIP device start up
When a SIP device starts up it sends its current address and location details to its Registrar server. This server then updates the users location in the location server.
Once the client's details are updated, they can be contacted using their published address which resolves to their current IP address.
When a SIP UA registers it ell the Registrar about its feature capabilities. This is useful info for SIP devices wanting to make contact with the UA
whole list of features
SIP Proxy Server
forwards requests to the next server after working out which is the next server to talk to
It will interpret a request message and if necessary rewrite the message before forwarding it.
It can issue both requests and responses so it is in effect a SIP client and a server.
It can fork the incoming request to multiple locations if someone has multiple location registrations
remembers incoming requests and outgoing requests
This keeps 'state' info for the entire duration of a SIP session. This is useful for implementing extra services such as call forward on busy or no answer.
forgets all information once an outgoing request is generated.
This keeps a no 'state informations and as soon as it has helped out a UA it forgets everything about the transaction.
Why do you need a Proxy Server?
sometimes only by contacting a proxy server SIP signalling actually be allowed to leave a corporate network
may also be acting as the corporate firewall
UA proxy details
a UA gets its proxy details either by manual configuration or via DHCP
This keeps all state info on all transactions that are pending. Once a session is established, the proxy forgets the state info.
A 'Stateful Proxy' forgets incoming and outgoing SIP requests once they have been processed
DHCP and SIP
can send proxy details in either the DNS or IP address format in DHCP option 120
DHCP option 120
The option is used to provide SIP server IP address or FQDN to SIP client
SIP Proxy - Trapezoid model
100 trying - progress of the call setup
180 ringing - when the destination starts ringing
200 Ok - message is sent on device pick-up which is relayed and followed by an acknowledgement.
BYE - when one device hangs up
SIP server in proxy mode
In proxy mode, all SIP messaging goes via the Proxy
SIP server in Proxy Redirect Mode
Once the proxy finds the 'called to' location from the location server, it sends the contact details to the calling device. The INVITE is then reissued with my specific contact details 'directly' to the called softphone.
The proxy is doing less work with this setup.
What is the SIP 'Response code' that signifies 'Ringing'?
A location server is used by a SIP proxy servor or redirect server to obtain information about a called party's possible location(s)
Will have a database to hold location info for the SIP UA and this is kept up to date via the Registrar service this is processing Register and Re-Register messages from clients. The SIP proxy will then use the Location service to help find the current location details of the destination SIP URI in a SIP INVITE mesage
Location Server - components
Location Server - Information sources
Local database provides as part of the location server product
DNS - it will store the location details of other servers in other domains that the location server may need to contact
Microsoft Active directory that uses LDAP protocol
1. Get config via TFTP file on boot up
2. Get config via config server as defined in RFC 6011
3. Manual configuration.
SIP basic elements that all clients need
SIP registration server hostname /IP
DNS server address if using DNS names for SIP registration
SIP port number
User account / password
SIP proxy hostname or IP address to direct calls
SIP Messages are normally requests and responses. The request from client to server, the response back to the client from the server.
Request and responses use different headers in the SIP message to describe the detail of the communication between agents
Authorization and encryption is use to make SIP more secure
Basic SIP Request methods
initiates a call by inviting a user to particle in a session. INVITEs can also be used for session modification
ACKnowledgement is used as a respne to a 200 OK response that was the result of an initial INVITE request. A session should now be in place. ACK is only used with INVITE and reINVITES requests
is used to indicate termination of a call or session
is used to cancel a pending request
is used to register the user agent by temporarily binding the Agent URI to an AOR (address of record) so the SIP server knows the location of the user agent
is used to find out what a server or UA media capabilites are but does not set up a session
is used for communicating mid-session signaling info
is a Provisional ACK and is only used in response to a 1XX 'style' response message.
IF an initial INVITE had no SDP body, then after a 1xx 'style' response the PRACK can include the relevant SDP detail.
Each provisonal response (eg. from a UAS, a 183 session in progress) is given a seq number, carried in the RSeq header field in the response
The PRACK message from the UAC contain an RAck header field, which indicates the seq num of the provisional response that is being ack.
Session Description Protocol (SDP)
describes the media of a session. It is important to realize that it doesn’t negotiate the media.
SIP deals with establishing, modifying, and tearing down sessions, SDP is solely concerned with the media within those sessions.
SDP is used when one party tells the other party, “here are all the media types I can support — pick one and use it.”
method is used to req notification of an event or set of events at a later time
eg. requesting a notification when another persons 'IM Presence' details change.
is used to notify that an event which was requested by an earlier SUBSCRIBE method has occurred.
Used by a SIP server to NOTIFY a client of an event. eg. a VM has been left for the client.
is used to Transfer calls and also to contact external resources
allows a client to update parameters of a session such as set of media streams and their codecs, but has no impact on state of dialog
method can carry a SOAP message as its payload
Simple Object Access Protocol is a lightweight protocol that defines a framework for encoding request and response message in XML
Best Effort NOTIFY
is used by MS Lync, LCS, and Skype for Business comm products.
Unlike a NOTIFY method, BENOTIFY doesn't require a response as apps may not need a NOTIFY response to a certain request thus reducing SIP signaling traffic, which is important for deployments with large number of clients on server
method is an ext. to SIP that allows transfer of IM where requests will normally carry the IM content in the request body.
SIP Response Codes
SIP response codes
are made up of 3 digits. The first digit in the code indicates the class of the response and the other two digits are used to represent a reason or 'reason phrase'.
style response is an informational response. The request was received and is still being processed.
style response is a sucess respone. The action was received, understood and accepted
style response is a redirection response. Further action needs to be taken in order to complete the request
style response is a 'client error' response. For some reason, such as bad syntax, the request cannot be fulfilled at this server.
style response is a 'server error' response. For some reason, the server cannot fulfill a valid request.
style response is a 'global error' response. The request being made is invalid at any server.
Which 'Method' is an extension to SIP that allows the transfer of Instant Messages?
SIP Header - INVITE
The header indicates the method type. eg INVITE, the SIP URI of the target UA and SIP version 2.0
Via shows the layer 4 transport protocol to use, eg UDP, IP address, and port where the respnse is to be sent back to. eg. senders gateway 220.127.116.11:2051
branch - parameter is used to uniquely identify this transaction and should not change
From shows the details of the Caller and Callers SIP URI, it's the callers Caller ID
To shows the details of the Called party
Call-Id is a globally unique ID for this particular dialog. It will be the same for all request and response transactions within this dialog.
CSeq is used to indentify and order transactions. eg. sequence 1 and method INVITE. Each of the parties in a call will maintain their own Cseq numbers and these numbers and these numbers increment for every successive command in a call. 70 is the recommended default value.
Max-Forwards field is used to limit the number of proxies or gateways that can forward the request to the next downstream server. eg. 70 will be decremented by each server that forwards the request.
Contact shows the SIP URI that can be used to contact this agent with subsequent requests
User-Agent indicates telephone modem, firmware version, MAC address
If the Accept field is not present the receiving server should assume application/sdp
The Allow field lists the set of methods supported by the UA generating the message.
Allow-Events details some basic events that the UA supports. eg. Talk, Put on Hold, and Refer (or Transfer) a call or session.
Session-Expires header conveys the session interval for a SIP call. It is placed in an INVITE request and is allowed in any 2xx response to an INVITE eg. 3600 seconds or 60 mins.
Content-Type describes the body content, which is app and the type which is sdp
Content Length is the length of the SDP body in bytes
SIP HEADER - 200 Response
Via headers are inserted by servers into requests to detect loops and to allow responses to find their way back to the client VIA the server
Call-info field provides additional info about the called party.
Record-route details are inserted by the proxy to 'force' future requests in this dialog to be routed through the proxy. eg 18.104.22.168
Supported and Require Headers
Supported allows a client to inform a server what features it supports. eg. timer, 100rel
Require - what the server requires the client to support. eg. timer
Session timers allows the refreshing of a SIP session periodically using SIP re-INVITES or UPDATES messages.
'REFRESH' allows user agents and proxies to keep a session alive and also allows the status of the session to be determined and released if not active. This can be useful when a call has been ended but a BYE not been sent. eg. a lost connection
SE - session expires
RFC 4028 defines session timers
Session-Expires is the upper level of time for the session
Min-SE is the minimum a server will actually allow
If a Refresh is not received before the timer expires, the session is ended.
The refresher in charge of sending the updates can be the server or client and is shown in the 200OK that completes the session setup
Refreshes are sent halfway through the session interval
The recommended Session-Expires value in RFC4028 is 1800 seconds or 30 minutes.
When a SIP device responds to a request the response can be
Final - 200 OK
Decline - 603 - a final result to a transaction which is acknowledged
Provisional - such as 180 Ringing - are not acknowledged by default but desirable especially when communicating with the PSTN
SIP PRACK method provides reliability and to show support for this feature a SIP device will add the 100rel parameter to the supported header
If the recipient does not support 100rel it must reject with a 420 resonse and state in the header that 100rel is unsupported
PRACK can be used with all 1xx style responsed except 100 trying.
Responses are acknowledged to ensure better reliability for a transaction
Short form /compact headers
What does code 180 mean?
A '200' code indicates a successful event
What SIP Method will the SIP soft phone need to send to the ITSP in order to be ready to make calls
SDP stands for Session Description Protocol and is detailed in the RFC 4566
It is used to handle the session negotiation process with a SIP transaction
An SDP packet is often carried as the message body of a SIP request
Part of a SIP INVITE request, an SDP offer is made detailing a number of characteristics that define the proposed media session such as codec type, contact information, and ports to be used.
The response to this acknowledges acceptance, offers alternative session parameters, or declines the proposed session with no alternatives offered.
MIME (multipurpose internet mail extensions) is used to define what is in the body of a SIP message
The entry,Content-Type: application/sdp defines that an agent would need to support the application layer protocol SDP in order to setup a session.
SDP component in a SIP message
SIP header generally describes who is making the call and where the destination agent is.
The SDP section lists all the detail required in order to setup a successful media connection such as a voice or video media stream.
The Called agent can decide to accept or reject the session. To reject the session, the called agent responds with a port setting of 0, to accept it responds with it's own SDP details in a SIP 200 Response. After this media can be exchanged.
Sip INVITE version number of 0
o or origin entry, displays the username of 'root' and session identifiers along with the IP v4 IP address
s or session name field allows for a call description
c is connection information for calling party to return all messages to.
t Timer values (start and stop) are usually set at 0 and 0 allowing the calls to have no timer boundaries.
m for media shows the media type, eg AUDIO.
Port 60106 - the port the UA can receive audio on
RTP/AVP - the Real-time protocol / Audio Video profile codecs that this UA is offering the destination device to choose to use.
One of these is Codecs, 18, is G729 **a=rtpmap:18 g729/8000
SDP Detail - reply
reply shows the same version of 0
An owner 'username' of root, the sessions IDs along with the source IP address
description of 'SIP Call'
optional piece of info of the contact email addres of agent
E.164 number of this agent, the contact details, time values and the media type that this device has chosen from the list offered by the caller, eg 18 -- G729
Multiple 'm' lines
multiple 'm' lines - The SDP INVITE element shows the m=auio element for the voice including port info and the m=video element details the port and other requirements for the video. When the calling received the 200 OK to both elements the voice and video channels are set up.
Changing session parameters
A session can be modified after it is started by changing the session parameters through SDP with methods such as re-INVITE or UPDATE
Adding a new stream such as video to a voice conversation
Removing a stream
Changing codecs from uncompressed G.711 to compressed G.729
Changing address info
Putting a call on hold
Set up a call conference
SDP Example - Put a call on Hold
The re-invite message includes the hold command
SDP - Call hold trace
To put a call on hold, the holding device sends connection details of an IP address of 0.0.0. and an audio setting of sendonly which the receiving device responds back with recvonly. Press hold to re-establish the media stream resends the appropriate connection IP address along with the sendrecv attribute. The receiving device responds with sendrecv and two way audion is reestablished.
Call hold - old and new methods
placing a user on hold is accomplished by setting the connection address to c=0.0.0.0
discourages the use of c=0.0.0.0. Extends options available with the following attibutes.
RFC 3264 attributes
used to establish a 2-way media stream
the SIP endpoint would only receive (listen mode) and not send media
The SIP endpoint would only send and not receive media
The SIP endpoint would neither send nor receive media.
INVITE and reINVITE
Resent /Retransmitted INVITE
contains the same Call-ID and CSeq value as a previous INVITE and is normally sent to the proxy if a '100 trying' has not been received
A re-INVITE is used to change the session parameters of an existing or pending call. It uses the same Call=ID, but the CSeq value is incremented because it is new request
SIP mobility allows freedom to have calls redirected to the location you are currently at and to the device you want to receive calls on.
SIP call forking - parallel
With call forking in 'parallel mode', the SIP proxy receiving the INVITE will discover via the location server that you have two current locations. It will send an INVITE to both locations at the same time
Both locations will ring and the proxy will notify the caller of this. In this example, the desk phone answers and sends a 200 OK message to the proxy. The proxy forwards the 200 OK to the caller and send a cancel message to the softphone to stop ringing.
SIP call forking - sequential
Sequential call forking is when the Proxy tries to contact the SIP devices registered for a user in order, one at a time. eg. the 1st device returns a 302 moved response that will then allow the proxy to move on and try the next device on it's list. In reality, the Proxy will probably be communicating with a destination proxy that will respond saying that the device user has moved not the end device.
E.g. IF Lynda answers her mobile and desk phone, you will have 1 conversion or call and 2 call legs.
A call leg in RFC 2543 refers to the signaling relationship between two user agents (UAs) but this is now referred to as a 'dialog' in the replacement of RFC 3261.
In a SIP INVITE, a dialog is identified by a call identifier, local tag, and remote tag.
In an initial call setup, the From field has a tag at the end of the field. The To field only contains the SIP URI, no tag as yet.
The 200 OK contains, the unique caller id, CSeq value, and tag on called to and the unique tag on calling number.
Introduced in RFC 3261 and are used by servers ans systems to help them differentiate all of the dialogs that they may be involved in.
All branch IDs start with z9hG4bk
The Contact field is found in the SDP body of a SIP message.
Call forward to voicemail
The proxy knows about the call forward setting, sends a message to the calling device to notify it of the call forwarding setting.
The proxy rewrites the INVITE and sends it to the voicemail server. This server then responds and a media path is established so the caller can leave a message.
When the called hangs up the VM sends a NOTIFY sip message that will make the MWI indication on the phone light up.
SIP Call forward - No answer
Proxy sends an INVITE to a device which rings and responds back to the proxy. After a configurable timer has expired on the proxy, the proxy sends a cancel to the device that responds and then the proxy sends an INVITE to the call forward number the proxy has for the user.
Replaces is used for attended call transfer, call park. RFC3891.
1. Operator calls the call center
2. Get a 182 response. Operator transfer customer to the call center using REFER method.
3. Customer issue an INVITE with the replaces header to take the operators place in the queue. From entry changes to the customer with his own unique tag. The Replaces header shows the replaced call ID and the tags used in the transaction between the operator and the call center.
4. The call center then sends the 182 message to the customer.
In this scenario, call is forwarded on no answer and the new Diversion header will contain the detail of where the call has been diverted from along with a reason.
The proxy can receive all respond from possible destinations and send back only the appropriate 200 response without maintaining state an agent would have sent 3 invites and maybe received the errors before the live agent could respond, resulting in call setup failure.
VIA and Record-route
Via and Record-route entries can help prevent 'loops' and can govern the path a SIP message takes.
VIA records are added to a SIP message as follows
VIA headers are used by proxies to see if any looping of the message has occurred. If they receive a message that includes their own IP address in a VIA record a 482 (Loop detected) response is returned to the sender
When sending a Request message, which is used?
Contact (if there is no route)
From (if there is no contact)
Record-route / VIA defined
Endpoint A sends a request say INVITE to proxy1, proxy1 forwards it to proxy2 and proxy2 gives that INVITE to endpoint B. Each proxy adds its Record-route at the start of the record-route header, when called party gets request, last proxies record-route token is the at the start of record route header. Unlike Via, the record route is not deleted by respective proxies in return path. At calling party, whole record route is received.
When the request is arrived at UAS, the route set is prepared from record-route header taken in order. If record-route is absent, route set is set to NULL.
When the response received at UAS, route set is prepared at UAS by taking RR in reverse order.
In next transactions because of Route set request URI may be affected. If route set is empty, the UAC must place remote target URI into the Request-URI.
If first route URI in route set contains lr parameter (loose routing), then request-URI is not affected.. However if first route URI does not contain lr parameter, then UA should put the first route to request-URI, then put the route set in order, and finally adds remote target to Route header at the end.
VIA is used by UAS to to determine target to send immediate response. All proxies in path adds corresponding Via at the start of Via header. Say there are N proxies. So Via at called party looks at proxy(n).via;proxy(n-1).via.... Calling-phone-via
So when UAS responds back, it sends all Via without any modification. Now each proxy deletes its corresponding via, finally when response is received at endpoint , endpoint sees its own via only.
Route and Record-Route header fields have a slightly different purpose >-- they are used to route _requests_
User agent A with IP address 22.214.171.124 sends an INVITE request to the proxy which forwards the request to user agent B. UA A adds the Contact header field in the request. The Contact header field tells UA B that it can reach UA A on IP 126.96.36.199. UA B adds a Contact header field to 200 OK reply, telling UA A that it can reach B on IP address 188.8.131.52. This way both user agents exchange their IP addresses and they do not need the proxy anymore. They can easily send all further SIP messages directly to each other, because they remember the IP address of the remote party from Contact header field. This way all further requests would bypass the proxy server.
There are many cases where the proxy server needs to see _all_ future SIP messages exchanged between the user agent, such as for accounting. In this case the proxy server needs tell the user agents that they should not exchange future SIP messages directly,but they should relay them through the proxy again.
The proxy server can do this by inserting Record-Route header field in the INVITE message. The Record-Route header field contains the IP address of the proxy and once the INVITE message reaches UA B, it extracts the IP address of the proxy server from Record-Route header field and store it in memory along with the IP address of the remote party (UA A). So UA B knows the IP address of UA A and it also knows that it should send all future requests to UA A through the proxy server.
UA A should also send all future SIP requests to UA B through the proxy server, but it does not know it yet, because the proxy server added Record-Route header field to the INVITE message which will only reach UA B. UA B has to tell UA A that all future SIP requests should be sent through the proxy, and it does so by copying all Record-Route header fields from the INVITE message to 200 OK which is sent from UA B to UA A. UA A will then extract Record-Route header fields along with Contact from 200 OK and store it in memory. At this point both user agents know the IP address of the remote party and that they should relay all SIP messages through the proxy.
When UA A wants to send an ACK to UA B. It will lookup the IP address of the remote party (Contact from 200 OK) from memory and put it in the Request-URI of ACK. The reason why ACK does not have the same Request-URI as the original INVITE is that the ACK should be sent to the user agent instance that generated 200 OK -- the Request-URI from the INVITE would fork if user B had several user agents and this is not desirable for ACKs.
The URI based on Contact header field never forks, it is delivered only to the UA instance that generated 200 OK. UA A will also find the URI from the Record-Route header field in memory (stored along with the contact of the remote party). It will create a Route header field, put the URI in it and append it to the ACK.
1. 192.168.100.31 calls 08457445445 which generates a SIP INVITE
2. The domain name of UA A service provider is appended to create the Request URI
3. VIA Header is added to by UA A along with its local LAN contact details
4. Contact field is populated with the Live contact deails, eg UA A phone number + the IP address/port combo of the outside edge of my network.
4. To, who UA A is calling
5. From, UA A phone details
200 OK response have VIA records that were included in the INVITE removed. Only the VIA record for the UA A phone is included.
There are also 2 record-route records that were added to the INVITE message by the SIP and Billing servers on the ways out. Record - Route records are never deleted.
Contact element changed to represent the SIP provider gateway and will be used in the ACK to be sent
ACK message needed to end up at the SIP gateway. The Request-URI is the sip URI of the called number + the IP address of the gateway of the SIP provider
The messag is sent to the top of the Route list, the IP address of the SIP server
When the SIP server checks to see if the Request URI is something it is resonsible for or owns compares its IP address with the first route record, rewrites the ACK message which is then sent to the Billing server
Billing server does its own checks and removes the route record and tthen forwards the ACK based on the info in the request URI, the gateway
Loose routing - The way SIP servers leave the Request URI alone and use the route records to route, RFC 2543
multipurpose Internet Mail extensions
was defined to provide a way of attaching different document/ file types to email messages. SIP takes advantage of this existing standart by using it to inform a UR what content is present in a SIP message
Content-type: application/ SDP
tells us that the MIME content of the SIP message is the application layer protocl SDP. The UA, if support SDP, can interpret the SDP info in the message to find out details such as codecs supported in the inviting agent and prot numbers for responses.
Content is described as
Multiple MIME parts
A SIP message can actually contain multiple MIME parts, but there needed to be a set boundary defined to separate each of these parts. Boundary 1 separates the usual info in the SDP body and then following the next boundary marker is a gif image.
SIP to PSTN call flow
public switched telephone network
Integrated services digital network user part
Initial address message
numbering plan indicator
The gateway convert the RTP media to TDM media for the PSTN.
SIP code and PSTN mapping
Back-2-Back user agent is a 4th type of server. Others are proxy, registrar, and redirect. Can act as standalone proxy
The B@BUA maintains the complete call state and continues to send requests and responses for sessions in which it is involved.
B2BUA benefits and features
Centrialized management of all calls
PBX call managment features such as call transfer, forwarding and automatic call disconnection to warn a user that credit is low.
Call conferencing facilities
The ability to 'hide' the network such as private IP address schemes and the underlying network topo from scanning attempts
The ability to connect two different types of signalling networks such as SIP and H323 for coexistence during a migration to a fully SIP based network
Implement and enforce policies such as class of service and restriction
It is the SIP user agent server (UAS) that initiates a SIP call
Session Initiation Protocol
At what TCP/IP layer would you find the SIP protocol
SIP proxy sever will always relay media as well as SIP messages on behalf of a SIP UAC
Valid URI addresses
Can contain +,-,name,starts wit sip:
After a successful REGISTRATION
A 200 code is sent
Main characteristics of a SIP location server
1. The LOCATION service usually coexists on the same server as the REGISTRAR service2. It can utilize external databases such as DNS
SIP Request methods
REGISTER, UPDATE, CANCEL, INVITE
SIP Response code types
Response code - moved temporarily
VIA element of a SIP message can be found in the SDP body
SIP response, elements from the initial SIP message ar copied exactly
Via, From, To, Call-ID, and CSeq are copied exactly from Request. To and From are NOT swapped
A SIP device needs to send SDP element in order to negotiate the codec to use with the 'called' SIP device
Sequential SIP 'Call Forking' implies a proxy will 'call' you SIP registered devices one after the other until one is answered
A SIP UAS will try to use the location details in a certain preferred order to get a Request to a SIP UA as part of a dialog
Route, Contact, From
Back to Back User Agent
If you move your SIP device and it does not reregister with the REGISTRAR server it will be able to locate the SIP device using DNS