You are on page 1of 25

Session 2: SIP Extensions

SIP Extensions and Features


IETF Working groups
References
2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential Internal Use Only 1
SIP Features

Mid-call Changes
Call Hold
Caller Privacy
Call Transfer
Session Timer
T.38 Fax
Error Scenarios
Event Notification
DTMF Relay
QoS in SIP
SIP Security
NAT/Firewalls
Accounting, Authorization
Instant Messaging and Presence

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 2
Mid-Call Changes

What can change ?


Change of codec. (bandwidth efficiency)
Change of Media IP address or FQDN/port.
Start a new feature like T.38
How to communicate?
Re-INVITE: Send INVITE again with a modified version of
the offer (SDP)
UPDATE: Send UPDATE with a modified offer.

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 3
a=sendonly indicates call hold
c=0.0.0.0 and a=inactive also
can be used to initate hold

Call Hold
SIP UA1 SIP Proxy SIP UA2

INVITE
100 Trying INVITE
100 Trying

180 Ringing 180 Ringing


200 OK
200 OK
ACK ACK
2way RTP
INVITE (a=sendonly) INVITE (a=sendonly)
200 OK (a=recvonly) 200 OK (a=recvonly)
ACK ACK
INVITE (c=IN IP4 IP-UA2) INVITE (c=IN IP4 IP-UA2)
200 OK 200 OK
ACK ACK
2way RTP

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 4
Caller Privacy

Many ways of presenting the Calling name &


number information via SIP.
From header, Remote-Party-ID, GTD, QSIG/ISUP
mime attachment, INFO method, PAI .
The Remote-Party-ID is used to carry
calling/called information to the remote party.
draft-ietf-sip-privacy-04.txt

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 5
Remote-Party-ID Call flow

John calls a user at GW2. The call goes through the company proxy
which makes sure his name is not used when gw2 receives the
INVITE. This is done by the proxy changing the Remote-Party-ID
header. When GW2 issues a setup to the PSTN the calling name used
will be Company A instead of John.

GW Proxy GW2
INVITE
From: INVITE
John
<sip:1234@host.com> From:
Remote-Party-ID: John <sip:1234@host.com>
John Remote-Party-ID:
<sip:1234@host.com> Company A<sip:1234@host.com>

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 6
P-Asserted Identity

Defined in RFC 3325.


Network-asserted identity service
Defines a new header that can be asserted by a
proxy after authenticating the user
Passed to other trusted proxies
PAI data can be stripped by proxy before
forwarding SIP message to untrusted proxy, if
specified

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 7
PAI Call flow
John calls a user at GW2. Proxy authenticates INVITE and adds PAI to
forwarded INVITE, based on Proxy-Authorization header
GW Proxy GW2
INVITE
From:
John
<sip:1234@host.com>

407 Proxy Auth


Proxy-Authenticate: ....
realm="sip.cisco.com"

INVITE
Proxy-Authorization:
.... realm="sip.cisco.com
user=John" INVITE
From:
John <sip:1234@host.com>
P-Asserted-Identity:
John<sip:1234@host.com>

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 8
Call Transfer
SIP UA1 SIP UA2 SIP UA3
Originator Recipient Final Recipient

INVITE / 200 OK / ACK

URI to which call will be


2way RTP
transferred

REFER:
Refer-To: UA3
202 Accepted
INVITE

200 OK
NOTIFY 200 OK (Refer Success)

200 OK

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 9
SIP - REFER

REFER sip:b@agentland SIP/2.0


Via: SIP/2.0/UDP agenta.agentland;branch=z9hG4bK2293940223
To: <sip:b@agentland >
From: <sip:a@agentland >;tag=193402342
Call-ID: 898234234@agenta.agentland
CSeq: 93809823 REFER
Max-Forwards: 70
Refer-To: (whatever URI)
Contact: sip:a@agentland
Content-Length: 0

UAS responds with a 202 Accepted


The REFER method indicates that the recipient (identified by the Request-URI) should
contact a third party using the contact information provided in the request.

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 10
SIP Session Timer

