IP Packet switching in Telecom - Part 4 - telecomHall

Home Site Map

27/10/2013
Register

telecomHall
Home Hunter Get Hunter Tips Course Groups Forums Jobs Events

enter search terms Search

Sign In

Community

About

IP Packet switching in Telecom - Part 4

Posted by leopedrini Thursday, March 22, 2012 11:11:00 AM C ategories: C ourse Previous Post << >> Next Post

March 2012 F 2

+
S 3

S M T W T 26 27 28 29 1

And then we finally get to NGN signaling protocols: SIP and SDP. The Rate this C ontent picture below was extracted from RFC 3261 and gives a fairly good example of a SIP dialog between two users, Alice and Bob.

0 Votes

9 10

11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 2 3 4 5 6 7

Statistics
Entries (24)

Categories
C ourse (24)

Related Posts
Analyzing C overage with Propagation Delay - PD and Timing Advance - TA (GSMWC DMA-LTE) What is RRC and RAB? What is Retransmission, ARQ and HARQ? IP Packet switching in Telecom - Part 3

The entities involved in the call setup are called User Agents (UA). UAs which request services are called User Agent Clients (UAC), and those which fulfill requests are called User Agent Servers (UAS). Although the basic operating mode is end-to-end, the model supports the use of intermediate proxy servers, which work as back-to-back User Agents (B2BUA) relaying requests from one user to the other. In the picture Alices softphone and Bobs SIP phone are the end-to-end user agents, while theres two proxy servers: atlanta.com and biloxi.com. Linking this with what we already know about IMS, we can identify the P-CSCF as a SIP proxy server, while the communicating UEs are the end-to-end UAs.

IP Packet switching in Telecom - Part 2 IP Packet switching in Telecom - Part 1 Goodbye IPv4... Hello IPv6! What is Antenna Electrical and Mechanical Tilt (and How to use it)? What is MIMO? How to Run a RF Site Survey (Tips and Best Practices)

Note: Also visit my blog Smolka et Catervarii (portuguese-only content for the moment) Quoting RFC 3261: SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services. For example, SIP can locate a user and deliver an opaque object to his current location. If this primitive is used to deliver a session description written in SDP, for instance, the endpoints can agree on the parameters of a session. If the same primitive is used to deliver a photo of the caller as well as the session description, a caller ID service can be easily implemented. As this example shows, a single primitive is typically used to provide several different services. SIP primitives are:
REGISTER: indicate an UA current IP address and the Uniform Resource Identifiers (URI) for which it would like to receive calls; INVITE: used to establish a media session between UAs; AC K: confirms message exchanges with reliable responses (see below); PRAC K (Provisional AC K): confirms message exchanges with provisional responses (see below). This was added by RFC 3262; OPTIONS: requests information about the capabilities of a SIP proxy server or UA, without setting up a call; C ANC EL: terminates a pending request; BYE: terminates a session between two UAs.

What is Ec/Io (and Eb/No)? What is C ellular Field Test Mode? What is Antenna? OSI 7 Layers Model What is RF Drive Test (Testing)?

Archives
June, 2013 (1) May, 2013 (1) June, 2012 (1) March, 2012 (1) February, 2012 (2) January, 2012 (1) November, 2011 (1) October, 2011 (1) September, 2011 (1) June, 2011 (1) April, 2011 (2) March, 2011 (3) February, 2011 (5) January, 2011 (1)

Typically a SIP message have to have a response. Like HTTP, SIP responses are identified with three-digit numbers. The leftmost digit says to which category the response belongs:
Provisional (1xx): request received and being processed; Success (2xx): request was successfully received, understood, and accepted;

http://www.telecomhall.com/ip-packet-switching-in-telecom-part-4.aspx

1/3

IP Packet switching in Telecom - Part 4 - telecomHall

Success (2xx): request was successfully received, understood, and accepted; Redirection (3xx): further action needs to be taken by sender to complete the request; C lient Error (4xx): request contains bad syntax or cannot be fulfilled at the server/UA of destiny; Server Error (5xx): The server/UA of destiny failed to fulfill an apparently valid request; Global Failure (6xx): The request cannot be fulfilled at any server/UA.

27/10/2013
December, 2010 (2)

Session Description Protocol (SDP) is described at RFC 4566 (warning: IETF mmusic working group is preparing an Internet Draft which eventually will supersede RFC 4566). Matter of fact, it should be called Session Description Format, since its not a protocol as we use to know. SDP data can be carried over a number of protocols, and SIP is one of them (although RFC 3261 says that all SIP UAs and proxy server must support SDP for session parameter characterization). Quoting RFC 4566: An SDP session description consists of a number of lines of text of the form: <type>=<value> where <type> MUST be exactly one case-significant character and <value> is structured text whose format depends on <type>. In general, <value> is either a number of fields delimited by a single space character or a free format string, and is case-significant unless a specific field defines otherwise. Whitespace MUST NOT be used on either side of the = sign. An SDP session description consists of a session-level section followed by zero or more media-level sections. The session-level part starts with a "v=" line and continues to the first media-level section. Each media-level section starts with an "m=" line and continues to the next media-level section or end of the whole session description. In general, session-level values are the default for all media unless overridden by an equivalent media-level value. Some lines in each description are REQUIRED and some are OPTIONAL, but all MUST appear in exactly the order given here (the fixed order greatly enhances error detection and allows for a simple parser). OPTIONAL items are marked with a "*".

Heres an example of an actual SDP session description:

Very well. I think thats enough to you understand how NGN signaling works. Now its time to get one step down on the TCP/IP protocol stack, so on our next article well be starting to talk about transport protocols, and will understand how the socket API is used to create separate sessions over the transport protocols service Au revoir, mes amis.

Tweet

Previous Post << >> Next Post

http://www.telecomhall.com/ip-packet-switching-in-telecom-part-4.aspx

2/3

IP Packet switching in Telecom - Part 4 - telecomHall

Site Map | Printable View | 2008 - 2013 telecomHall Powered by mojoPortal | HTML 5 | CSS | Design by styleshout

27/10/2013

http://www.telecomhall.com/ip-packet-switching-in-telecom-part-4.aspx

3/3