dupontsergio75@gmail.

com naHenb l'IHCTpyMeHTOB Bbtfirn

U&)H6VSE

8/03/2015 Blog Archive

► 2017 (1)
E2E VoLTE call setup(3/4) - Voice call setup
► 2016 (5)

... 2015 (18)

Once the IMS registration is successfully done between the UE and the IMS network, the user can
► October (1)
make a VoLTE call. Upon request for voice call from the user, the VoLTE UE starts SIP signaling with
► September (1)
the IMS core. The SIP messages are routed based on initial Filter Criteria (iFC) in the IMS Core and
delivers SDP offer and answer to establish media session along with various SIP headers. As a ..- August (5)
consequence of the SIP signaling, a new dedicated EPS bearer is established between the UE and the E2E VoLTE call flow : detach (UE-initiated)
SGW/PGW which is used to transfer voice media. The QoS of this new dedicated EPS bearer is
VoLTE: Service Request scenario in IDLE
defined by the PCC rules generated by the PCRF. mode

VoLTE : UE initiated voice call release

E2E VoLTE call setup(4/4) - dedicated EPS

Introduction
bearer c...

While the SIP messages go through the default EPS bearer (QCl=5) towards the IMS core, the voice media path is E2E VoLTE call setup(3/4) - Voice call setup

established at the front-end NEs taking the role of IMS Application Level Gateway (IMS-ALG) and IM Access Gateway
► July (5)
based on SDP negotiation. The following diagram shows the conceptual diagram of IMS-ALG and IMS Access Gateway
► June (6)
model specified in 3GPP TS23 .228. The IMS-ALG controls media resources and gating functions of the IM Access
Gateway over lq interface. It acts as a B2BUA and can modify the SDP and SIP headers of SIP messages if necessary.
► 2014 (4)
The IM Access Gateway executes the allocation and release of transport addresses, IP versioning and the media gating
function under the control of the IMS-ALG.
Popular Posts

CII
""' E2E VoLTE call setup(l/4) :
Cl
UE A ' s Home network UE B ' s Home network Initial attach and default EPS
""' ""' bearercreation
When the UE is turned on, it
establishes a PDN connection
(,._ _ _ _ _1M_ s_ c_ o_,_• _ _ __ _ , ~ N~ -----
1M_s_c_o_, e
_ _ _ __,] with a default APN. In this test for VoLTE call
setup, the operator pro ...
P-CSCF IM Ac cess lq IM Access P-CSCF
Gateway Gatew ay
E2E VoLTE call setup(2/4) : IMS
0MS-A LG} .1 registration
Once the UE attaches to the
G LTE network and the default
S/PGW S/PGW EPS bearer is created
successfully with the IMS APN, the UE
registers t ...
EPS OE'arerQf
QC/al - ----
E2E VoLTE call setup(3/4) -
EPS bearer cf
QCt=5 ----- -- Voice call setup
Once the IMS registration is
UEA UE B successfully done between the

1/17
 UE and the IMS network, the user can make a
VoLTE call. Upon request ...
Fig 1. IMS-ALG and IMS Access Gateway model

VoLTE: Understanding of GTP

The following diagram shows how the media path is established. Upon request from the user for voice call setup, the ~ TEID to use in LTE trouble

UE sends VoLTE call setup request {i.e., SIP INVITE) to the IMS core with an SDP offer, which contains the allocated
·" ~ shooting
--=- The GTP(GPRS Tunneling
media information of the originating UE [A] . The IMS-ALG allocates media resource in the IM Access Gateway to which Protocol) is a communication
the originating VoLTE UE can access. The allocated media information at IM Access Gateway is sent back to the UE in protocol used by the LTE to deliver IP packets
the response as an SDP answer [a] . The IMS-ALG allocates additional media resource for the upstream, includes it in within the EPC. The GTP-C is used to de ...

the SDP offer and sends it towards the remote IMS-ALG [B]. The IMS-ALG in the remote IMS network responds with
VoLTE : Tracking Area Update
the SDP answer containing the media access point of IM Access Gateway in the same network [b] . The IMS-ALG in the
and combined attach
remote network also allocates another media resources and sends it to the UE as an SDP offer [C] . In turn, the UE will A telecommunication network
also send back the response including SDP answer of its own [c] . provides the way of identifying
and tracking the location of the
UE to maintain the UE mobility. The UE regis ...
NOTE the gray arrow indicates the signaling path and the rest indicate the media path and its direction.

VoLTE: Traffic Flow Templates

The service data flow template
is a set of packet filters applied
UE A ' s Hom e netw or k U E B ' s Home netw ork
to IP packets to identify the
service data flow belonging to
a specific a...

E2E VoLTE call setup{4/4) -

dedicated EPS bearer creation
While SIP signaling is in
progress in VoLTE call setup, a
dedicated EPS bearer is created
for voice media transfer. The dedica ...

VoLTE: Service Request

scenario in IDLE mode
.. . The IDLE state is defined as the
J state when both RRC state (i.e.,
eNB and UE signaling
connection state) and ECM state (i.e., NAS
signaling ...

UE A ' • UEB
a r- VoLTE: Bearer binding and
Session binding
E) as The LTE supports the
PCC(Policy and Charging
Control) architecture for QoS
Fig 2. Media path establishment control applied to service data flow. In the
PCC architecture, t...

NOTE The IM Access Gateway functionality is typically provided by Service Border Controller {SBC) .
E2E VoLTE call flow: detach
{UE-initiated)
G The UE initiated detach

II. VoLTE call setup procedure procedure may occur when the
UE is turned off or the UE
needs to fall back from EPS services to non-
Upon request from the user for VoLTE call setup, the UE initiates SIP signaling with the IMS core. The P-CSCF address is
EPS services or...
informed to the UE when the UE attaches to the network. The signaling path beyond the P-CSCF is determined based
on a routing mechanism of IMS core. The SDP negotiation is performed along with the SIP signaling and determines
the media path for voice call setup.

Upon receiving call setup request {i.e ., SIP INV/Tt), the P-CSCF informs the PCRF of the service data flow information.
The PCRF triggers the Evolved Packet Core {EPC) to create a dedicated EPS bearer of QCl=l for voice media by
2/17
generating and provisioning PCC rules to the SGW/PGW. The PCC rules include QoS parameters and rules to be
applied to service data flows based on which the SGW/PGW establishes mapping relations between service data flows
and the EPS bearers.

NOTE Based on GSMA IR.92, the UE is strongly recommended to support the precondition framework for VoLTE.
Please note that, in the following practice, the precondition procedure has been disabled before testing. Please refer
to FCM.01, IR.92 and 3GPP TS 24.229 for the detail.

NOTE While the following procedure shows the only originating side, the same procedure and principles can also be
applied to the terminating side. The signaling procedure handled within the IMS core has not been described to avoid
complexities as it can vary based on the deployment architecture as per IMS vendor.

