Independent Submission Amardeep Sinha
INTERNET-DRAFT Sunil Kumar Sinha
Expires:02/15/2007 August 14,2006
The SIP BLOCKED Response
draft-sinha-sip-block-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas and its working groups.
Note that other groups may also distribute working documents as
Internet-drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsolete by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress".
This document may not be modified, and derivative works of it may
not be created, except to publish it as an RFC and to translate
it into languages other than English.
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on 02/15/2007
Copyright Notice
Copyright (C) The Internet Society (2007).
Abstract
This document defines a new response code, 4XX(Blocked), for the
Session Initiation Protocol (SIP). This response code can be
used by User Agent Client (UAC) that intentionally does not want
to have session with an incoming request from another user with
particular SIP services. For example UAC does not want to
establish a session with an incoming request for video
Individual Submission [Page 1 ]
Internet-Draft The SIP BLOCKED Response August 2006
conference from particular domain. The existing mechanisms in
SIP do not provide any such facility to refuse a request based
request Uniform Resource Identifier (URI), SIP application,
media type or other SIP services.
Table of Content
1. Introduction..................................................2
2. Terminology...................................................3
3. Definition....................................................3
3.1. Full Blocked ...........................................4
3.2. Partial Blocked.........................................5
3.3. Implementation Model of Blocking feature at UAC.........5
4. 4XX Response Code............................................10
5. Call flow....................................................10
5.1. Call flow of Full Blocked..............................11
5.2. Call flow of Partial Blocked...........................13
5.2.1. Interaction With initial INVITE having SDP......13
5.2.2. Interaction With initial INVITE having no SDP...16
6. Interaction with other session initiation request.............20
6.1. Interaction with SIP Presence...........................20
6.2. Interaction with Instant Message........................22
6.3. Interaction with Replace Header Field...................24
6.4. Interaction with OPTION request ........................26
7. IANA Consideration............................................26
8. Security Consideration........................................26
9. Acknowledgements..............................................26
10. Reference.....................................................26
10.1. Normative References....................................26
10.2. Informative References..................................27
11. Author’s Address..............................................27
1. Introduction
The SIP allows users to establish SIP sessions with various
capabilities. However, a user receiving such a request has no
option to block the call based on phone number, domain name etc.
This document proposes a way to block any incoming SIP request
based on phone number, URI, domain name, session parameter as
well as based on the SIP applications like INVITE, SUBSCRIBE etc.
The proposal is also to generate a valid 4XX response code that
would inform the calling party that the request is blocked for
such SIP services.
The SIP, currently, does not provide a response code that allows
the user agent server (UAS) or a proxy server, acting on behalf
of UAC to indicate that the request was rejected because the
callee does not want to go ahead with the sip session with
Individual Submission [Page 2 ]
Internet-Draft The SIP BLOCKED Response August 2006
specific application services with the caller. In other words,
SIP does not include a response code that could be sent across
to a caller informing that the callee will not accept the
invitation for the intended service with the caller.
The closest response code is 403 (Forbidden), which denotes
unauthorized access is prohibited. This does not inform
completely or give a complete picture to the caller that why the
call was rejected by callee.
As a permanent solution, this document defines a new 4XX
(Blocked) response code, belonging to client error. With the
introduction of this Call Blocked feature, the callee has more
control on the calls.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119
[1].
3. Definition
The Blocked feature allows the UAC not to receive or block a SIP
request and(or) a SIP request originating from specific URI or
from a specific domain name or a specific host with or without
certain session parameters like audio, video, etc at various
codecs level. When the SIP request is initiated by caller which
has been blocked by callee, then the calling party will receive
a 4XX (Blocked) response. The callee does not receive any
indication that a SIP call(or SIP request) attempt was made.
It is basically a implementation of a 'Do Not Disturb'
terminology for SIP.
A 4XX (Blocked) is a response that will indicate that the UAS
refuses to fulfill the incoming request because the call was
blocked. The default reason phrase is "Blocked".
Blocked feature SHOULD have following characteristic :
(a) The Call Blocked feature can be turned ON or OFF any time.
(b) Neither SIP Proxy server nor any other SIP entity has
anything to do with activation/deactivation of this feature,
i.e., it is implemented only at UAC side.
(c) Broadcast message pertaining for SIP protocol meant for
some urgency scenario, if there is, cannot be blocked.
Individual Submission [Page 3 ]
Internet-Draft The SIP BLOCKED Response August 2006
(d) Current on-going SIP session will not be affected if the
activation or deactivation is done during the session.
(e) Users who are likely to establish a new SIP session with
the participants who is in an already SIP session will be
effected even if the blocking is done during a SIP session
with another party.
(f) A UAC that does not understand a 4XX (Blocked) response,
will interpret it as a 400 response, for backward
compatibility.
For example, assume three SIP Client A, B and C. If A and B are
in a conversation and B tries to block incoming requests from A,
the effect is not immediate. The block will take effect from
the subsequent requests that A can possibly make with B. On the
contrary if B is in conversation with A and is trying to block C
the change will be immediate. This would mean that after A and
B finish the call and if C tries to establish a session with B,
then B will be responded with a 4XX (Blocked) response to C.
There are two types of "Call Blocked" feature based on telephone
number, domain name, URI etc with or without other criteria.
1. Full Blocked.
2. Partial Blocked.
3.1 Full Blocked
When a SIP Client blocked a specific telephone number, domain
name, URI etc without any criteria of session parameter then it
is called Full Blocked. The SIP Client has totally
rejected the call. This feature MUST also support wildcard ‘*’
pattern as explained below.
The Full Blocked feature is applicable in the following scenario.
(i) Blocked a specific telephone number: - A SIP Client blocks
a specific telephone number by configuring telephone number
against the Blocked option.
(ii) Blocked a range of telephone number: - A SIP Client blocks
incoming number beginning or ending with certain number.
(iii) Blocked all calls from a specific domain: - A SIP Client
blocks all calls coming from specific domain by
configuring wildcard ‘*’ against the Blocked option
followed by the domain name like *@<domainname>.
(iv) Blocked SIP services like Instant Message: - A SIP Client
blocks the Instant Message by configuring the SIP Service
Individual Submission [Page 4 ]
Internet-Draft The SIP BLOCKED Response August 2006
– ‘MESSAGE’, against the Blocked option.
In this case of Full Blocked feature, on receiving a 4XX
(Blocked) response the caller party comes to know that the
callee blocks the call. So the caller party could make another
attempt with different phone number to disturb the callee.
Hence resulting in invalidity of Full Blocked feature.
Considering the security aspect for the callee, the callee
can play a recorded message thereby the caller will not know his
call is getting rejected.
3.2 Partial Blocked
When a SIP Client block a specific telephone number, domain
name, URI etc with some session description criteria (like
media type = audio only or Method = IM (Instant Message) etc.) is
called Partial Blocked. The SIP Client has rejected the
call based on certain criteria.
For example if UAC wants to block only Instant Message from some
particular SIP client say User A, then UAC configures his
blocking option like <Request-URI_of_User_A> followed by IM
against blocking option.
With this, UAC can receive all requests except the IM coming
from User A.
3.3 Implementation Model of Blocking feature at UAC.
The Flow Diagram below explains how this Blocking Feature is to
be implemented in the SIP client. Each step in the flow diagram
describes the processing step at UAC on receiving the SIP request.
Incoming SIP request
|
+-------V---------------+ No
Step 1------> |Check if any Blocking |---------------+
|feature is Activated | |
+-----------------------+ v
| Proceed as per RFC 3261
|Yes
|
V
Step 2------> +-----------------------+ Complete Match found (case A)
| Check incoming SIP |---------------+
| method/request | |
+-----------------------+ |
| | V
| | 4XX Blocked Response
| | (Full Blocked)
Individual Submission [Page 5 ]
Internet-Draft The SIP BLOCKED Response August 2006
| |
| |
Partial Match | | (case C)
found (case B) | | No Match
V V
Step 3------> +-----------------------+
| Request URI is |Complete Match found
| compared against |---------------+
| blocking list | |(case D)
+-----------------------+ |
| | V
Partial Match | | 4XX Blocked Response
found | No Match
(case E) | / \ |(case F)
| / \ |
V/ If \V
/SDP is \
No SDP /Present \ Yes - SDP present
Step 4 +------------\in Request /-------------+
| (case G) \ / | (case H)
V \ / |
4XX Blocked Response \/ |
(with require=SDP) V
/ \
/ \
/Check If\
/Blocked SIP \
No Match /Services matches\
Step 5 -------> +-------------- \ with SDP /
| (case I) \ Parameter /
| \ /
| \ /
| \ /
V \/
Successful Response | Match found
of Request V (case J)
4XX
Figure 1. Implementation Model
Whenever the Blocking feature is activated and the incoming
request is received by the UAS it will have to check for the
Blocked parameter before proceeding with any SIP Processing.
The sequence of events on checking the blocked parameter is
explained in detail in Table 1.
Individual Submission [Page 6 ]
Internet-Draft The SIP BLOCKED Response August 2006
Table 1.
+------------------------------------------------------------------+
|Processing | Action | Description with examples |
| Steps | | |
+------------+------------+----------------------------------------+
|Step 1 |Check if any|For any incoming SIP request, UAS first |
| |Blocking |checks whether the Blocking feature is |
| |feature is |activated or not. If it is not |
| |activated |activate then, the UA will proceed as |
| | |per RFC-3261otherwise it will go to |
| | |step 2. |
+------------+------------+----------------------------------------+
|Step 2 |In this step|As Blocking profile is activated, |
| |the incoming|therefore comparison needs to be done. |
| |SIP request |Since a User can block any SIP method, |
| |methods are |phone number, domain name on his SIP |
| |compared |Client/ device as per his wish. |
| |with Blocked| |
| |Method |Since in any SIP request, the first |
| | |word of the request-line is a 'SIP |
| | |Method' name, that’s why we need to |
| | |first compare this, which is done is |
| | |here in step 2. |
| +-------+------------+----------------------------------------+
| |Case A | Complete match found |
| +-------| |
| |This case can occur in following scenario |
| |(i) if user B has only blocked IM |
| |(ii)if user B has only blocked INVITE |
| |(iii)if user B has only blocked SUBSCRIBE |
| |(iv)if user B has blocked IM and INVITE or any |
| | combination. |
| | |
| |Complete match found means that the User has |
| |configured the SIP method only as a blocking |
| |parameter.This Implies that User is not willing to |
| |handle that configured SIP Method. |
| |In this case, 4XX Blocked Response is generated. |
| +------+-----------------------------------------------------+
| |Case B| Partial Match found |
| +------| |
| |This case can occur in following scenario like |
| |(i) if user B has blocked IM with some options like |
| | particular Domain A. |
| |(ii) if user B has blocked INVITE with some options |
| | like particular phone number. |
| |(iii) if user B has blocked INVITE with some options |
| | like video session. |
| | |
Individual Submission [Page 7 ]
Internet-Draft The SIP BLOCKED Response August 2006
| |Partial match found means that User has configured |
| |some others blocking parameters along with SIP |
| |method. So it moves into other processing stage, as |
| |in step 3. |
| +-------+-----------------------------------------------------+
| |Case C |No Match found |
| +-------| |
| |This case can occur in following scenario like |
| |(i) user B might have blocked Video. |
| |(ii) user B might have blocked application and text.|
| |(iii) user B might have blocked FAX. |
| | |
| |Means that no SIP method has been blocked by the User|
| |. It does not means that the User has not configured|
| |other blocking parameter. So it moves into other |
| |processing stage, as in step 3. |
+------------+-----------------------------------------------------+
| Step 3 |In this Step, the Request URI of incoming message is |
| |map with the Blocked URI as a parameter. |
| +--------+-----------------------------------------------------+
| | Case D |Complete match found |
| +--------| |
| |(i) if the user B has configured some phone number |
| | 2222 against the blocking profile. |
| |(ii) if the user B has blocked some particular SIP |
| | like a@b.com. |
| | |
| |Complete match found means that either of the |
| |following two match is found. Either the User has |
| |only configured the SIP URI as a blocking parameter. |
| |Or User has blocked the SIP Method coming from some |
| |specific URI. In this case, 4XX Blocked Response is |
| |generated. |
| +-------+-----------------------------------------------------+
| |Case E |Partial Match found |
| +-------| |
| |(i) If User B has blocked Invite with codec g729 |
| |(ii)If User B blocked a@b.com uri with codec g711A |
| | Law |
| | Partial match found means that User has configured |
| | some others blocking parameters along with following|
| | cases- |
| | - has blocked SIP method with some media parameter |
| | - has blocked SIP URI with media parameter |
| | - has blocked both SIP method and SIP Uri with other|
| | media parameters.So it moves into other processing|
| | stage , as in step 4 |
| +-------+-----------------------------------------------------+
| |Case F |No Match |
| +-------| |
Individual Submission [Page 8 ]
Internet-Draft The SIP BLOCKED Response August 2006
| |(i) if user B has blocked Video only |
| |(ii) if user B has blocked FAX only |
| |(iii) if User has blocked FAX with some particular |
| | codec |
| |(iv) if User B has blocked FAX and Video both, etc |
| | |
| |Means that the User has blocked only some SDP |
| |parameter. So it moves into other processing stage, |
| |as in step 4. |
+------------+-----------------------------------------------------+
|Step 4 |If SDP is present in the SIP Request |
| | |
| |It is a decision making processing step, where our |
| |UAC looks for SDP capabilities in this incoming SIP |
| |request |
| +-------+-----------------------------------------------------+
| |Case G |No SDP |
| +-------| |
| |Means that the incoming SIP request does not contains|
| |SDP protocol. |
| | |
| |Since the User has configured some blocking parameter|
| |related to SDP parameters, which is needed to be |
| |verified with the SDP parameters of the incoming SIP |
| |request. |
| |So it generates 4XX response code with "require |
| |header" field, as a mandatory parameter. The require |
| |header field values should be set to=SDP by the |
| |caller in the request. |
| +-------+-----------------------------------------------------+
| |Case H |Yes- SDP Present |
| +-------| |
| |UAC moves to next processing step 5, for further |
| |matching on SDP parameters. |
+------------+-----------------------------------------------------+
|Step 5 |Check If Blocked SIP services matche with SDP |
| |parameters. |
| +-------+-----------------------------------------------------+
| |Case I |No match found |
| +-------| |
| |Proceed as per RFC 3261. This is because the |
| |configured blocking parameters does not match with |
| |incoming SDP of SIP request. |
| +-------+-----------------------------------------------------+
| |Case J |Match found |
| +-------| |
| |It generates the 4xx response code (Blocked ) to |
| |indicate the caller that its SIP request has been |
| |blocked. |
+------------------------------------------------------------------+
Individual Submission [Page 9 ]
Internet-Draft The SIP BLOCKED Response August 2006
4. 4XX Response Code
The 4XX response code, as it is related to client error, it
belongs to Client Error response category. This response may
or may not include reason header field with it, depending upon
the vendor implementation, except for the case in 8.2.2 section
where it is mandatory. Information about header field in
relation to 4XX(Blocked) response code(i.e. Full Blocked and
Partial Blocked)is summarized in Table 2.
Table 2.
+-----------------------------------------------------+
| Header Field | Full Blocked | Partial Blocked |
+----------------+----------------+-------------------+
| via | m | m |
+----------------+----------------+-------------------+
| to | m | m |
+----------------+----------------+-------------------+
| from | m | m |
+----------------+----------------+-------------------+
| max forward | m | m |
+----------------+----------------+-------------------+
| call-ID | m | m |
+----------------+----------------+-------------------+
| Cseq | m | m |
+----------------+----------------+-------------------+
| required | o | m |
+----------------+----------------+-------------------+
| reason | o | o |
+----------------+----------------+-------------------+
| Content Type | o | o |
+-----------------------------------------------------+
m: the header field is mandatory.
o: the header field is optional.
"OPTIONAL" means that an element MAY include the header field
in a response and a UA may ignore the same. A "MANDATORY"
header field MUST be present in a response and the header field
MUST be understood by UAC processing the response. Otherwise it
will be treated as a normal 4XX response.
5. Call Flow
This section explains a detailed call flow between two SIP User
-Agents (Alice and Bob). Alice (sip:alice@atlanta.example.com)
Individual Submission [Page 10]
Internet-Draft The SIP BLOCKED Response August 2006
and Bob (sip:bob@biloxi.example.com) are assumed to be SIP phone
or SIP-enabled devices. For simplicity in reading and editing
the document, only the minimum required header field set is
shown in below examples.
5.1 Call flow of Full Blocked
In this following example scenario, Bob has Full Blocked the
Alice's phone number. In other word Bob do not want to have any
kind of session with Alice. The UAC at Bob refuse to process
the INVITE request and reply with 4XX(Blocked) response to Alice.
Alice would have to send an ACK to Bob in order to properly
terminate the call.
Alice Bob
| INVITE F1 |
|----------------------------------->|
| |
| 183 Session Progress F2 |
|<-----------------------------------|
| |
| 4XX Blocked F3 |
|<-----------------------------------|
| |
| ACK F4 |
|----------------------------------->|
| |
* Rest of flow not shown *
/* The initial INVITE request generated by the UAC, Alice (F1),
might look like this
F1 INVITE Alice --> Bob
INVITE sip: sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bK123
Max-Forward: 70
To: Bob <sip:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=12345
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 INVITE
Content-Length: 151
v=0
o=alice 2890844526 12345 IN IP4 client.atlanta.example.com
Individual Submission [Page 11]
Internet-Draft The SIP BLOCKED Response August 2006
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F2 183 Session Progress Bob -----> Alice
SIP/2.0 183 Session Progress
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bK123
;received=192.0.2.101
Max-Forward: 70
To: Bob <sip:bob@biloxi.example.com>;tag=67890
From: Alice <sip:alice@atlanta.example.com>;tag=12345
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 INVITE
Content-Length:0
/* The UAS, Bob, checks the INVITE request. However, Alice's
phone number is Blocked. So he rejects the request with a 4XX
(Blocked) response code. It copies the entire mandatory header
from the request to the 4XX(Blocked)response and may also add a
'reason' header with a descriptive phrase. This 4XX(Blocked)
response is sent back to Alice. The response, F3, received at
Alice, might look like this
F3 4XX Block Bob -----> Alice
SIP/2.0 4XX Block
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bK123
;received=192.0.2.101
Max-Forward: 70
To: Bob <sip:bob@biloxi.example.com>;tag=67890
From: Alice < sip:alice@atlanta.example.com >;tag=12345
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 INVITE
Reason: Your call is Blocked
Content-Length:0
/* Alice has received the 4XX (Blocked) response to the INVITE
she sent across to Bob and she in turn will send an ACK in order
to terminate the call, which (F4) might look like this
F4 ACK Alice --> Bob
ACK sip:bob@biloxi.example.com SIP/2.0
Individual Submission [Page 12]
Internet-Draft The SIP BLOCKED Response August 2006
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bK123
Max-Forward: 70
To: Bob <sip:bob@biloxi.example.com>;tag=67890
From: Alice <sip:alice@atlanta.example.com>;tag=12345
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 ACK
Content-Length:0
5.2 Call flow of Partial Blocked
5.2.1 Interaction With initial INVITE having SDP.
The following example depicts that Bob has Partially Blocked
Alice's phone number for audio based requests. Alice tries to
establish an audio session with Bob ignorant of the block that Bob
had imposed on the requests that would arise from Alice’s phone.
Alice Bob
| INVITE F1 |
|----------------------------------->|
| |
| 183 Session Progress F2 |
|<-----------------------------------|
| |
| 4XX Blocked F3 |
|<-----------------------------------|
| |
| ACK F4 |
|----------------------------------->|
| |
| |
| INVITE F5 |
|----------------------------------->|
| |
| 183 Session Progress F6 |
|<-----------------------------------|
| |
| 200 OK F7 |
|<-----------------------------------|
| |
* Rest of flow not shown *
/* The initial INVITE request generated by the UAC, Alice(F1),
might look like this
Individual Submission [Page 13]
Internet-Draft The SIP BLOCKED Response August 2006
F1 INVITE Alice --> Bob
INVITE sip: sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bK123
Max-Forward: 70
To: Bob <sip:bob@biloxi.example.com>
From: Alice < sip:alice@atlanta.example.com >;tag=9845661514
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 INVITE
Content-Length: 151
v=0
o=alice 2890844526 12345 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F2 183 Session Progress Bob -----> Alice
SIP/2.0 183 Session Progress
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bK123
;received=192.0.2.101
Max-Forward: 70
To: Bob < sip:bob@biloxi.example.com >;tag=67890
From: Alice < sip:alice@atlanta.example.com >;tag=12345
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 INVITE
Content-Length: 0
/* The UAS (Bob) checks the INVITE request and finds that this
is a request for an audio session. Since Alice's phone number is
Partially Blocked, Bob will reject the request with a 4XX
(Blocked) response code. Bob copies the entire mandatory header
from the request to the 4XX (Blocked) response and may add a
'reason' header with a descriptive phrase. The response Alice
receives (F3) might look like this
F3 4XX Block Bob -----> Alice
SIP/2.0 4XX Block
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bK123
;received=192.0.2.101
Max-Forward: 70
To: Bob <sip:bob@biloxi.example.com>;tag=67890
From: Alice <sip:alice@atlanta.example.com>;tag=12345
Individual Submission [Page 14]
Internet-Draft The SIP BLOCKED Response August 2006
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 INVITE
Reason: Your call is Blocked
Required: SDP
Content-Length: 0
/* Alice receives the 4XX (Blocked) response to the INVITE
request she sent and generates an ACK in order to terminate the
call, which (F4) might look like the following
F4 ACK Alice --> Bob
ACK sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bK123
Max-Forward: 70
To: Bob <sip:bob@biloxi.example.com>;tag=67890
From: Alice <sip:alice@atlanta.example.com>;tag=12345
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 ACK
Content-Length: 0
/* Now Alice knows that Bob does not wish to establish an audio
session with her. So Alice tries again and this time sends a new
INVITE request for a video session.
F5 INVITE Alice --> Bob
INVITE sip: sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bKabc
Max-Forward: 70
To: Bob <sip:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=abc123
Call-ID: 12ka4@Atlanta.example.com
CSeq: 2 INVITE
Content-Length: 151
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=video 0 RTP/AVP 31 34
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000
Individual Submission [Page 15]
Internet-Draft The SIP BLOCKED Response August 2006
F6 183 Session Progress Bob -----> Alice
SIP/2.0 183 Session Progress
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bKabc
;received=192.0.2.101
Max-Forward: 70
To: Bob <sip:bob@biloxi.example.com>;tag=def6789
From: Alice <sip:alice@atlanta.example.com>;tag=abc123
Call-ID: 12ka4@Atlanta.example.com
CSeq: 2 INVITE
Content-Length: 0
/*This time Alice gets a successful response that fulfills Bob's
requirement. The successful response is generated because Bob
has blocked audio sessions with Alice and not video sessions.
F7 200 OK Bob -----> Alice
SIP/2.0 200 OK
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bKabc
;received=192.0.2.101
Max-Forward: 70
To: Bob <sip:bob@biloxi.example.com>;tag=def6789
From: Alice <sip:alice@atlanta.example.com>;tag=abc123
Call-ID: 12ka4@Atlanta.example.com
CSeq: 2 INVITE
Content-Length: 147
v=0
o=bob 2890844527 12345 IN IP4 client.biloxi.example.com
s=-
c=IN IP4 192.0.2.201
t=0 0
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
5.2.2 Interaction With initial INVITE having no SDP.
In the following example, Bob’s requirement is the same as
detailed in section 8.2.1. But Alice sends the INVITE without
SDP.
Individual Submission [Page 16]
Internet-Draft The SIP BLOCKED Response August 2006
Alice Bob
| INVITE (without SDP) F1 |
|----------------------------------->|
| |
| 183 Session Progress F2 |
|<-----------------------------------|
| |
| 4XX Blocked F3 |
|<-----------------------------------|
| |
| ACK F4 |
|----------------------------------->|
| |
| INVITE (with SDP) F5 |
|----------------------------------->|
| |
| 183 Session Progress F6 |
|<-----------------------------------|
| |
| 4XX Blocked F7 |
|<-----------------------------------|
| |
* Rest of flow not shown *
/* The initial INVITE request generated by the UAC, Alice(F1),
might look like this
F1 INVITE Alice --> Bob
INVITE sip: sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bK123
Max-Forward: 70
To: Bob < sip:bob@biloxi.example.com >
From: Alice < sip:alice@atlanta.example.com >;tag=asd1234
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 INVITE
Content-Length: 0
F2 183 Session Progress Bob -----> Alice
SIP/2.0 183 Session Progress
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bK123
;received=192.0.2.101
Max-Forward: 70
To: Bob < sip:bob@biloxi.example.com >;tag=zxc6789
From: Alice < sip:alice@atlanta.example.com >;tag=asd1234
Individual Submission [Page 17]
Internet-Draft The SIP BLOCKED Response August 2006
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 INVITE
Content-Length: 0
/* The UAS, (Bob), checks the INVITE request and finds that the
request has no SDP. Since, the Alice's phone number is Partially
Blocked, Bob rejects the request with a 4XX (Blocked) response
code along with a 'Require' header field that is mandatory in
case of Partially Blocked. It also copies all the mandatory
header information from the request and may add a 'reason' header
with descriptive phrase. This 4XX (Blocked) response is sent to
Alice. The response, F3, received by
Alice may look like this
F3 4XX Block Bob -----> Alice
SIP/2.0 4XX Block
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bK123
;received=192.0.2.101
Max-Forward: 70
To: Bob <sip:bob@biloxi.example.com>;tag=zxc6789
From: Alice <sip:alice@atlanta.example.com>;tag=asd1234
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 INVITE
Reason: Your call is Blocked
Required: SDP
Content-Length: 0
F4 ACK Alice --> Bob
ACK sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bK123
Max-Forward: 70
To: Bob <sip:bob@biloxi.example.com>;tag=zxc6789
From: Alice <sip:alice@atlanta.example.com>;tag=asd1234
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 ACK
Content-Length: 0
/* Now Alice knows that the INVITE request was without SDP and
Bob reject with 4XX(BLOCKED) response with 'Require' header field
= SDP,implies that there is a partial Blocked at Bob side. So
Alice again need to sends a new INVITE request with SDP to Bob in
order to establish the audio session. Note that Alice do not know
that Bob has blocked for audio session from him.
Individual Submission [Page 18]
Internet-Draft The SIP BLOCKED Response August 2006
F5 INVITE Alice --> Bob
INVITE sip: sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bKpqr
Max-Forward: 70
To: Bob <sip:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=mno1234
Call-ID: 12ka4@Atlanta.example.com
CSeq: 2 INVITE
Content-Length: 151
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F6 183 Session Progress Bob -----> Alice
SIP/2.0 183 Session Progress
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bKpqr
;received=192.0.2.101
Max-Forward: 70
To: Bob < sip:bob@biloxi.example.com >;tag=lkj6789
From: Alice < sip:alice@atlanta.example.com >;tag=mno1234
Call-ID: 12ka4@Atlanta.example.com
CSeq: 2 INVITE
Content-Length: 0
/* The Alice's request is rejected by Bob with 4xx Blocked
response,implies that Bob has intentionally blocked for Audio
session.
F7 4XX Block Bob -----> Alice
SIP/2.0 4XX Block
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bKpqr
;received=192.0.2.101
Max-Forward: 70
To: Bob <sip:bob@biloxi.example.com>;tag=lkj6789
From: Alice <sip:alice@atlanta.example.com>;tag=mno1234
Call-ID: 12ka4@Atlanta.example.com
CSeq: 2 INVITE
Reason: Your call is Blocked
Required: SDP
Content-Length: 0
Individual Submission [Page 19]
Internet-Draft The SIP BLOCKED Response August 2006
6. Interaction with other session initiation request.
In this section, we will be dealing with the interaction of this
BLOCKING feature with other SIP requests. Note all SIP request
will affected except few, as summarized below in a form of Table 3.
Table 3.
+--------------------------------------------------+
| INVITE | Yes |
| | |
+-------------------------+------------------------+
| ACK | No |
| | |
+-------------------------+------------------------+
| CANCEL | No |
| | |
+-------------------------+------------------------+
| BYE | No |
| | |
+-------------------------+------------------------+
| REGISTER | No |
| | |
+-------------------------+------------------------+
| OPTION | Yes |
| | |
+-------------------------+------------------------+
| NOTIFY | No |
| | |
+-------------------------+------------------------+
| SUBSCRIBE | Yes |
| | |
+-------------------------+------------------------+
| PRACK | No |
| | |
+-------------------------+------------------------+
| UPDATE | Yes |
| | |
+-------------------------+------------------------+
| INFO | No |
| | |
+-------------------------+------------------------+
| REFER | No |
| | |
+-------------------------+------------------------+
| MESSAGE | Yes |
| | |
+--------------------------------------------------+
6.1 Interaction with SIP Presence
Presence protocol that is mainly concerned about established
subscription ( or long-term relation ) between devices that
transfer status information and the delivery of the information.
As per the RFC 3265, the notify i.e., Bob when receives the
SUSCRIBE message, either he can accept or reject the message.
And as per implementation prospective is concern, the Bob need
to be present at the device end so that he could either reject
or accept the SUBSCRIBE request.
Individual Submission [Page 20]
Internet-Draft The SIP BLOCKED Response August 2006
On the counter part, with block feature enabled at the Bob
device "to not to receive SUBSCRIBE", let say for e.g. Blocked
all SUBSCRIPTION, then without being Bob to present at the
device end, the SUBSCRIBE request will get rejected with 4XX
(Blocked) response code.
In the call flow below, Alice name is added in a buddy list of
Bob, and at the same time Bob do not want to gives its status
info to Alice, so he blocks the SUBSCRIBE for Alice.
Alice Bob
| SUBSCRIBE F1 |
|----------------------------------->|
| |
| 183 Session Progress F2 |
|<-----------------------------------|
| |
| 4XX Blocked F3 |
|<-----------------------------------|
| |
* Rest of flow not shown *
F1 SUBSCRIBE Alice --> Bob
SUBSCRIBE sip: sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bK12345
Max-Forward: 70
To: Bob < sip:bob@biloxi.example.com >
From: Alice < sip:alice@atlanta.example.com >;tag=9845661514
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 SUBSCRIBE
Event: presence
Expire:600
Contact: <sip:alice@atlanta.example.com >
Content-Length: 0
F2 183 Session Progress Bob -----> Alice
SIP/2.0 183 Session Progress
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bK12345
;received=192.0.2.101
Max-Forward: 70
To: Bob < sip:bob@biloxi.example.com >;tag=l11111
From: Alice < sip:alice@atlanta.example.com >;tag=9845661514
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 SUBSCRIBE
Event: presence
Expire:600
Contact: <sip:alice@atlanta.example.com >
Content-Length: 0
Individual Submission [Page 21]
Internet-Draft The SIP BLOCKED Response August 2006
F3 4XX Block Bob -----> Alice
SIP/2.0 4XX Block
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bK12345
Max-Forward: 70
To: Bob < sip:bob@biloxi.example.com >;tag=l11111
From: Alice < sip:alice@atlanta.example.com >;tag=9845661514
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 SUBSCRIBE
Event: presence
Expire:600
Contact: <sip:alice@atlanta.example.com >
Content-Length: 0
6.2 Interaction with Instant Message
As per the RFC 3428, it does not say weather the user who has
received the Instant Message has finally read the message or
not. It may possible that the user is not willing to receive
IM, let say for e.g. from some specific SIP URI/Phone, then he
could Block it. Thereby when the SIP user who sends MESSAGE
request (i.e., IM) could know that his message has been
rejected due to Block (a step ahead, getting more information
on the status of message IM in lieu of getting either 200 or
202 response).
If Bob does not IM message from subscriber Alice, then Bob can
block the reception of Instant Message coming from Alice.
Alice Proxy Bob
| | |
| MESSAGE F1 | |
|-------------------->| |
| | |
| | MESSAGE F2 |
| |------------------------>|
| | |
| | 4XX Blocked F3 |
| |<------------------------|
| 4XX Blocked F4 | |
|<--------------------| |
* Rest of flow not shown *
Thus, on receiving F2 MESSAGE, the UAS at Bob checks for the block
feature. If user Bob wants partial blocking of message (IM) not
the full blocking, then he has to set the blocking profile with
=MESSAGE) parameter. Thus, on receiving F2 MESSAGE, Bob rejects
the incoming Instant Message by MATCHING method name and the
configured BLOCKING profile by 4XX response.
Individual Submission [Page 22]
Internet-Draft The SIP BLOCKED Response August 2006
F1 MESSAGE Alice ---> Proxy
MESSAGE sip: sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bKijk1
Max-Forward: 70
To: Bob < sip:bob@biloxi.example.com >
From: Alice < sip:alice@atlanta.example.com >;tag=9845661514
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 MESSAGE
Contact: <sip:alice@p.p.p.p>
Content-Length: 0
F2 MESSAGE Proxy ---> Bob
MESSAGE sip: sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bKijk1
Max-Forward: 69
To: Bob < sip:bob@biloxi.example.com >
From: Alice < sip:alice@atlanta.example.com >;tag=9845661514
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 MESSAGE
Contact: <sip:alice@p.p.p.p>
Content-Length: 0
F3 4XX Blocked Bob ----> Proxy
SIP/2.0 4XX Block
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bKijk1
Max-Forward: 70
To: Bob < sip:bob@biloxi.example.com >;tag=9945313062
From: Alice < sip:alice@atlanta.example.com >;tag=9845661514
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 MESSAGE
Content-Length: 0
Reason: Your call is Blocked
F4 4XX Blocked Proxy ---->Alice
SIP/2.0 4XX Block
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bKijk1
Max-Forward: 69
To: Bob < sip:bob@biloxi.example.com >;tag=9945313062
From: Alice < sip:alice@atlanta.example.com >;tag=9845661514
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 MESSAGE
Content-Length: 0
Reason: Your call is Blocked
Individual Submission [Page 23]
Internet-Draft The SIP BLOCKED Response August 2006
6.3 Interaction with Replace Header Field
Let us assume that the user Alice has three SIP devices, namely
Phone-1 and Phone-2 and the User Bob has blocked Alice's Phone-2
SIP device.
Let us consider a scenario that Alice is in an active SIP session
with Bob via using her Phone-1. User Alice wants to moves to a
different location, it keeps Bob at parking place.
When Alice again send new INVITE, with replace header field, from
her another SIP device Phone-2,then it receive 4XX Block response.
This will indicate that Alice the she is blocked via A-2 SIP
device.
Alice Alice Parking
phone1 phone2 Bob Place
| | | |
|<===============================>| |
| | | |
| Alice transfers Bob to Parking Place |
| | | |
|------------REFER/200----------->| *1 *2 |
|<--NOTIFY/200 (trying)-----------|--INVITE/200/ACK-->|
|<--NOTIFY/200 (success)----------|<=================>|
|------------BYE/200------------->| |
| | | |
| | | |
| Alice later retrieves call from another phone |
| | | |
| F3 |-INV w/Replaces->| |
| | | |
| F4 |<--183-----------| |
| | | |
| F5 |<----4xx---------| |
| | | |
* Rest of flow not shown *
( Call Flow of SIP session between Alice phone1 to Bob , then
call parking are not shown )
F3 INVITE Alice's Phone 2 ---> Bob
INVITE sip: sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bKijk1
Max-Forward: 55
To: Bob < sip:bob@biloxi.example.com >
Individual Submission [Page 24]
Internet-Draft The SIP BLOCKED Response August 2006
From: Alice < sip:alice@atlanta.example.com >;tag=9845661514
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 INVITE
Replace: to-tag=12345;from-tag=789001;call-ID=6666abcd
Contact: <sip:alice@p.p.p.p>
Content-Length: 151
( SDP not shown . .)
F4 183 Session Progress Bob -----> Alice
SIP/2.0 183 Session Progress
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bKijk1
Max-Forward: 70
To: Bob < sip:bob@biloxi.example.com >;tag=9945313062
From: Alice < sip:alice@atlanta.example.com >;tag=9845661514
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@p.p.p.p>
Content-Length: 0
/* Wherein the replace header field contains the dialogue-ids of
established session between Alice and Bob, and contact header
field contains the new device i.e., Alice's Phone2 location id.
Thus on receiving F3 message from device Phone-2,Bobs compares it
with its blocking feature, which match, and thus it rejects this
request with 4XX(Blocked) response.
F5 4XX Block Bob -----> Alice
SIP/2.0 4XX Block
Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bKijk1
Max-Forward: 70
To: Bob < sip:bob@biloxi.example.com >;tag=9945313062
From: Alice < sip:alice@atlanta.example.com >;tag=9845661514
Call-ID: 12ka4@Atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@p.p.p.p>
Content-Length: 0
Reason: Your call is Blocked
In this scenario, Alice could again send INVITE request to Bob via
her SIP device Phone-1, as still Bob is in parking place.
Here we have an advantage that suppose Alice wants Bob to
establish the SIP session explicitly with Alice via Alice's
Phone-2 device, then she could say to Bob to unblock Alice's
Phone-2 device via another SIP phone (in this example it could be
Alice's Phone-1). Then after if Bob do so, means unblocks the
Alice Phone-2, being in Parking place, then when Bob receives
INVITE with replace header field via Alice's Phone-2 device, a
successful session could be established.
Individual Submission [Page 25]
Internet-Draft The SIP BLOCKED Response August 2006
6.4 Interaction with OPTION request
Since OPTION method is often used in SIP signaling in order to
get the capabilities and discover the current availability.
The user agent or server responds to the request as it would to
an INVITE ( i.e., if it is not accepting calls, it would repond
with a 4xx or 6xx response). A success class (2xx) response can
contain Allow, Accept, Accept-Encoding, Accept-Language and
Supported headers indicating its capabilities.
Whereas those SIP client which has blocking capability 200 Ok,
with an additional header field, Call-Info header with the
field value BLOCKED indicating that the UAC has blocking
capability.
7. IANA Consideration
This section registers a new SIP response code according to the
procedure of RFC 3261.
RFC Number: RFC XXX
[NOTE TO IANA: Please replace 4XXX with the RFC number of
this specification].
Response Code Number: 4XX
Default Reason Phrase: Blocked
8. Security Consideration
This document, itself, is concerned with providing SIP session
participation with a negotiation mechanism for phone-number,
SIP URI, etc, by blocking other non-acceptable device. This
blocking feature mechanism gives an user client to have a
security measurement.
9. Acknowledgement
The Authors would like to thank Amit Mishra, Ashish Upadhyay,
Ashish Khare, Divya Shah, Goldy, Kishan Pal, Naresh G. and
Vidyaramanan S for his contributions to this document.
10. Reference
10.1 Normative References
[1] Bradner, S., "Key word for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Individual Submission [Page 26]
Internet-Draft The SIP BLOCKED Response August 2006
[2] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol" ,RFC 2327, April 1998
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M. and E.Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.
[4] Ed., B. Campbell, Rosenberg, J., Schulzrinne, H., Huitema,
C., Gurle, D., "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[6] Mahy, R., Biggs, B., Dean, R.,"The Session Initiation
Protocol (SIP) "Replace header", RFC 3891, September 2004.
10.2 Informative References
[7] Atkins, D. and G. Klyne, "Common Presence and Instant
Messaging Message Format", Work in Progress.
[8] Ed., G. Huston,De., I. Leuca,"OMA-IETF Standardization
Collaboration", RFC 3975, January 2005.
11. Author Address
Amardeep Sinha
Motorola India Pvt. Ltd.,
Marathalli, Bangalore,
India
Phone: +919845661514
Email: amardeep_sinha@rediffmail.com
Sunil Kumar Sinha
IP-Unity,
J. P. Nagar, Bangalore,
India.
Phone: +919945313062
Email: sunilkumarsinha9@rediffmail.com
Full Copyright Statement
Copyright (C) The Internet Society (2007).
This document is subject to the rights, licenses and
restrictions contained in BCP 78, and except as set forth
therein, the authors retain all their rights.
Individual Submission [Page 27]
Internet-Draft The SIP BLOCKED Response August 2006
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, (THE IEFT TRUST)
AND THE INTERENT ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHT OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PORPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other right that might be claimed
to pertain to the implementation or use of the technology described
in this document to the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implements or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Individual Submission [Page 28]