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 *@. (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 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 From: Alice ;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 ;tag=67890 From: Alice ;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 ;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 ;tag=67890 From: Alice ;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 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 ;tag=67890 From: Alice ;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 ;tag=67890 From: Alice ;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 From: Alice ;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 ;tag=def6789 From: Alice ;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 ;tag=def6789 From: Alice ;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 ;tag=zxc6789 From: Alice ;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 ;tag=zxc6789 From: Alice ;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 From: Alice ;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 ;tag=lkj6789 From: Alice ;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: 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: 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: 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: 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: 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: 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: 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: 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]