Why we need it ?
The SIP Session Timer is basically a keep-alive mechanism for
established sessions, which helps avoid resources getting hung when
network failures occur.
This is a fundamental issue for large scale network deployments.
How it works
Basically, UAs send periodic re-INVITE or UPDATE requests (referred to
as session refresh requests) to keep the session alive. If a session refresh
request is not received before the interval passes, the session is
considered terminated. Both UAs are supposed to send a BYE, and call
stateful proxies can remove any state for the call.
Reference : RFC 4028

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 11
SIP Session timer (Contd.)

Session Timer Negotiation (How to determine Refresher/Refreshee)


Two new header fields, Session-Expires and Min-SE, and a new response
code, 422, are defined. Session-Expires conveys the duration of the
session, and Min-SE conveys the minimum allowed value for the session
expiration. The 422 response code indicates that the session timer
duration was too small.
The UAC sends out a request with the following headers
Supported: timer
Min-SE: 1800
The UAS (or any proxies), can insert a Session-Expires header indicating
the desired interval for Session refreshes. If the time in the Min-SE is not
long enough the UAS (or proxy) should return a 422.
The Session-Expires header field also contains a "refresher" parameter,
which indicates who is doing the refreshing - the UAC or the UAS.

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 12
T.38 Fax using SIP
Voice call established
Fax tone is detected this initiates re-INVITE
2 way media (RTP flowing)
to relay fax notification to other endpoint
V.21 preamble/CED detected
INVITE w/ T.38 SDP

200 OK

ACK
This re-INVITE follows normal SIP re-INVITE
Rules namely, Higher CSeq, same Call ID etc.
Transmit FAX This re-INVITE also has T.38 attributes in the
SDP.
INVITE (restores voice)

200 OK

ACK draft-ietf-sipping-realtimefax-01.txt
2 way media (RTP flowing) ITU-T T.38 Annex D, SIP/SDP Call
Establishment Procedures

OGW TGW
2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 13
SIP Error Responses

4xx: Client Error - the request


contains bad syntax or cannot be
fulfilled at this server
5xx: Server Error - the server failed to
fulfill an apparently valid request
6xx: Global Failure - the request
cannot be fulfilled at any server

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 14
SIP Error Scenarios (Callee busy example)

OGW TGW
(a) 486:
INVITE SIP/2.0 486 Busy here
Via: SIP/2.0/UDP 172.18.193.99:5060;branch=z9hG4bK776asdhds
From: "3100802" <sip:3100802@172.18.193.99>;tag=2C6B64-D3B
100 Trying To: <sip:3100801@172.18.193.100>;tag=43FEAF8-34C
Date: Fri, 06 Oct 2000 20:01:10 GMT
Call-ID: EA6D7C0F-9AF811D4-8008FE5D-E29FD0D0
486 User Busy (a) Timestamp: 970861897
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Allow: UPDATE
Allow-Events: telephone-event
Content-Length: 0

Figure 1: Callee is Off Hook

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 15
SIP Error Scenarios (Media issue example)
TGW (a) INVITEs SDP:
OGW v=0
o=CiscoSystemsSIP-GW-UserAgent 1329 1720 IN IP4
INVITE w/SDP (a) 172.18.193.99
s=SIP Call
INVITE is requesting for Codec G711ulaw. c=IN IP4 172.18.193.99
Payload type: 0 t=0 0
m=audio 17126 RTP/AVP 0 100
100 Trying c=IN IP4 172.18.193.99
a=rtpmap:0 PCMU/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
488 Not Acceptable Media (b) a=ptime:20

(b) 488:
TGW configured for G.729 SIP/2.0 488 Not Acceptable Media
Payload Type: 18 Via: SIP/2.0/UDP
172.18.193.99:5060;branch=z9hG4bK776asdhds
From: "3100802" <sip:3100802@172.18.193.99>;tag=3101E0-15D2
To: <sip:3100801@172.18.193.100>;tag=4448180-899
Date: Fri, 06 Oct 2000 20:06:11 GMT
Call-ID: 9DA3C742-9AF911D4-800FFE5D-
E29FD0D0@172.18.193.99
Timestamp: 970862198
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Allow: UPDATE
Allow-Events: telephone-event
Content-Length: 0
2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 16
Accounting (Gateway)
Originating GW Radius
Terminating GW
Server

INVITE

100 Trying

