Individual Submission Amardeep Sinha INTERNET-DRAFT Sunil Kumar Sinha Expires:02/15/2007 August 14,2006 The SIP BLOCKED Response draft-sinha-sip-block-00.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 (2006). Abstract This document define a new response code, 4XX(BLOCKED), for a Session Initiation Protocol(SIP).This response code can used by User Agent Client(UAC)that it intensely does not want to have session with an incoming request with particular SIP services from particular domain. For example, UAC do not want to establish a session with an incoming request for video conference from particular domain. The existing mechanism in SIP do not provide any such facility to refuse a request based request URI, SIP application, media type and other SIP services. Individual Submission [Page 1] Internet-Draft The SIP BLOCKED Response August 2006 Table of Content 1. Introduction...................................................2 2. Terminology....................................................3 3. Scope..........................................................3 4. Definition.....................................................4 4.1. Full Blocked.............................................4 4.2. Partial Blocked..........................................5 4.3. Flow Diagram - Implementation Model of Blocking..........5 feature at UAC 5. UAS Behavior...................................................10 6. UAC Behavior...................................................10 7. 4XX Response Code..............................................10 8. Call flow......................................................11 8.1. Full Blocked.............................................11 8.2. Partial Blocked..........................................13 8.2.1. Interaction With initial INVITE having SDP.......14 8.2.2. Interaction With initial INVITE having no SDP....17 9. Interaction with other session initiation request..............20 9.1. Interaction with SIP Presence............................21 9.2. Interaction with Instant Message.........................22 9.3. Interaction with Replace headerfield.....................24 9.4. Interaction with OPTION request .........................26 10. IANA Consideration.............................................27 11. Security Consideration.........................................27 12. Acknowledgements...............................................27 13. Reference......................................................27 13.1. Normative References.....................................27 13.2. Informative References...................................28 14. Author’s Address...............................................28 1. Introduction The Session Initiation Protocol (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 call based on phone number, URI, domain, as well as based on the SIP applications like SMS,voice, video, codec 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 a SIP services. The SIP, currently, does not provide a response code that allows the UAS or a proxy acting on behalf of SIP Client(User) to indicate that the request was rejected because the callee doesn’t want to go ahead with sip session with specific application services with caller. In other word, SIP does not include a response code that could be sent across to a caller informing him that the callee will not accept the invitation for the intended service.with the caller. Individual Submission [Page 2] Internet-Draft The SIP BLOCKED Response August 2006 The closest response code is 403 (Forbidden), which denotes unauthorized access is prohibited. This does not inform the caller that the call was rejected because the invite originated from a specific phone number for a specific service which the callee had blocked from his side. As a permanent solution, this document defines a new 4XX (Blocked) response code, belonging to client error,. 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. Scope This document defines a new response code that will be sent across to the caller when the callee blocks certain applications, like INVITE, SUBSCRIBE, SUBSCRIBE, etc , originating from specific URI (SIP URI/ TEL URI), specific domain, or from specific host. In other words this proposition says how a callee can set his profile and not accept incoming SIP request. It is basically a implementation of “Do not Disturb” terminology in SIP. The 4XX response code sent against blocked incoming requests can be classified based on the blocking of the SIP application’s services at various levels. The Blocking capabilities levels are listed below: 1) Blocking at user level. 2) Blocking at domain level. 3) Full blocking as well as partial blocking. 4) 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. 5) Decision of Blocking is taken at UAC only. Proxies do not have to perform any kind of processing. 6) Broadcast message cannot be blocked. 7) Caller could know that a particular SIP services is blocked,by receiving final 4XX response to its request. 8) Current on-going SIP session will not be affected, if the activation or deactivation is done during session, only for the participants involved in the session. But users who are likely to Individual Submission [Page 3] Internet-Draft The SIP BLOCKED Response August 2006 establish a new SIP session with the participants in an already existing session will be effected even if the blocking is done during a SIP session with another party. For example, assume three end points 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, he will be responded to with a 4XX response that he is blocked to establish such a connection with B. 9) Quality of Service: To make an outgoing SIP call, SIP request is sent with a list of codec, in an order that is preferred by the User. In the same way by using this feature, the user can choose the codec. That is, if a user is willing to go for good quality of voice. 4. Definition The BLOCKING feature enables a subscriber to block an unwanted invite for communication. This feature is to be present at the User side from where the UAC can configure using "BLOCKING" option on its gui, for GUI based SIP client or through the command line interface (CLI) option for non-gui based SIP Client. Also, this Blocking feature, would be contains more option for a User to wherein he could do more enhanced blocking like Codec blocking, request blocking, and other SIP services as mentioned and discussed in the subsequent session below. A 4XX (Blocked) is a response that will indicate that the UAS refuses to fulfill the incoming request because it was blocked. The default reason phrase is ‘Blocked’. There are two types of Blocking: 1. Full Blocking. 2. Partial Blockeing. 4.1 Full Blocking When a User wants to block a call from a particular URL and/or SIP services arising from URL, he can use this “Full Block” methodology to do so. The Full Blocking feature is applicable in the following scenario. When a User wants to block a call from a particular domain, he can use this “Full Blockage” option to do so. The UAC just has to configure "*" against blocking option followed by that domain name, Individual Submission [Page 4] Internet-Draft The SIP BLOCKED Response August 2006 like "*@domain_name" against blocking option. Whenever a call lands from that domain, it will be rejected and a 4XX response code will be sent across to notify the caller that he was completely blocked from reaching this particular callee. Similarly when a User wants to block a call from a particular phone or SIP phone, he can use this “Full Blockage” option to do so. The UAC just has to configure or for SIP devices against blocking option, like "9845661514” phone number or ‘User_A@domain_name.com, against blocking option. Whenever a call lands from blocked phone, it will be rejected and a 4XX response code will be sent across. Similarly when a User wants to block incoming Instant Message, he can use this “Full Blockage” option to do so. The UAC just has to configure “MESSAGE”,against blocking option. Whenever a call lands from the blocked phone, it will be rejected with 4XX response code. Whereas if UAC wants a complete blocking of incoming PSTN request from certain location , then UAC only need to configure location area code against blocking option, like “+9180*” will block all in coming request from city Bangalore of India. 4.2 Partial Blocking When a User wants to block a call from a particular URL and/or SIP services, he can use this “Partial Blockage” methodology to do so. This would mean that if the user does not wish to accept a certain type of media session from a particular caller or URL, say video, he can do so using the partial blocking option. The Partial Blocking feature is explained fully with some examples in section 8.2. For example, if UAC wants to block only Instant Message from some particular SIP client, then UAC configures his blocking option like followed by IM” against blocking option. With this, UAC can receive all request coming from User A, but all IM originating from User A will be rejected. 4.3 Flow Diagram – 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. Individual Submission [Page 5] Internet-Draft The SIP BLOCKED Response August 2006 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 | Check incoming SIP |---------------+ | method/request | | +-----------------------+ | | | V Partial Match | | 4XX Blocked Response found | No Match (Full Blocked) V V Step 3------> +-----------------------+ | Request URI is |Complete Match found | compared against |---------------+ | blocking list | | +-----------------------+ | | | V Partial Match | | 4XX Blocked Response found | No Match | / \ | | / \ | V/ If \V /SDP is \ no SDP /Present \ Yes - SDP present Step 4 +------------\in Request /-------------+ | \ / | V \ / | 4XX Blocked Response \/ | (with require=SDP) V / \ / \ /Check If\ /Blocked SIP \ No Match /Services matches\ Step 5 -------> +-------------- \ with SDP / | \ Parameter / | \ / | \ / | \ / V \/ Successful Response | Match found of Request V 4XX Individual Submission [Page 6] Internet-Draft The SIP BLOCKED Response August 2006 Figure 1. Flow Diagram 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. Table 1. +------------------------------------------------------------------+ |Processing | Action | Description with examples | | Steps | | | +------------+------------+----------------------------------------+ |Step 1 |Check if any|For any incoming SIP request, UAS first | | |Blocking |check whether the Blocking feature is | | |feature is |activated or not. If it is not activated| | |activated |then,the UA will proceed as per RFC-3261| | | |otherwise it will go into second step | +------------+------------+----------------------------------------+ |Step 2 |In this step|As Blocking profile is activated, | | |the incoming|therefore mapping needs to be done.Since| | |SIP request |a User can block any SIP method,phone | | |methods are |number, domain name on his SIP Client/ | | |map with the|device as per his wish. | | |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 map | | | |this, which is done is step 2. | | +-------+------------+----------------------------------------+ | |Case 1 | 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 only blocked IM and INVITE or any | | | combination. | | | | | |Complete match found means that the User has only | | |configured the SIP method 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. | | +------+-----------------------------------------------------+ Individual Submission [Page 7] Internet-Draft The SIP BLOCKED Response August 2006 -------------------------------------------------------------- | |Case 2| 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 INVITTE with some options | | | like particular phone number | | |(iii) if user B has blocked INVITTE with some options| | | like video session | | | | | |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 3 |No Match found | | +-------| | | |This case can occur in following scenario like | | |(i) if user B might have blocked Video | | |(ii) if user B might have blocked application and | | |text | | |(iii) if user B might have blocked FAX | | | | | |Means that no SIP method has been blocked by the User| | |.It doesn’t 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 1 |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 2 |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 | Individual Submission [Page 8] Internet-Draft The SIP BLOCKED Response August 2006 | | 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 3 |No Match | | --------| | | |(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 | | |parameterSo 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 a SDP capabilities in this incoming SIP| | |request | | |-------------------------------------------------------------| | |Case 1 |No SDP | | |-------| | | |Means that the incoming SIP request doesn’t contains | | |SDP protocol. | | | | | |Since the User has configured some blocking parameter| | |releated to SDP parameters, which is needed to be | | |verfired with the SDP parameters of the SIP request. | | | | | |So it generated 4XX response code with require header| | |field, as a mandatory parameter.The require header | | |filed values should be set to=SDP | | |-------------------------------------------------------------| | |Case 2 |Yes- SDP Present | | --------| | | |UAC moves to next processing step 5, for further | | |matching on SDP parameters. | -------------------------------------------------------------------| |Step 5 |Check If Blocked SIP services matches with SDP | | |parameters. | | |-------------------------------------------------------------| | |Case 1 |No match found | | --------| | Individual Submission [Page 9] Internet-Draft The SIP BLOCKED Response August 2006 | |Proceed as per RFC 3261This is because the configured| | |blocking parameters doesn’t match with incoming SDP | | |of SIP request | | |-------------------------------------------------------------| | |Case 2 |Match found | | --------| | | |It generates the 4xx response code (Blocked ) to | | |indicate the caller that the he blocked with this SIP| | |request. | -------------------------------------------------------------------- 5. UAS Behavior A UAS described below is a SIP UAS that receives SIP request with SDP and return a 4XX (Blocked) response. A SIP UAS while responding with a 4XX (Blocked) response to an Invite without SDP MUST add the ‘required’ header with ‘SDP required’ as header field value. 6. UAC Behavior A SIP UAC receiving a 4XX(Blocked) response for a request originated from it, MAY retry the request. It SHOULD only do so if it obtains a confirmation from the callee that this is desirable. Such confirmation could be obtained through a ‘required’ header of the 4XX (Blocked) response. So, if Originating SIP client receives 4xx (Blocked) response with ‘require’ header filed value=SDP, he it could resent the request with SDP. A UAC that does not understand a 4XX (Blocked) response, will interpret it as a 400 response, for backward compatibility. 7. 4XX Response Code The 4XX response code, as it is related to client error so 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. The Full Blocked and Partial Blocked column relate to the presence of a header field in the response: Individual Submission [Page 10] Internet-Draft The SIP BLOCKED Response August 2006 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. 8. Call Flow This section explains a detailed call flow between two SIP User-Agents (Alice and Bob). Alice (sip:alice@atlanta.example.com) 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. 8.1 Full Blocked In this following example scenario, Bob has Full Blocked the Alice's phone number. In other word Bob don't 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. Individual Submission [Page 11] Internet-Draft The SIP BLOCKED Response August 2006 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 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 F2 183 Session Progress Bob -----> Alice SIP/2.0 183 Session Progress Individual Submission [Page 12] Internet-Draft The SIP BLOCKED Response August 2006 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 all the 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 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 8.2 Partial Blocked Individual Submission [Page 13] Internet-Draft The SIP BLOCKED Response August 2006 8.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 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 Individual Submission [Page 14] Internet-Draft The SIP BLOCKED Response August 2006 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 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 all the 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 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 Individual Submission [Page 15] Internet-Draft The SIP BLOCKED Response August 2006 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: 1 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 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: 1 INVITE Content-Length: 0 /*This time Alice gets a successful response which fulfills Bob's requirement. The successful response is generated because Bob has blocked audio sessions with Alice and not video sessions. Individual Submission [Page 16] Internet-Draft The SIP BLOCKED Response August 2006 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: 1 INVITE Content-Length: 147 v=0 o=bob 2890844527 2890844527 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 8.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. 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 * Individual Submission [Page 17] Internet-Draft The SIP BLOCKED Response August 2006 /* 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=9845661514 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=z9hG4bKijk ;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 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 which 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=z9hG4bKijk ;received=192.0.2.101 Max-Forward: 70 To: Bob ;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 Individual Submission [Page 18] Internet-Draft The SIP BLOCKED Response August 2006 ACK sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bKxyz 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. 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: 1 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: 1 INVITE Content-Length: 0 Individual Submission [Page 19] Internet-Draft The SIP BLOCKED Response August 2006 /* 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: 1 INVITE Reason: Your call is Blocked Required: SDP Content-Length: 0 9. 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 | | | | +-------------------------+------------------------+ Individual Submission [Page 20] Internet-Draft The SIP BLOCKED Response August 2006 ---------------------------------------------------- | SUBSCRIBE | Yes | | | | +-------------------------+------------------------+ | PRACK | No | | | | +-------------------------+------------------------+ | UPDATE | Yes | | | | +-------------------------+------------------------+ | INFO | No | | | | +-------------------------+------------------------+ | REFER | No | | | | +-------------------------+------------------------+ | MESSAGE | Yes | | | | +--------------------------------------------------+ 9.1 Interaction with SIP Presence Presence protocol which 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 notifier 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. 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 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. Individual Submission [Page 21] Internet-Draft The SIP BLOCKED Response August 2006 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 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 > 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 9.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 Individual Submission [Page 22] Internet-Draft The SIP BLOCKED Response August 2006 may possible that the user is not willing to receive IM(Instant Message), 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. 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 Individual Submission [Page 23] Internet-Draft The SIP BLOCKED Response August 2006 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=z9hG4bK123 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=z9hG4bK123 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 9.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 a 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. Individual Submission [Page 24] Internet-Draft The SIP BLOCKED Response August 2006 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 * 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 > 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 F4 183 Session Progress Bob -----> Alice SIP/2.0 183 Session Progress Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bK123 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 Content-Length: 0 Individual Submission [Page 25] Internet-Draft The SIP BLOCKED Response August 2006 /* 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 matchs, and thus it rejects this request with 4XX response. F5 4XX Block Bob -----> Alice SIP/2.0 4XX Block Via: SIP/2.0 TCP client.atlanta.example.com:5060;branch=z9hG4bK123 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 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. 9.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. Individual Submission [Page 26] Internet-Draft The SIP BLOCKED Response August 2006 10. 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 11. 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. 12. Acknowledgement The Authors would like to thank Amit, Ashish U, Divya Shah, Goldy, Kishan Pal and Vidyaramanan S for his contributions to this document. 13. Reference 13.1 Normative References [1] Bradner, S., "Key word for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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, Se[tember 2004. Individual Submission [Page 27] Internet-Draft The SIP BLOCKED Response August 2006 13.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. 14. 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, Inida. Phone:+919945313062 Email:sunilkumarsinha9@rediffmail.com Full Copyright Statement Copyright (C) The Internet Society (2006). 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. 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 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 Individual Submission [Page 28] Internet-Draft The SIP BLOCKED Response August 2006 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 29] Internet-Draft The SIP BLOCKED Response August 2006