SIP QoS
SIP QoS – RFC 3312 support
Release: 12.4(2)T
EDCS 322236(SFS)
Session Number
Presentation_ID
© 2005, Cisco Systems, Inc. All rights reserved.
1
What does QoS mean for SIP?
• Reserves call resources before call is
setup (reserve before ring).
• Utilizes Prack Method and UPDATE
method
2
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
SIP QoS Summary
• SIP IOS QoS history (icee to propel)
• Changes made by Propel project
• Configurations
• QoS call Flows
3
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
System Diagram
4
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
Sip QoS dependencies
• The SIP IOS gateway utilizes the IOS QoS module
which uses the rsvp subsystem in IOS.
• The QoS module provides APIs for SPIs, such as
SIP, to reserve bandwidth for a call.
• The QoS module was added by the Overture
project.
• Both SIP and H.323 uses this QoS module for
QoS calls.
5
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
QoS Module Overview
• Provides a set of APIs for SPIs use.
• SIP provides a callback function to the QoS modules. This is
how the QoS module informs SIP whether or not the
resources are reserved.
• QoS API:
QoS_Listen, QoS_Reserve, QoS_Modify, QoS_Cleanup
• Callback function:
ccsip_qos_callback_func – This is the function pointer which
the QoS module uses inform us of the reservation status. It
will indicate to us success or failure.
6
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
From ICEE to Propel
When ICEE implemented IOS SIP QoS the
draft <draft-manyfolks-sip-resource01.txt> was followed. This draft called for
the use of reliable provisional responses
and the use of the COMET (Conditions
MET method).
7
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
PROPEL QoS
During the Propel timeframe, RFC 3312 was out
and we decided to update our QoS
implementation. The main part of this was
making changes to the SDP library and using the
UPDATE method instead of COMET. No changes
were done with interactions with the QoS
module. We continue to use the QoS API in the
same manner.
8
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
SIP QoS - Precondition
• SIP uses the concept of precondition to signal the
server to not to present the call or alert the callee
until certain preconditions are met.
Offerer includes an option tag “precondition” to signal on the
SIP signaling.
Includes the option tag in “Require” header if the desired
reservation strength is mandatory.
Includes the option tag in “Supported” header if the desired
reservation strength is none or optional.
• Since the QoS preconditions are media-stream
specific, the parameters are presented in SDP.
9
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
SIP QoS – Precondition (cont’d)
• Two different reservation state variables are used to track and to
meet/surpass the threshold;
one to present the existing condition,
current-status = "a=curr:" precondition-type SP status-type SP
direction-tag
the other desired condition to be met,
desired-status = "a=des:" precondition-type SP strength-tag SP
status-type SP direction-tag
• Each SIP element can request for confirmation/ notification when the
set preconditions are met. Has more significance from server point of
view.
confirm-status = "a=conf:" precondition-type SP status-type SP
direction-tag
where,
precondition-type = "qos" | token
strength-tag = ("mandatory" | "optional" | "none" | "failure" | "unknown")
status-type = ("e2e" | "local" | "remote")
direction-tag = ("none" | "send" | "recv" | "sendrecv")
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
10
SIP QoS – session establishment with e2e status
bob
Direction
Current
Desired
send
no
mandatory
recv
no
mandatory
alice
INVITE - precondition (SDP-Offer)
m=audio 20000 RTP/AVP 0
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
start
183 Session Progress (SDP-Answer)
m=audio 20002 RTP/AVP 0
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
start
RESERVATION (RSVP)
Done
UPDATE - (SDP-Offer)
m=audio 20000 RTP/AVP 0
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
Done
200 OK (SDP-Answer)
m=audio 20002 RTP/AVP 0
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
180 Ringing
Call Presented to user
11
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
PRACK Method
The PRACK method was first introduced into IOS
in the icee project. This is needed for QoS Call
Flows. The main intent of the PRACK request is
to confirm that the 18x response message was
received. It ACKs the 18x message. RFC 3262
(Reliability of Provisional Responses in SIP)
details the PRACK request. When PRACK was
implemented in IOS, this RFC did not exists. We
used <draft-ietf-sip-100rel-01.txt>
12
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
More on PRACK
Why do we need to be sure 183 was
received? Since the 183 in a QoS call flow
contains QoS information in the SDP it is
crucial that the UAC receives it as it
contains the data which is required to
start resource reservations.
13
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
Example INVITE with QoS
INVITE sip:111@172.18.201.177:5060 SIP/2.0
Via: SIP/2.0/UDP 172.18.197.154:5060;branch=z9hG4bK1425AE
Remote-Party-ID: <sip:7777@172.18.197.154>;party=calling;screen=no;privacy=off
From: <sip:7777@172.18.197.154>;tag=34BD10C-24B1
To: <sip:111@172.18.201.177>
Date: Wed, 19 Jul 2006 14:59:17 GMT
Call-ID: FC1FF85C-166D11DB-803187DA-E1971025@172.18.197.154
Supported: 100rel,timer,resource-priority,replaces
Min-SE: 1800
Cisco-Guid: 4215553831-376246747-2150402010-3784773669
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1153321157
Contact: <sip:7777@172.18.197.154:5060>
Expires: 1800
Allow-Events: telephone-event
Require: precondition
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 276
Presentation_ID
14
© 2005, Cisco Systems, Inc.
Company Confidential
INVITE example Continued
v=0
o=CiscoSystemsSIP-GW-UserAgent 8191 1321 IN IP4 172.18.197.154
s=SIP Call
c=IN IP4 172.18.197.154
t=0 0
m=audio 18344 RTP/AVP 0 19
c=IN IP4 172.18.197.154
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=ptime:20
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
15
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
QoS Headers and SDP
• In the INVITE, we see Require:
Preconditions. This lets the UAS know we
are mandating QoS and it must fail the call
if it cannot support this.
• In the SDP we see:
a =curr:qos e2e none
a=des:qos mandatory e2e sendrecv
The first attribute line indicates our current qos which is end to end and none since we have
yet to reserve the resources. The second line indicates what we want. In this case, it’s end
to end, sendrecv and mandatory.
16
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
Example 183 for QoS
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 172.18.197.154:5060;branch=z9hG4bK1425AE
From: <sip:7777@172.18.197.154>;tag=34BD10C-24B1
To: <sip:111@172.18.201.177>;tag=4EE323C-695
Date: Wed, 19 Jul 2006 14:53:33 GMT
Call-ID: FC1FF85C-166D11DB-803187DA-E1971025@172.18.197.154
Timestamp: 1153321157
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Require: 100rel
RSeq: 4461
Allow-Events: telephone-event
Contact: <sip:111@172.18.201.177:5060>
Require: precondition
Content-Type: application/sdp
Content-Length: 273
17
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
183 QoS SDP
v=0
o=CiscoSystemsSIP-GW-UserAgent 7851 1988 IN IP4 172.18.201.177
s=SIP Call
c=IN IP4 172.18.201.177
t=0 0
m=audio 17104 RTP/AVP 0
c=IN IP4 172.18.201.177
a=rtpmap:0 PCMU/8000
a=ptime:20
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
18
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
More on 183
In the 183, the require header also indicates it requires reliable provisional response support
i.e. PRACK the 18x. The SDP has these attributes:
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
The first indictates we have no current QoS. The second indicates it requires end to end QoS
with sendrecv. The 3rd indicates that it requires the UAC to let the UAS know that resources
have been reserved. This is done by sending an UPDATE.
19
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
Example UPDATE SDP for QoS
v=0
o=CiscoSystemsSIP-GW-UserAgent 8191 1321 IN IP4 172.18.197.154
s=SIP Call
c=IN IP4 172.18.197.154
t=0 0
m=audio 18344 RTP/AVP 0 19
c=IN IP4 172.18.197.154
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=ptime:20
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
The last two attribute lines indicate that the current QoS is established in the send
direction and the last indicates the desired level.
20
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
Example 200 OK SDP for UPDATE
v=0
o=CiscoSystemsSIP-GW-UserAgent 7851 1988 IN IP4 172.18.201.177
s=SIP Call
c=IN IP4 172.18.201.177
t=0 0
m=audio 17104 RTP/AVP 0
c=IN IP4 172.18.201.177
a=rtpmap:0 PCMU/8000
a=ptime:20
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
Here, we see the current QoS is both sendrecv and the desired is still mandatory and
sendrecv.
21
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
What next?
After the UPDATE transaction is complete
(reservations successful) the rest of the
call flow looks normal. At this time the
UAS would inform ccapi of the call.
22
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
Configuring QoS in IOS
First, QoS mandates PRACKs so make sure
they are enabled. By default, they are
enabled so nothing is needed there. It is
possible they are disabled so re-enabling
may be necessary. See the ICEE SUDS for
complete cli examples. It’s in EDCS74560.
23
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
More Configs
The dialpeers on both the UAC and UAS will need to be configured for QoS. This is not a
SIP specific cli as these cli’s are also used for H.323.
Whether the “des:qos“ attribute line in the sdp is optional or mandatory is determined by
the QoS configuration on the gateway. The gateway implementation shall use the QoS
configuration to determine whether to use des:qos attribute with mandatory or
optional tag for the SIP session. The configured values "req-qos" and "acc-qos" in
the dial-peer can be used to determine how the des:qos attribute line is used. The
following describes how “des:qos“ is set to mandatory or optional.
no “des:qos" in nsdp:
Both req-qos and acc-qos are configured to BestEffort.
What determines what is in the sdp?
If the desired qos (req-qos) is set to a value other than BestEffort,
"des:qos" attribute is made optional:
If the acceptable qos (acc-qos) is set to BestEffort,
“des:qos" is made mandatory:
24
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
QoS CLI example
dial-peer voice 333 voip
destination-pattern 333
session protocol sipv2
session target ipv4:172.18.201.173
incoming called-number 111
dtmf-relay rtp-nte
req-qos controlled-load audio
acc-qos controlled-load audio
25
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
Successful Call Flow
26
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
Unsuccessful QoS Call Establishment Reservation Failure @ OGW (w Strength Tag :
Mandatory)
27
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
Unsuccessful QoS Call Establishment Reservation Failure @ TGW (w Strength Tag :
Mandatory)
28
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
Unsuccessful QoS Call - Reservation
Failure @ TGW (w Strength Tag : Optional)
29
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
Midcall QoS Changes (w Strength Tag :
Mandatory | Optional)
30
Presentation_ID
© 2005, Cisco Systems, Inc.
Company Confidential
F0_7604_c1
© 2000, Cisco Systems, Inc.
31