180/183 Ringing
200 OK

Start Record
Written
ACK

Stop Record
Written
BYE
200 OK

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 17
Accounting (Proxy)
SIP UA Radius SIP UA
Proxy Server w/
Record-Route On Server

INVITE INVITE

100 Trying
100 Trying

180/183 Ringing
180/183 Ringing
200 OK

Start Record
200 OK Written

ACK
ACK
BYE

Stop Record
Written
BYE

200 OK 200 OK

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 18
Authentication
SIP UA Radius/ SIP UA
MySQL

INVITE

407 Proxy Authentication Challenge string (nonce)


Proxy-Authenticate:
ACK
INVITE Credentials
Proxy-Authorization:
100 Trying INVITE

100 Trying

180 Ringing
180 Ringing

200 OK 200 OK

ACK ACK

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 19
Event Packages

Registrations
Dialog State
Conference State
Message Summary & Message Waiting
Indication
Telephony Events (DTMF Digits)

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 20
SIP - SUBSCRIBE

SUBSCRIBE sip:rohan@vmail.cisco.com SIP/2.0


Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
To: <sip:rohan@cisco.com >
From: <sip:rohan@cisco.com >;tag=78923
Date: Mon, 10 Jul 2000 03:55:06 GMT
Call-Id: 1349882@rmahy-phone.cisco.com
CSeq: 4 SUBSCRIBE
Contact: <sip:rohan@rmahy-phone.cisco.com>
Event: message-summary
Expires: 86400
Accept: application/simple-message-summary
Content-Length: 0

Notifier responds with a 200 OK


Subscriber User Agents will typically SUBSCRIBE to message summary information for a
period of hours or days, and automatically attempt to re-SUBSCRIBE when the subscription
is half-expired(similar to DHCP).

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 21
SIP - NOTIFY

NOTIFY sip:rohan@rmahy-phone.cisco.com SIP/2.0


Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
To: <sip:rohan@cisco.com >;tag=78923
From: <sip:rohan@cisco.com >;tag=4442
Date: Mon, 10 Jul 2000 03:55:07 GMT
Call-Id: 1349882@rmahy-phone.cisco.com
CSeq: 20 NOTIFY
Contact: <sip:rohan@vmail.cisco.com >
Event: message-summary
Subscription-State: active
Content-Type: application/simple-message-summary
Content-Length: 45
Messages-Waiting: yes
Voicemail: 2/8 (0/2)
Subscriber responds with a 200 OK
Immediately after a subscription is accepted, the Notifier MUST send a NOTIFY with the
current message summary information. This allows the Subscriber to resynchronize its state.
When the status of the messages changes, the Notifier SHOULD send a NOTIFY message
to all active subscribers to that account.

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 22
DTMF Relay

Two methods Inband or Out-of-band.


Inband-way: DTMF tones are transported inband, and encoded in the
same way as voice traffic. Would work fine for high bit-rate codecs
like G.711 but not for low bitrate codes like G.729 and G.723.
Out-of-Band way: RFC2833 (in media), NOTIFY/INFO (in signaling
path).
RFC 2833 section 3 defines formats of Named Telephony Event
(NTE) RTP packets used to transport DTMF digits, Hookflash and
other telephony events between two peer endpoints.
Typical applications - SIP phones calling voice mail or other IVR
system.

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 23
DTMF-Relay: (RFC2833 or AVT way)

SDP Body looks like (EXAMPLE 1):


INVITE sip:9193923873@cisco.com
SIP/2.0
...
...
m=audio 3456 RTP/AVP 0 105

a=rtpmap:0 PCMU/8000
a=rtpmap:105 telephone-event/ 8000
a=fmtp:105 0-16

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 24
DTMF-Relay : AVT (Contd.)

Here 105 as the payload value selected at the CLI and NTE
was selected as dtmf relay method
The a=fmtp attribute carries the tone range handling
capability.
The remote end responds with a 180/183/200 OK with its
capabilities.
If the remote end is not configured for the same dtmf relay
method, Inband method is used.
If the remote end uses the same dtmf relay method, then it
uses the same payload type

2002, Cisco Systems, Inc. All rights reserved. Cisco Confidential - Internal Use Only 25

You might also like