I UE I I eNB/EPC I l M ME I [ sGW/ PGw l I PCRF I I P-<:SCF I l S-CSCF I

4 8. &IP INVITE
Fr om. To, Ro ur, Acceix-COntact, P Preferreo-Serv1te,
r>-Pre!<!r-ldenrr , lon- ·xpo-e:s, 1 l)Ore,1, SOP offe, 1 Try in g
J OO Trying

49.11 3 Session In Prog ess

SO I' er
50.AAR
ME<lia desc:rip;:o- IP fbw, fbw sta:u
pro ol, m e<l<aty ~e, M 6R, Codec), S. vlt.,.
Info-St u Fm . f-(; h &11"€- •d, U I
SUbsulpcion Info '·
51.RAR
- PCC rule (n.lle na I w, fbw st< u,;QoS-
QCVGl!R/ BP./A ~ l't ed e,Af- hcr1:•re-idJ
EPS de< ·,ott:tl lu:rue, nt ';lliun
•
~ ~
• I
52. RAA
IP-<:AN-T'/Pe,· R~T ype, 3GPP-SGS -MCC- r-1 C, 3GPP-
U e•l lltlon I AH CG)

I De d icated EPS be ane r o QCl=l Il

IP-GAi -T
53. AAA
e.RAT Type

54.183 S ~<ion Progre<<

SOP "il'ilSI.Sef

55 . PR ACK
-
56. 200 OK

57. 180 Ri ngin

- -
_58. 200 O~
59. ACJC

Fig 3. VoLTE setup call flow

[48] Upon request from the user to make a voice call, the originating UE sends the SIP /NV/Tftowards the P-CSCF.

• Supported header: a list of option tags indicating supporting features. In this example, the "timer" and
"l00rel" indicate support of session timer and a reliable delivery of the provisional response (i.e., 183
Session In Progress), respectively.
3/17
• P-Early-Media header: indicator of whether the UE supports the early media mode.
• Allow header: a list of SIP methods that is supported by the UE.

• P-Preferred-ldentity header: the originating user's identity that is preferred by the originating user to be
used. This header is replaced with the P-Asserted-ldentity header by the P-CSCF in the IMS network. If
the SIP message is sent towards untrusted IMS core, the P-Asserted-ldentity header shall be removed.
• User-Agent header: VoLTE client information

• Privacy header: preference of sending UE indicating that any sensitive information shall be hidden from
any parties that do not need to know it.

• Accept-Contact header: a list of features of target UE preferred by the sending UE

• P-Access-Network-lnfo header: the radio access technology and cell identity.

• Session-Expires header: a valid period of time of this SIP INVITE session. The parameter "uac" indicates
that the sending UE will refresh the session before the timer is expired.

• P-Preferred-Service header: service identification user wishes to be used. This header is replaced with
the P-Asserted-Service header by the P-CSCF.
• Content-Type: media type of the message-body sent to the recipient.

• Route header: a list of IP addresses of intermediary nodes which the SIP request will go through. This
would a copy of Service-Route header returned in 200 OK response to SIP REGISTER, which is inserted by
the S-CSCF. The Service-Route header indicates the intermediary node associated with that S-CSCF.
• From header: sending user's SIP URI or TEL URI

• To header: recipient's SIP URI or TEL URI

• Call-ID header: a globally unique identifier of the SIP session. All the SIP messages of the same session
must have the same Call-ID value.
• CSeq header: sequence of the same SIP method. The sequence number is incremented as the same SIP
method is being sent.
• Max-Forwards header: maximum number of hops that the message can go through.

• Contact header: the contact address, device capabilities, feature-tags, etc. of the sending UE.
• Via header: a list of SIP addresses of intermediary nodes. The entry is inserted by each node that wants
to stay in the signaling path for the SIP response. The response message for this request (e.g., 183
session in progress, 100 Trying, 200 OK, etc) will be transferred to the originating UE following the
reverse path listed in this header.
• Content-Length: body length in bytes.

4/17
 ess i on I ni t i ation Pr ococo1 (INVIT)
~ Req uest - Line : INVITE tel :+ 7021075 394 SIP/ 2. 0
13 Mess age Header
supp orted : t i mer ,100r e l
P-£ar1y -Media : s upporc ed
Al l ow : Ir-NITE 1ACK , OPTION S , CANCEL I BYE1 POATE , INFO J REFER ,NOTI FY ,MESSAGE; PR.ACK
P-P r ef rred - Id nt i cy: <t 1 :+ 70 2107 24 3>
Ser - Age nt : SLICK I MS 4 . 0.0
Pr i vacy: none
Accept - c ontact: • ; +g . 3gpp. i cs i - r ef ="' ur n%3Aur· n- 7%3A3gpµ - s er v i c e. i ms . i cs i . 111-mel •·
P-Asqi s:a - N@Jj \'/Of k- tnfo : 3GPP- F, - IJTR AN- TDD j uv an-c.e 11 - i d - 39pp~ OQ060QOp u
se si on- Expi r e.s : 360 0 : r efres her =uac
P- Pr f r r ed - s rvice : ur n:urn-7 : 3gpp-s er vic e . i m~ .ics i .mmt e l
com:enc- ,ype : appl i ac ·i on/ sdp
m Rout e : <s i p :10. 75. 23 .197 : 5060; l r >, <s i p:mavodi - d-4a- 18- l c-f f f f f f f f - l &~ i mcs007. i m
Fr om : <tel: · 70 2107 524 3>;r ag= 32 2844 738 3
To : e l :+ 7021075394>
al l - Io : 64 56894 76:\1100. 64 .63 .41
;B c s eq: I I NVITE
Max- Forwards : 70
' 4 3@1 00 . 64 . 6 3 .41 : 5060 > j l· O , 3app . i c s i - r ef - "urn%3Aurn- 7%3A3a p
3 . 41 : 50 O; branch=z9hG4bK32 7 33 5030s rng; cr ansporc=T P; keep
Content - Length : 580
ff Mes sag s ody

Fig 4. headers in SIP INVITE

The SIP INVITE contains an SDP offer. The SDP defines media information of the sending node which contains the
contact ip address, port number and a list of supporting codec information. The following shows descriptions of each
parameters used in SDP.

• 'o' (originator and session identifier): <username><session-id><network type><address type><ip

address>
• 's' (session name): any textual session name
• 'c' (connection data): <network type><address type><connection address>
• 't' (timing): <start time><stop time>
• 'm' (media description) : <media type><port><protocol><fmt: media format description>
• 'b' (bandwidth): AS (application specific) - maximum RTP session bandwidth (kbytes), RS- sending RTCP
bandwidth (bytes), RR - receiving RTCP bandwidth (bytes)

• 'a=rtpmap' (attributes): <payload type><encoding name><clock rate><encoding parameters>

• 'a=fmtp' (attributes): format specific parameters related with the corresponding media
• 'a=ptime'(attributes): length of time represented by the media in a packet (ms)
• 'a=maxptime'(attributes): maximum amount of media that can be encapsulated in each packet(ms)

The following is an SDP example included in the SIP INVITE captured on the Gm interface. The UE's IP address is
" 100.64.63.41" and port number for audio is "1234", which is depicted as [A) in Fig2.

5/17
 css1 on es cr p 10n ro ocol version (v); O
owncr/crea'tor, s ess ion Id (o): CMS - U 1 2345617 0 IN IP4 100 64 63 11
s es s i on ame ( s ): VOIP
so,s s i on Informat i on ( i ) : A VOIP s es s i on
@ connect i on Irrforma'ti on (c ) ; IN IP4 100. 64. 6 3 . <11
ill Time Descr i pt i on, activo, ti me (c): O O
~ Med i a Des cr ip t i on , name and ddr ess (m): aud i o 1234
~ Eandwi dth Inforrnat i on (b): A S : 80
::El Bandwi dth Inforrna.ti on (b) : RS : 800

R- WIJ/ 16000/ 1
1 - mode- s et
rtpmap : AMR- WE 00/ 1
od - chan e - ca

ill Med i a Attr i bute

::EJ Med i a Attr i bute

Fig 5. Attributes in Session Description Protocol (SDP) offer

NOTE Upon receiving the SIP INVITE with an SDP offer, the P-CSCF may send service data information to the PCRF of
which flow-status AVP set to 'DISABLED'. In this case, the P-CSCF will send additional service data information when it
receives the 183 Session In Progress with SDP answer. In the following example, the service data information is sent
only once when the P-CSCF obtains SDP offer and answer all together at step #48.

The P-CSCF responds with a 100 Trying provisional response. The provisional response is a one-way response sent
back to the originating side used as informative. It is not necessarily guaranteed for its safe arrival.

- session Ini t iation Protoco

@ Status-L i ne: SIP 2 . 0 100 Tryi ng
B Message Header
@ Vi a: SIP/ 2 . 0/ TCP 100 . 64 . 63. 4 1:5060;recei v ed=100.64 . 63 . 41 ;branch=z9hG4 bK32
@ From: <tel :+ 702107 5243> ;tag=3228447383
To: <tel: + 702107 5394>
call-ID: 645 6894 76@100 . 64 . 63 . 41
@ cseq: 1 I NVITE
c ontent- Lengt h: 0

Fig 6. Parameters in 100 Trying

[49] The terminating UE locally allocates resources, generates the 183 Session In Progress along with SDP answer and
sends it back towards the originating UE. The 183 Session In Progress arrives the originating S-CSCF following the
reverse path of the SIP messages. The S-CSCF forwards it to the P-CSCF.

• Record-Route header: a list of IP addresses that is copied from the Route header by the terminating UE in
the received SIP INVITE. The value of this header will be reused by the originating UE when it composes
Route header upon sending subsequent SIP request.
• Require header: a list of option tags indicating features that needs to be supported by the recipient (i.e.,
the originating UE) of this message. In this case, the "l00rel" indicates the originating UE shall support
the reliable delivery of provisional response.

NOTE the provisional response, lxx, is an informative response therefore it does not usually require the
reliable delivery. However, 183 Session In Progress would be an exception as it contains the SDP answer.

6/17
 • RSeq header: the sequence number of this response. The value of this header is copied to the CSeq
header in the following SIP PRACKsent by the originating UE.
• P-Asserted-ldentity header : the authorized user's identity of the sending user of this message (i.e., the
terminating user)
• P-Charging-Vector header: a collection of charging information, which consists of IMS Charging Identity
(ICID) value, the address of the SIP proxy that creates the ICID value and the Inter Operator Identifiers
(IOI). The ICID indicates a globally unique charging value that identifies a dialog, the IOI identifies both
the originating and terminating networks involved in a SIP dialog. In the following example, the full text
for the header is as follow:

icid-value=0.274.19S-1418282284.647;term-ioi=3234S;term-ioi=22345;icid-generated-
at=10.75.0.S;term-ioi=Type3Term;orig-ioi=32345

HI Statu s - Line: SIP

G Message Header
BJ Vi a: SIP / 2 . 0 / UDP 001. i m~.mnc .mcc .3g pp nei::wor k .or g:5060 ; r~c~ivcd ~1 0 . 7 5. 0.9
0 Record - Route: <sip : - 5- 4c - 35 - 2- 2fOOOO- @· i mcsOOS. i ms . mnc .mcc .Jgppnet work.
0 From: te l :T 0210 S243 ; tag= - c - 7e- 20- b-ffffffff - _ 000C29SA756A - 24ec - b6862700 - ld9
@ To: te l : 021075394; tag, - d - 7e - 5c - 5- f-ffff-fff - _OOOc29BC860C - 13ab- e d 2eb700- 8cc - 5-
c all- ID : 000C29 SA75&A- 24ec-b68 6 2700 - l d8- 54894 52d - a 2a89
c s eq : 1 I NVITE
Requ i r : 1 00re l
RSeq: 2
[ tru n aced ) n a ct : -<S ip : - d - 7e - c - S- Ffffffff - @ 001 . ims . mnc . mcc . 3gp
r v r: / vl . O P F/v l. 0-14047 OJ
ffi P-Ass er ed- ! <l enTi t y: s ip:+ 7021075 94@i ms . rnnc . mcc . 3gppnetwork . org , tel:+ 7021 0
P- hargi ng - v ector : i c i d-va l ue=0 . 774.1 9 a-1418 28 . 284 . 64 7 ; t rm- i o i =3 34 ; term-ioi = 234 ,;
c ontent -Type: app I i c a i: i o n/sdp
P- E:ar l y - Me dia: inact i v e
P- Acc ess - Ne.t\'lork- Info : 3GPP- E: - UTRAlll •TDD;ui:ran- cell-i d- 3gpp, 00060001.all
coni:ent - Leng,h: 397
All ow: UP DATE ' NOTI FY ' I VTIT. I FO ,P RAC K, ACK , BYE , SU BSC RIB[ , NOT IJ:Y, RCGIST[R,Rffl:R,OPTION
l!l Message Body

Fig 7. Headers in 183 Session In Progress

[SO) Upen receiving the 183 Session In Progress, the P-CSCF triggers the Authentication and Authorization
Request (AAR) towards the PCRF to inform the fact that there is a new Application Focus (AF) session being created.
The PCRF performs session binding between the AF session and the corresponding IP-CAN session .

NOTE AF indicates an element offering applications that require the Policy and Charging control of the user plane
resources. In this context, it indicates the P-CSCF.

• Session-Id AVP: identifier of Rx session for this application. It lasts until this application (i. e., VoLTE
session) does exist.
• AF-Application-Identifier AVP : identifier of the VoLTE call session assigned by the P-CSCF.
• Media-Component-Description AVP : media information of the service data flow

• Service-Info-Status AVP: the status of the service information that the P-CSCF is providing to the PCRF.

o FINAL SERVICE INFORMATION (0) : the service has been fully negotiated between the two
nodes and the provided service information is the result of the negotiation.
o PRELIMINARY SERVICE INFORMATION (1) : the provided service information is a preliminary
and further negotiation is to be needed between two nodes.

NOTE In this example, the value is set to be "FINAL SERVICE INFORMATION" as the P-CSCF has both SDP offer
and answer.
7/17
 • AF-Charging-Identifier AVP : identifier for charging correlation with bearer layer.
• Specific-Action AVP: a list of events that P-CSCF wants to be informed from the PCRF. The PCRF shall
report to the P-CSCF when any of these events occurs.
• Subscription-Id AVP : identifier of the end user's subscription. It holds subscription type and data.
Multiple instances of the subscription-id indicates multiple type of identifiers of the same subscriber
such as E164, SIP URI, IMSI, etc.
• Framed-IP-Address AVP: UE's IP address which is allocated by the PGW during initial attach procedure.
• Required-Access-Info AVP : indicator of query by the P-CSCF for access network information.

8 Di amet er Pr o ocol
v ers i on : OxOl
Lengt h : 2160
,..i Fl g : oxco
c o and c ode : 265 AA
Appli ti on.Id : 3GP P R (1 777236 )
Hop- by- Hop Ident ifier: Ox90075 010
nd- o- cnd rde n ifi r: 0 57 8aSf77
[ Answer I n : 128]
s ss , on - I i -- - v.i =10 . 75 . 3.19.? ; 80; 67179008; 5254
o r i gi n-ttost (2 64 ) asb c002. ims . mnc . mc c . 3g ppnenmrk .
AVP : or igi n- R al m( 296) 7=41 f =-M- val =ims . mnc . mcc . 3gp pne wor k . er g
AVP : AU[h-App l i car ion-Id (25 8) 1=1 2 f=- - v a1=3GPP RX (16777236)
D~ti na i on -Realm (2 83) 1=41 f =-M- v al =epc. mnc . mcc . 3gp pnetivork. or g
A - Application- dent i fi er(5 04) 7=49 • VM - vnd=TGPP va1=757 6 3 7 72 6e d3
Media- c omponent- oes cr ipt ion (517) 1=1268 f = , - vnd =TGPP
ii AVP : s rvi - t nf o - s·t t.u (527) 1 1 6 f VM - v nd T •,PP v al - l'lNAL_S RVlC _! N ORMATT
ffi AVP: AF-Char g ing- I dent i fi er (50 5) 7=36 f =VM - v nd=TGP P v al=302e3237342 e 313935 2d
'B AVP : Sp ci-fic - A ion (5l ) 1- 16 f - vnd TGPP v a7 • JNO CATION_OF_ o ss_o _ G·AR
@ AVP: spec i f ic-Act i on(513) 7=1 6 f =VM- v nd=TGPP val =INDICATIO N_OF_RECOVERV_OF_B
ttJ AVP: Sp ci fic- A i on (513) 1~16 f ~vr-- vnd- TGPP val =INOICATION_OF_RELE S OF E
@ AVP : Spec i f i c-Acti on (51 3) 1=1 6 f= - vnd=TGPP va l =CHARGING_CORRE LATION_EXCHA
AVP: speci f ic-Acti on (S13) 7=1 6 f=VM- v nd=TGPP va7=ACCESS_ ETWORK_ I FO_ REPORT
subscripc i on- Id(443) 1=80 f=- -
s ubs c r ipt i on-Id (44 3) 1=4 4 f=- -
sub~cripcion- Id(44 ) 1~84 f -- -
s ubs cr ipt: i on- Id (44 3) 1=44 f =- 1~-
Suppo r ted - ea tu r ( 628 ) 1• 56 f • V-- vnd• i PP
Framed- IP- Addr ess( 8) 1=12 f =- • - va l =I00 . 64 . 63. 41 { 100 . 64 .63 . 41 )
R quir d- Acc <s - Inf o (536) 7• 16 f v -- vnd~TGPP val • IJ SE LOCATION (O)
Rour e-Rec or d{ 28 2) 7= 52 f=-M- v al= as bc 00 2 . i ms . mnc . mcc
AVP : Route-Rec or d(282) 1= 52 f =-M- val = dr aa OOI . i ms . mn . mcc
oest. i nai: i on-Host 293 1=52 'f=-/11- val= cr fOOl. e c. mnc . mcc

Fig 8. AVPs in AAR

The Media-Component-Description AVP reflects the SDP offer and answer which includes the media type, direction
and codec information.

• Media-Sub-Component AVP: descriptions for media flows. There are two sub components appears in this
snapshot, one for RTP and the other one for RTCP.
• Flow-Description AVP : description for IP flow in each direction, of which IP addresses and port numbers
are copied from the SDP offer and answer by the P-CSCF.

o Uplink IP flow: UE ("100.64.63,41", " 1234") ➔ SBC (" 10.75.23.197", "10570" )

o Downlink IP flow: SBC (" 10.75.23.197", "10570" ) ➔ UE ("100.64.63,41", "1234" )

• Flow-Status AVP: permission status of each media flow.

o ENABLED-UPLINK (O) : enable associated uplink IP flow(s) only.

o ENABLED-DOWNLINK (1): enable associated downlink IP flow(s) only.
o ENABLED (2) : enable all associated IP flow(s) 8/17
 o DISABLED (3): disable all associated IP flow(s)
o REMOVED (4) : remove all associated IP flow(s)

• Media-Type AVP: the type of media stream e.g., audio, video, data, text, message.
• Max-Requested-Bandwidth-UL/DL AVP: the Maximum Bit Rate (MBR) of the IP flow in each direction.
The bandwidth contains all the overhead coming from IP layer and the layer above e.g., IP, UDP, RTP, RTP
payload.

• RS-Bandwidth AVP: maximum required bandwidth for RTCP sender reports.

• RR-Bandwidth AVP: maximum required bandwidth for RTCP receive reports.

• Codec-Data AVP : codec related information known at the P-CSCF.

B AVP : ,edia- compone.nt - Descrip t: ion(Sl.7) 1=1268 f = IIM - v nd=TGPP

AVP code: 51.7 Medi a c omponent - De.scription
@ AIIP Flags: o,co
AVP Le.ng h: 1268
AVP ve.ndQr Id: 3 pp JO 'L5
B Media-component-De,cr i pt:ion: 00000 06cOD0001000002Baf0000000100000207cOOOOObc . .
[I A P : Media- component: - umb er (518) l - 16 f • VM - vnd• TGPP val -1
13 AVP : Media - sub- Co;nponent(519) 1= 188 f =VM- vnd =TGPP
AVP code: 519 Medi a-sub-component
~ AVP la9 : ox o
AVP Length : l88
AVP vendor Id: 3GPP (10415)
6 Med· a - sub - c omponent: OODOOlfdc0000010000028afOOOOOOOlOOOOOlfbc000004 5 ...
AVP: F l OW-Number(509) 1=16 f=IIM- vnd=TGP P val=l
AVP: 1'101-1 - Des r i pri n(SO) 1=69 f=VM - VIIU=T PP val=perm i l in i 1, from 100.6'1.63 . 41
AVP: F l ow-D scr i ption (,O) 1= 70 f=VM- vnd=TGPP val=permir out i p from 10. 7 .?3 . 19
AIIP : r- ·101-1 - Stat us(Sn) 1- 16 f - vM - v nd~TGPP v ah .HMB LED (2)
II AP: Media - sub- component (519) 1 • 204 f - VM vnd TGPP
AVP: AF-App l i cation-Ident i fier(504) l=-19 f=VM- vnd=TGP P va l =75726e3a757 26e2d373a33677
It AVP: M dia - iyp (520) 1=16 1=\IM- nd=TGl"P val=AUl)lO (0)
AVP : Ma -R quesced-Ban<lwidch-u (~16) l=lf;> f=VM- vnd=TGPP va l = 1000
[I AVP : r•1ax- Requesred - sanm,lidth - DL(S1S) 1=16 t =VM - vnd~TGPP va J~soooo
AVP: Fl 01•- Stat:us(Sll) 1• 1 6 f \M 0 vnd- TGPP val •ENAIILED (2)
II AVP: RS -Bandwidth(5 22) 1=16 f=\1),1 - vnd=TGPP val=3 67
AVP : RR-6d11dv,•'id h(521) 1=16 f =W- vnd=TGPP val=llo2
J;- AVP: odo.c - o ,a AVP(524) 1=23 f=VM - vnd=l PP va l =downlirlk\r \ t1.Jns>1er \r\nm=aud i 105 70
VP: codec - oa ca AVP( 4) 1=46'1 f =\1'1 - vnd=TGP P va l - uplink \r \ noffer \ r \ m.,,,audio 1234 RTP

Fig 9. Sub-AVPs of Media-Component-Description AVP

[51] Upon receiving the MR, the PCRF generates PCC rules. PCC rules includes IP flow description for uplink and
downlink (i.e., 5-tuple), QoS information, the flow status, etc. The SGW/PGW performs bearer binding between the
received PCC rules and the corresponding IP-CAN bearer. The IP flow shall be mapped to a specific IP-CAN bearer
based on these PCC rules by the SGW/PGW

• Charging-Rule-Definition AVP: A PCC rule. There are two PCC rules showing up for voice call, one for RTP
and the other one for RTCP.
• Charging-Rule-Name AVP : A PCC rule name. It is uniquely defined within the same IP-CAN. If the PCC rule
is pre-defined in PGW as is the case for default EPS bearer, it is uniquely defined within the PGW.
• Flow-Information AVP: a single IP flow packet filter. It includes the ip address and port number and the
direction of the IP flow.

• Flow-Status AVP: permission status of each media flow. Refer to step#49 for the detail.

• QoS-Information AVP: QoS information to be applied to the IP flow, which includes QoS Class Identifier
(QCI), GBR (Guaranteed Bit Rate), MBR (Maximum Bit Rate) and ARP (Allocation Retention Precedence).

• QoS-Class-Identifier AVP : QoS Class Identifier

• Guaranteed-Bitrate-UL/DL AVP : guaranteed for service data flow. The bandwidth contains all the
overhead coming from the IP-layer and the layers above e.g., IP, UDP, RTP and RTP payload.
9/17
 • Max-Requested-Bandwidth-UL/DL AVP: the Maximum Bit Rate (MBR) of the IP flow in each direction.
The bandwidth contains all the overhead coming from IP layer and the layer above e.g., IP, UDP, RTP, RTP
payload .

• Allocation-Retention-Priority AVP: The priority of allocation and retention . When a new media resource
is requ ired to be allocated and all the resources are already occupied, the PGW can release the allocated
media resource and re-allocate it for the new IP flow based on this value.
• Precedence AVP: the order of applying the service data flow template consisting of service data flow
filters to the service data flow at PGW.
• Flows AVP: Indicator of the IP flow to which this PCC rule is to be applied .

<-har in - Rul e- lnst:all : 000003ebc0000lec0000 8af000003edcOOOOOOfO 002 a f ...

E AVP : char in - Rul - 0 fi nition 1003 l 92 f ='VM - vnd=TGPP
AVP code: 1003 charging- Ru l e- Def i nit i on
AVP Fl ags : 0xc0
AVP Llmgt.h: 492
AVP vendor I : 3GP P (10415)
8 Chargi ng - Rule- Defi nition: 000003edcOOOOOOf000028af 305f37.000000042iB0000064.
AVP: hargi ng-Rule-N me(lOOS) 1=15 f=v~ - vnd=TGPP val=30Sr32
~ AVP: F ow-In ormat1 on =V-- vn =TGPP
AVP code: 1058 Fl ow- Infor mation
AVP l as: Ox80
AVP Lengt h: 1-00
AVP vendor r d : 3-GPP (10415)
8 Fl ow-Informati on: 000004 88000001 00007 af 0000000100000lfbc0000046 . . .
AVP: Flow- Di rect ion(1080) 1 16 f - v-- vnd TGPP val 001,'NLINK (1)
.i AVP : Flo1v- oesc.ri tion 07 1=70 f =VM - vnd=TGP P val =oermic ouc i fro:n 10 . 7
AVP: Flm•- I nforrnat i on(1058 ) 1- 100 f =V-- vnd~TGPP
AVP: Flow-status (511) 1=1 6 r=VM- vnd=TGPP val =E~AB LED (2 )
- AVP: os-1:n or m;it1on =VM- vn =TGPP
A P c ode: .1016 QoS Information
A P Flags : Oxco
VP Length : 1.52
AVP vendor- Id : 3GPP (10415)
8 QoS-lnforma ion: 00000404c0000010 00078af 0000000100000402c0000010 .. .
.B AVP: Q05- Cl a ss - Iden·tifier(l028) l - 16 f - 'VM- vnd=TGPP val«QCLl (1 )
B AVP: Guar ant ed - Bitrace- UL(1026) 1=16 f =VM - vnd=TGPP val =l20000
JJ AVP: Guaranteed - Bi t r ate- DL(1025) 1~16 f VM- vnd TGPP val - 120000
.l'I AVP: Max-Reques1:ed -6ancfwi d t h- L(Sl 6) 1=16 f =VM- v d= GPP val=120000
AVP : Max-Requesi:ed-sandwi dt h-01 (5 5) 1=16 =VM- vnd=TGPP val=120000
.B AVP: Al 1ocation- Re1:ent ion- Priorhy (1034) 1=60 f - v-- vnd- TGPP

• val 302e323734 2e3139352d31

+I AVP: 0 1=44 f=VM- vnd=fGPP

Fig 10. AVPs of RAR

[52) The SGW/PGW initiates the EPS bearer creation procedure and responds with the Re-Auth-Answer(RAA) to the
PCRF.

• Access-Network-Charging-Address AVP : IP address of the network entity within the access network
performing charging.

• 3GPP-SGSN-MCC-MNC AVP: MCC and MNC of the access network.

• 3GPP-User-Location-lnfo AVP : UE's current location. It is composed of Tracking Area Identity (TAI) and E-
UTRAN Cell Global Identifier (ECGI) .

10/17
 B Diameter Protocol
Ver i ori: OxOl
Leng h: 368
!=lags : Ox40
command code: 258 Re-/lu·th
App l i a[ionid: 3 PP Gx (1677723ij )
Hop- b - op Identi ier: Oxbb~58cd3
End- o- End ldent i fi r: Ox6d8d61fa
onse Ti me : 0.005648000 seconds
s ess ion - I d(263) 1=72 J =-M- va I =mulsaexOOl. epc. mnc874. mcc405. 3gppnecwork . erg ;
origin-Hos,( 264 ) 1=52 f=-M- val =mulsaexOOl. epc. mnc 74. mcc40 . 3gppn twor k. er g
origin- Realm (296) 1 1 f --M- val epc. mnc87~ . mccllOS. 3gppn et1-1ork . e r g
Su ppor ced- Fearnres (628) 1- 56 f ~v:-i - vnd=TGPP
Re sul t- ode(2 8) 1=12 f=-M- al =OIAMETE R_SUCCtSS (2001 )
Access - ecwor k-Charg i ng-Address (501) 1=30 f =Vlo1- vnd=TGPP va 1=2405 : 200 : 310: 7 :
lP-CA - -rype(1027) 1- 16 f - llM - vnd- TGPP val - 3GPP- ~PS (5)
RAT-,ype(1032) 1 - 16 f - v-- vnd• TGPP va l - EUTRAN (10();1)
3GPP-SG5N-r-\ - -1~C(l8) 1=1 f=V-- nd=rGPP val=
9 AVP: 3GPP - s r - Locat ion- I nfo (22 ) 1=25 =V-- vnd=TGP P val=MCC (Republ i c
AVP cod : l 7 3GPP- er - Loc ati on- Tnf o
ii: AVP Flag s : 0x80
AVP Leng·th : 25
AVP vendor I d; 3GPP (10415)
3GPP- ~er -location- I nf o : 82 0006, OOOOlaJ l
Geographic Location Type; TAI and ECGI (130)
Tracking Are Idenri ty (TAI)
I± E- UTAAN el l Gl obal Ident i i er (fCGI)
Paddi n : 000000

Fig 11. AVPs of RAA

[53) The PCRF responds with the AAA to the P-CSCF.

B oiamerer Prorocol
ver sion: OxOl
Le ngrh: 272
1±1 Flags: Ox40
co mmand code: 265 AA
Appli carionl d: 3GPP Rx {16777236)
Hop-by-Hop Idenrifier : Ox9 0075010
End-re-End Idenrifier: Ox578a8f77
[Req uesr I n: 124]
rResoo nse Ti me: 0.020906000 seco nds l
1±1 AVP: session-Id (2 63) 1=41 f=-M- val=l0. 75.23.192;780;67179008;899
1±1 AVP: Res ulr-code (268) 1=1 2 f=-M- val=DIAMETER__SUCCESS (2001)
1±1 AVP: or i gi n- Hosr {264) l =5 2 f=-M- val= .pcrfOOl. epc. mnc . mcc
1±1 AVP: origin-Realm(296) 1=41 f=-M- val=epc.mnc . mcc . 3gpp nerwor
1±1 AVP: Auth- Appli car ion- I d(258) 1=12 f=- M- val=3GPP Rx (16777236)
1±1 AVP: supporred-Fearures ( 628) 1=5 6 f=V-- vnd=TGPP
1±1 AVP: I P-CAN-Type {1027) 1=16 f=VM- vnd=TGPP val=3GPP-EPS (5)
1±1 AVP: RAT--rype(1032) 1=16 f=V-- vnd=TGPP val =EUTRAN (1004)

Fig 12. AVPs of AAA

(54) Upon receiving the successful AAA from the PCRF, the P-CSCF continues the SIP signaling by forwarding the 183
Session In Progress towards the UE. The following snapshot shows headers of 183 Session In Progress captured on Gm
interface.

• P-Early-Media header: ind icator of whether the UE supports the early media mode. The early media
option has been disabled in the practice.
Refer to step#47 and step#48 for the detailed description for SIP headers.

11/17
 ra sess ion m 1c1ac1on rrorocol (1.83)
SL.il tu:.. - L i n~ : S.IP / 2.0 183 ses.!:. i OJl Ptog res s

..,., Vi a : SI P/ 2. 0 / TCP 100. 6d. 63 . 41: 5060; recei ved,,,,100. G4. 63. 41 branch=z9hG1bK32'5 7 3350 30smg; trans por t .,,TCP :
Fr- om: <t. e I :+91 702.107 524 3> ; ta9= 3 22 84 7383
.3 To: <t el:+ 7021 075-.394 >; ta.,g=mavodi-c-lOb- 32 - -f-ff-ttttf -_OOOC 295A7'iBA- 7e 7 e-c 997 00-1 e 0- 5-4694 52 e- 61
ca ll -TO : • S 89,1 7 Goll 00 . 64 . 6 3 .41
3 ( S eq : 1 f }.'VJT~
Req'IJi rP : 100rel
RSeq: 2
[cruncatertJ conracr: <Si p: o<l i - c - J.O~- Jl - l - ffffffff - re- t ;,s xoo1, i ms . 11111c . 11cc gppnff..,rk . org :
Allow~ Ut'l.)..\1 c , Nill) F Y, l NVI l E , I f O . Pl<AC.1<, , ACK, BYC. , Su OSCRI 8 E , 1-:.EGI EK , A:E f;Elft ,OPT I O~S . CANC[L , PU8L.tS1~ ,l"l' CS S
, Recor d Rout e : <s•ip: od1 o l Of l fffffff 2 fffffff f ~10 , ,s . 23, 197 : $060 ; s ;podi o lib 22 z 200; l r >
P- r a,.1 y Medi a.: inac r i vc
... P- M :..~ te d- 1de:nt ·lty: si p :-+ 702107 5394@·1ms .mrH.. .IBCC'. . 3gpµr1e: tMlr k...org
serv •r; / vl. 0 PCSCF/VL O-H O<l2 5010
P - l\t: tl!!.!:> - \''1:lWOd c:- 1nro : 3GPP - E: -lITR.;"1,N - mo; Ulr ..tn-cell- td- 3gµi:,- 00060001 all
Col'ltent-Tyµe: appl icdl 1011/ stip
content -Length: 364
8 1 es sage y
63 sess-ian Descr ipt i on Protocol

Fig 13. Headers of 183 Session In Progress

The following snapshot shows the SDP answer included in the 183 Session In Progress. The SBC is going to be a peer
node from UE's perspective . Given that, the IP address and port number represents the SBC to which the originating
UE shall connect for media. The codec information represents the one supported by the SBC. Refer to step#47 for the
detailed description for SDP attributes,

El Sess i on r ni,iation Pr orocol (18 )

cacus - Li n : I P/ 2 . 0 1 3 sess i on Progr ess
l!I l'le.ssage eader

- Sessi on O<?Scription Protocol

essi on o scri pt i on Protocol ver s ion (v) : O
,i o,,me / er a.to r, Sessi o n Id (o) : c - 0 - 2 5- 2 OZ722364.l.41025904.l. 141 0 2 59041 I N l P4 1
se ssi on Nd!Tle (s): ss VOIP
Sess i on Info r mat i on ( i ): A VOIP Sessi on
Connect i on I nformat:ion (c) : IN IP~ 10 . 7 5. 2 3.19 7
a; Time o c:rip i on, ac, i ve r i m ( t): () 0
+ ; Med i a Des cripti on , name and addr-=.ss (m) : aud i 1 05 70 r,. 1P/ AVP 110
IL Bdnd•li dt h rnformdtion (b) : A.S:31
O: Bandwidth Infor mat ion (b): RS: 387
Bandwidt:h Informat:ion (b): RR :11 62
Med i a Aru ibu re (a): ~endrecv
Med i a An.ibuce (<l): maxpc i n,e : 240
~ Medi a Attribute (d): pt i me :20
Med i a Atcr ibute (a): ms i : od i - 0 - 14d- e - 2- ffffffff - @1D, 5, 23. 1 97
J; Media Attribute (a): rt pmap : J.10 Al'R- WB/ 16000/ 1
~ Med i a ATTr i hu t e a : fmi:; : 11 octer-a l i n=,· modP -~et=1· mode-chan P-ca ahili =7

Fig 14. SDP answer in 183 Session In Progress

The SDP answer delivered to the originating UE shows the IP address is 10.7S.23.197 and port number is 10570, which
is depicted as [a] in Fig2.

[SS] The UE confirms that the 183 Session In Progress with SDP answer has been received safely by sending
SIP PRACK.

• RACK header: the sequence number the corresponding 183 Session In Progress and the SIP INVITE.

Refer to step#47 for the detailed description for other headers.

12/17
 - es ion tniciacion Pro ocol ( P K)
odi-c-lOh-32- -fff-ff-ff'f-@ rasxOOl . im . mn c .m cc . <JppnPl

P-Access- '1et:work- I nfo: 3GPP- -UTJ!.AN-TOQ ; ucr an-ce11-i d- 3 gpf)=d058 74 0 060 OJ al 1

.el:+ 7021075243> ;tag=3228•14 7383
~ To : <tel:+ 702107 53 4> ;tag= od i - c - 10b- 32-2-ffffffff -_OOOC295A75BA-7 e7e- c4899700 - l
- cseq: 2 PRACK
ca.17 - rn: &156894 7 6@100 . 64. 63. n
Ma.x- J:or-wa.rds: 70
od i O- lOf - 3 f ffff - 2- ffffffff . @10. 75.23 .1 97:5060; 1r ; s i pod i - O- llb - 2
- contact:: <Sip :. 7021075243@100 . 64 . 63. 41 : 5060>; , g. 3gpp. icsi - ref - .. urrt.",;3i\urn - 7%JA3gpp-
i a: SIP/ 2. 0/ UDP 100. 64 . 63. 41: 5060; branc~ z9hG4bK3401 77 3265smg; t:ransport:- UDP
content - Le ngth: O

Fig 15. Headers in SIP PRACK

(56) The 200 OK response to the SIP PRACKis received by the UE.

B sess i on rni ti tion Protocol (200)

'+I St:;,t u:;- L i ne: SlP 7. 7 0 C)
Message ti@a der
vi a : SIP/2 . 0 / T P 100 . 64 . 63 . 41: 5060 ; mav-udp-rporc=5060 : rpon=SOGO ; rece i ved~100 . 64 .
ffi From: e l :+ 7021075243> ; ag=322844 7383
a: To: -ct el : + 7021075394>; tag=mavod i - C- 1 0b- J2 - 2 - ffffffff - _OOOC295A756A - 7e e - c48 997
cal l - ID: 645689476@1 0 . 64.63.41
G: cseq: 2 PRACK
serve,· : /vl. o PCSc F/ vl. 0 - 140425010
on en - Length: O

Fig 16. Headers in 200 OK for PRACK

(57] The 180 Ringing provisional response is received by the UE. It indicates the voice call setup request is being
notified to the recipient. Refer to step#47 and step#48 for the detailed description for headers.

NOTE If the option tag 'l00rel' appears in the Require header, the UE shall acknowledge the provisional response by
sending PRACK. If it appears in Supported header, it is just informative.

El Session Initiation Protocol (180)

Catus - Li ne : SI P/ ?.O ISO Ringing

., i a : SI P/ 2. 0 / TCP 100 . 64. 63 . 41: 5060; re ceived=100. 64 . 63 . 41; branch=z9nG4bK3257335 030srng; u

~ ~rom: <rel: , 70210/ 243>;tag=3228447 83
~ To: <1:cl: c 7021075394>; t:a9~ odi - c- l Ob- 32 - 2- ffffffff _OOOC295A75BA- 7e7 e- c4899 700 ! Se
Cdll-ID : [email protected]<!.63.41
~ cseq: 1 1NVITr
~ (truncated]contact: <Si p: odi - c- lOb- 32 - 2- fffffiff -@ .ta.sxOOl. ims . mnc .mcc .3gpp
All : UPOAI F , ,' IO'rI~Y,lS'Vl l , t NFO ,PRA ,A ~.,wa , ue 1\16 ,RG(.1 R,I\E ~li.,OPlJ ON, N .,.
~ Record - Route: <Si p: odi - 0 -lOf- lff ttff - 2 -ffffftff . @10.75.23 . 197:5060: s i podi - 0-llb
P-Early-Medi a: inacti e
P-Ass rr ed-Tdenc1t:y: si p:+ 7021075394 ims .mnc .mcc . lgppnerwork.org
s upport ed: lOOr el
en1 r: /vl. o P SC F/ Vl . 0-14042 5010
ContenL- Length : 0

Fig 17. Headers in 180 Ringing

[58] The 200 OK response for the SIP INVITE is received by the UE. It indicates that the terminating user answered the
phone. Upon receiving the response, the UE allocates the media resource. Refer to step#47 and step#48 for the
detailed description for headers.

13/17
 B s ni t i at i o n P1·oro ol (200)
(" 2 . 0 200 OK

IP / 2 . 0/ P 100.64.63 . 41: 5060 ; rec ei ved=100. 4. 63 .4l;b anch=z9hG4bK325 733503

@ Fr om: <rel :+ 7021075243> ; ,ag~3 228447383
1!1 To: <te l:+ 70210 75394 > ; t ag = od i- c - 1 0b- 32 - 2- f ffff f ·ff - _ OOOC295A7 51lA- 7e 7e - c48997
call - IO: 6d)6 [email protected] . 63.41
@ cse q: 1 INVITE
Requ i re: t i mer
session-Expires : l800;r f reshe r =uac
s uppor ted : l00r el,t i mer
[ crunc ated] co tact: <S i p: odi - c-lOb - 32 - 2- fffffftf - @ c asxOOl . i ms . mnc . mcc
11 ow: Uf'DATI., NOT IFY , J NVlT!s , IN FO, PR.ACK , A(K , &YE , SU BSC RIBE ,REGISTER , RE:FE:R,OPT ION S ,
l!I Record- Route : -; p: od i - 0 - lOf - l'fffff ff- 2- f ff f ff ff - @10. 75. 23 .19 7 : 5060; si pod i
@ P-AS sened- rd rn: i,y: s i p:+ [email protected] ms.mnc .mcc . 3gppnecwork.org
ser ver : / Vl.0 P(SCF / vl.0- 1 404 2 5010
P-Acce 5-Necwork- rnfo : 3GPP-E- TAAN-iDO; ucran-ce 11 -i d- 3gpp= 000 OOOl al l
concenc - Len th: O

Fig 18. Headers in 200 OK for SIP INVITE

[59] The UE sends SIP ACK towards the terminating user. Refer to step#47 for the detailed description for headers.

~ e sion 1ni tiat i on Proroco1 (AC)

odi- c -10 b - 32-2 - tffffft -@ tas x001. i ms. mnc . mcc . 3gppnetwc

rn rrom: <tel: , 70 21075243> ; tag - J22844 73 8 3

@ To: el : -, 7 0210 75394> ; tag • od i - c - 10b - 32 - 2- ffffffff - _OOOC295 A75 BA- 7 c 7c - c4899700 - 18
rn cseq: 1 ACK
call-10 : 6456894 6@100 . 64 . 63.dl
M x-Forward.,,: 70
1,1 ~ ut:e : <sip: od i - 0-1 0 f - 3 fff ffff - 2 - ff ffff ff - 10. 75 . 23.1 7 : 5060 ;l r; i p d1-0 -1J b- 22
o nrac,; : <Si p:~ / 02l07~ 4 300 00 . 64. 03 . 41: OoO> ;+g . 3gpp. i s i-rPf= "ur n%3Au rn- 7%3A3<Jpp- s
@ Vi a : SJP/ . 0/ UOP 100.64 . 3.41 : 060 ; branch=Z9h<;4bK4 ] 396444 0smg;trans p ort=UDP
( onrenr - Lengrh: O

Fig 19. Headers in SIP ACK

Red Mouse

REFERENCES

[1] 3GPP TS 23.228, "IP Multimedia System (IMS); Stage 2", vll.4.0, Mar 2012
[2] 3GPP TS 24.229, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session
Description Protocol (SDP); stage3", vll .3.0, Mar 2012
[3] 3GPP TS 24.628, " ", vll.3.0, Mar 2012
[4] 3GPP TS 29.212, "Policy and Charging Control (PCC); Reference points", vl2 .6.0, Sep 2014
[5] 3GPP TS 29.214, "Policy and Charging Control over Rx reference point", vl2.5.0, Sep 2014
[6] IETF RFC7315, "Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for 3GPP", July 2014
[7] IETF RFC4028, "Session Timer in the Session Initiation Protocol (SIP)", Apr 2005
[8] IETF RFC3264, "A offer and answer model with the Session Description Protocol (SDP)", Jun 2002
[9] IETF RFC3262, "Reliability of the Provisional Responses in Session Initiation Protocol (SIP)", Jun 2002
[10) IETF RFC3608, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During
Registration", Oct, 2003

14/17
Last Updated: 26th Dec 2015

~~Xf: RED MOUSE A!Lf: 17..;l !i

2f~: IMS Access Gateway, IMS-ALG, SIP, VoLTE

13 comments:

0
Mihai S 8/9/15 20:22

VoLTE UEs are required to support SIP Preconditions.They may be disabled by the network.
However a preconditions call flow including SIP Update/ SIP OK also would be usefull.

On the other hand I haven't seen UE sending Session Progress in a VoLTE VoLTE call without preconditions.

cheers,
Mihai

Reply

Replies

0 RED MOUSE 9/9/15 09:40

Unfortunately, the UE that has been used in this test didn't support the precondition, which was also
strange to me. But, your remark is correct as the IR.92 mandates the support of SIP precondition
framework for VoLTE call setup to give better user experiences to subs. Thanks for your comment as
always.

Reply

0 Mihai S 9/9/15 19:36

Try Samsung S4,S5 or SG, they support preconditions. :)

Reply

Replies

0
RED MOUSE 9/9/15 21:19

I don't doubt it. Thanks~!

Reply

0 Unknown 13/7/16 14:59

I have one question that while registartion when AF sends AAR message to PCRF what is the use the MBR-UL/DL in
that message .

Reply

15/17
0 seshu 17/4/1714:13

Very informative article , thanks for publishing it.

Reply

0
Unknown 13/2/19 18:00

Very nice article but i want to understand the difference betweeen VIA, ROUTE & PATH headers. The explanation
seems almost same.
I mean what is the requirement of a ROUTE header in sip INVITE when the same information is available in VIA
header?

Reply

0
Unknown 9/5/19 17:06

In simple terms VIA is used to send back the responses and Route is used to send the future requests.

Reply

Unknown 14/10/19 22:50

0 why transport is mentioned as UDP with VIA in prack,200k,ack???

Reply

0
[email protected] 4/2/23 20:38

Thanks for sharing this information with us

Ip communications solutions easy configurable products

Reply

0
stuporous 6/10/23 00:07

This comment has been removed by the author.

Reply

0 stuporous 6/10/23 00:21

This comment has been removed by the author.

Reply

0
stuporous 6/10/23 00:22

Hi, I have a question. for a volte to volte call within home plmn where the MMTel TAS and serving S-CSCF is same
for the calling and the called party how does the TAS differentiate if the SIP INVITE from the S-CSCF is for
Originating number or for Terminating number.

Reply

16/17
To leave a comment, click the button below to sign in with Blogger.

SIGN IN WITH BLOGGER

Newer Post Home Older Pc

Subscribe to: Post Comments (Atom)

Simple theme. Powered by Blogger.

17/17