Network Working Group                                        Vidyut Gupta
Internet-Draft                                               India
Expires: Feb 19, 2011                                        Aug 19 2010

SIP Forum - Message Body in SIP REGISTER Message
            draft-vidyut-sip-message-body-in-register-00.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and 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 obsoleted 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."

   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 Feb 19, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Abstract

In SIP, Register never carries any message body, but a lot of things can be simplified by allowing 
the one. User can configure their call preferences at any moment by just sending a Register message. In present
scenario when users are becoming more and more demanding it's perfectly logical to allow them to configure 
their call preferences dynamically. The present draft present two such call preferences requested by
user - call barging and advertising unavailability. It can, however, be extended for other scenarios as well.


Introduction

Most of the times when we get out of the town or do not want to
attend the calls from some particular callers e.g. credit card sellers, 
we always wish some how our service provider could block these calls. 
In SIP this could be done by using the REGISTER message and sending the 
message body which describe type of incoming call barging UA needs. 
Similarly while going into important meeting where user can not attend the call 
and want to convey the reason to his caller, he can send REGISTER request 
to server with message body specifying the reason for not attending the call. 


1. Call Barging

In contemporary deployments network elements provide the call barging service through static configuration, 
which is independent of SIP protocol. UA has nothing to do with it. 

The UAs compliant to this draft can use REGISTER message with xml body to request call barging.

Following diagrams shows the flow of scenario when user want to block the calls from a particular caller.


UA                   REGISTRAR           Location Server    	
|                        |                   |
| REGISTER               |                   |
|----------------------->|                   |
|  To:alice@atlanta.com  |                   |        
|  ---other headers ---  |  Store the info   |
|  content-type: xml     |------------------>|
|  content-length: xyz   |                   |
|                        |                   |
|  <call-barging>        |                   |
|  <URI>                 |                   |
|  bob@baloxi.com        |                   |
|  <\URI>                |                   |
|  <\call-barging>       |                   |
|                        |                   |
|                        |                   |
|       200 OK           |                   |
|<---------------------- |                   |
|                        |                   |
|                        |                   | 


Alice sending REGISTER for barging incoming calls from bob

When bob will send an INVITE to Alice her proxy will send suitable 4xx response - 486, for example.

2. showing Unavailability

UA can send the Register to show his unavailability as well. Of course, a UA can un-Register and become unavailable for always.
But here idea is to provide the relevant information to network about UA's unavailability. The two thing of prime importance for
his caller will be - reason for unavailability and the time after which he will be available. Following xml body format shall be
use for it
 

Xml body
<temporary-unavailable>
<Reason>
   Any text string  	
<\Reason>
<time>
Tentative time in seconds after which user will be available
<\time>
<temporary-unavailable>



UA                   		REGISTRAR           Location Server    	
|                        		|                   |
| REGISTER               		|                   |
|------------------------------------->	|                   |
|  To:alice@atlanta.com  		|                   |        
|  ---other headers ---  		|  Store the info   |
|  content-type: xml     		|------------------>|
|  content-length: xyz   		|                   |
|                        		|                   |
|  <temporary-unavailable>              |                   |
|  <Reason>                             |                   |
|   In Meeting  	                |                   |
|  <\Reason>                            |                   |
|  <time>               		|                   |
|   3600                                |                   |
|  <\time>		                |                   |
|  <\temporary-unavailable>             |                   |
|                                       |                   |  
|                        		|                   |
|                        		|                   |
|       200 OK          		|                   |
|<--------------------------------------|                   |
|                        		|                   |
|                        		|                   | 


Alice sending REGISTER for barging incoming calls from bob


Let's say bob sends INVITE to call Alice after 30 minutes of above Register message


UA                   		      Proxy           Location Server    	
|                        		|                   |
|      INVITE               		|                   |
|------------------------------------->	|                   |
|     To:alice@atlanta.com  		|                   |        
|                                       | Query for Alice   |  
|                        		|------------------>|
|                        		| Response based on |
|       480 Temporary Unavailable	|<------------------|
|<--------------------------------------| Alice's call      |
|                                       |  preference       |
|       Retry-After : 1800              |                   |
|	Reason : In meeting  		|                   |
|                                       |                   |     
|         ACK      		        |                   | 
|-------------------------------------->|                   |
|



Bob will get 480 temporarily Unavailable message with a 
Retry-After header containing the time left after which she is
supposed to be available and the Reason header which contains text 
string given by Alice.


3. XML tags used in this standard

The standard defines certain xml tags, to make UA to express it's call preferences. These tags may be extended
to provide new type of call preferences. The tags can be categorized into two parts :

3.1 Call Preference Tags :

These are the tags which specify the type of preference requested by the UA. The standard defines following three 
tags :

3.1.1 call-barging : This shall be the xml tag used for call baging. All the call barge parameters will be confined
to be boundaries of this tag. It shall always have URI as a supportive tag. It may or may not have time tag.

3.1.2 temporary-unavailable : This shall be the xml tag expressing the unavailibility. All the temporary-unavailable parameters 
will be confined to be boundaries of this tag. It can have two supportive tags - reason and time, both are optional.

3.1.3 reject :  This will be used by Registrar to reject all or subset of preferences requested by the UA. It may or may not contain
supportive tags. As per this standard it can only contain URI supportive tag

3.2 Supportive Tags :

These tags elaborate the call preferences indicated by the preference tags. 

3.2.1 URI: This is mandatory with call-barge, and will not be used with temporary-unavailable. It lists the 
URIs selected for call preference. A "*" with URI tag
means "for all URIs". *@somedomain.com means all the URIs from somedomain.com, similarly user@* means 
a user from all the domains. A "~" is used to specify all but not the given
expression. e.g. ~@office.com all the URIs but office.com. Multiple URIs tag can be 
there in a single body. They can be used to specify the
different-diffrent durations for particular sets of URIs, for example.

3.2.2 time: This is optional tag and is valid for both call-barge and temporary-unvailable. It Specifies 
the duration for which given call preference is applicable. Absence of this argument shall be treated
as "for-ever". In other words, a requested call preference not carrying time argument means applicability of call preference
is forever. A 0 value in time means UA is requesting to withdraw existing call preference.
 
3.2.3 Reason : This is optional tag and will not be used with call-barge. When used with temporary-unavailable it carries the
reason that UA wants to advertise to it's caller when it goes for temporary unavailability.

4 XML body for various Scenarios
  
Though the figure 1 presents the feature which looks trivial, in fact many contemporary hand sets
provide the feature to block the calls from a particular user. But there are way too many things that 
can be done using the extensibility of xml body for example, if user wants to block all incoming call 
he can send the following body in REGISTER message:

Xml body
<call-barging>
<URI>
     *	
<\URI>
<\call-barging>

Here * means bar all the incoming calls, no time argument means call-barge forever.

This is also possible that user want to block all the calls from a particular domain, following xml body 
will describe the call barging for a particular domain

Xml body
<call-barging>
<URI>
     *@xyz.com	
<\URI>
<\call-barging>

Similarly a particular user from all the domains

Xml body
<call-barging>
<URI>
   abc@*	
<\URI>
<\call-barging>

The user can also specify the time for call barge, for example he can barge the call from his office 
when he is on vacation for 2 days, following xml body shall be used for that.

<call-barging>
<URI>
    *@xyz.com	
<time>
   1728000
<\time>
<\URI>
<\call-barging>

The barge timer is associated with the set of URIs. This means different badge-time may be requested 
by the UA for different set of URIs in a single body. The time tag is within URI tag which means UA can
specify different durations of different sets of URI e.g.

<call-barging>
<URI>
    *@xyz.com	
<time>
   1728000
<\time>
<\URI>
<URI>
    bob@biloxy.com	
<time>
   3600
<\time>
<\URI>
<\call-barging>

Here call-barging for xyz.com is 1728000 second and for bob@biloxy.com is 3600 seconds
  
There can be situation when two or more sets of URIs have some overlapping, though usage of it is highly discouraged.
If, however, such a situation arise the Server must pick the super-set and drop the other preferences. For example :

<call-barging>
<URI>
    *@xyz.com	
<time>
   1728000
<\time>
<\URI>
<URI>
    *	
<time>
   3600
<\time>
<\URI>
<\call-barging>

Here Server will run the timer of 3600 seconds for blocking all the calls and will drop the first set of URIs. Same rule shall
be applied when handling the Re-Register.

There can scenario when user want to accept the call from particular domain and want to block rest of other callers
for example while in office, he wants to take calls from his office staff only. Following will be xml body for it :

<call-barging>
<URI>
     ~@office.com	
<\URI>
<barge-time>
   28800
<\barge-time>
<\call_barging

Here "~" represents the negation. So "~@office.com" means call barge from all domains but office.com.

To un-barge the call, following xml body shall be used

<call-barging>
<URI>
    abc@xyz.com
<time>
0
<\time>	
<\URI>
<\call-barging>

time value 0 removes the rule from the URIs it belongs to. So UA can send time 0 for a particular set of URI,and can specify
the non-zero value for other set.


5 Support for Message body In Register 

5.1 UA Behaviour

The UA which supports message body in Register shall send the tag "Reg-Msg-Body" in supported header of 
REGISTER message. If the registrar supports the same it will send 200 OK reply containing supported header 
with tag "Reg-Msg-Body". The UA can send the very first REGISTER message with message body, without even
knowing whether the network supports it or not. In case network does not supports it, i.e. no "Reg-Msg-Body"
tag in 200 OK, UA shall assume that all the call preferences requested by UA were dropped. After this UA shall not send 
message body in REGISTER until it gets the 200 OK with Reg-Msg-Body. However, the
UA compliant to this standard, shall send the supported header in REGISTER with Reg-Msg-Body tag. It makes sense 
as it might be possible that Registrar server is recently upgraded and now it supports Reg-Msg-Body. 

Registrar servers that support this standard shall send Reg-Msg-Body in supported header of 200 OK of REGISTER if
and only if they receive the same in REGISTER request. Please note that UA can send the register containing 
Reg-Msg-Body in supported header and without any body. This may used to know whether or not network supports message body
in REGISTER.

If UA received non 2xx response of Register, e.g. 401, 407, it shall assume no call preference rules are accepted by Registrar.
In case the non-2xx response if Register contains the supported header with Reg-Msg-Body tag, next Register from UA shall
be send with call preference sent in earlier Register. In case non-2xx response has no Reg-Msg-Body, UA shall not send message body
in further Register messages until it receives a supported header in 2xx of non-2xx message. 

A UA shall send one type of call preference in one Reg-Msg-Body. This means UA can not send the call-barge and temporary-unavailable
in a single message body of register.

5.2 Registrar Behaviour

Registrar shall show its support of Reg-Msg-Body by put a supported Header in response of Register with Reg-Msg-Body tag.
Registrar shall put the mentioned tag in 2xx or non-2xx response of Register. For example when Registrar is challenging the
Register message having Reg-Msg-Body tag, it will put supported header with this tag, in case it suuports the one.

Assuming that Registrar supports Reg-Msg-Body, it may or may allow the call preferences made by the user. However, Registrar 
will always send the 200 OK message for the Register if it's inline with RFC 3261, whether or not it accepts the 
call preferences requested by the UA in message body. This means 200 OK of Register will simply indicate that a UA 
is registered. The message body content of 200 OK of REGISTER message and supported header tag "Reg-Msg-Body" 
will tell whether or not call preference made by the user are accepted by network.

The message body of 200 OK of Register shall specify the reject list only. Thus, a 200 OK sent without any body shall indicate
that the call preferences are accepted by the network (	provided it has Reg-Msg-Body tag). Registrar will put all the un-accepted 
call preferences of UA in <reject> tag on xml body.

Therefore a if Register message, containing a body
 
<call-barging>
<URI>
     manager@office.com
     emergency@country.com
<time>
   1728000
<\time>	
<\URI>
<\call-barging>

gets 200 OK with following body

<reject>
<URI>
     emergency@country.com
<\URI>	
<\reject>


means Registrar will barge the call from manager@office.com but not from emergency@country.com

A Registrar can not modify the value in time tag, So there is shall not send the time in reject list.

The scenarios where Registrar has to reject the call preference should be rare. There, however, may be
a common scenario where user is not subscribed to avail call preference facility and is sending the
call preferences in Register message. Registrar shall reject all such call preferences by sending following
message body

<reject>
*
<\reject>

For rejecting temporary-unavailable call preference Registrar shall use above mentioned body. The temporary-unavailability
shall be an atomic operation. Which means either it will be accepted as it was requested or will be rejected - no subset acceptation
will be there.
	
6. Re-Register or Register refresh

Re-register semantics will reaming the same as specified in RFC 3261. Whether the message body in Register is 
accepted or rejected by the registrar, the register timer will be refreshed as per RFC 3261.
The Reg-Msg-Body timers specified by this standard will be restarted by the 
timer specified in new Register message, in the one is present. In case the value of timer is zero the given 
call preference will be de-activated. If the initial Register/Re-Register contains the time tag 
but the new one doesn't then this register message will be treated as no operation on these timers running at Registrar.

UA shall omit the body in Re-Register messages until or unless it wants to modify the rules or wants to instruct
registrar to restart the timer at its end. If the UA put new body in Register it will be appended to previous one 
and the timer for previous body (if there was any) will be as they were. In case, UA puts new body and along with 
previous one, timer for previous body will be restarted and new body will be treated as new one. 

In case UA's registration expires at Registrar, all the call preference will be deleted automatically


7. Conclusion

Multiple scenarios can be thought out and xml tags can be made for them. This will also 
save the cost of callers who have to pay if the call was forwarded to Voice mail. Here callers get 
information without being charged and at the same time callee's voice mails will also reduced to a significant numbers.


8. SIP semantics
The xml body can be send as used be done in others methods like INVITE, INFO etc. Please refer 
draft-ietf-sip-body-handling-01.txt for sending xml body in SIP messages.

9. Security Considerations

   There are security risks as UA is exposing the URIs in the plain xml format.

10. IANA Considerations

   This document registers a new option tag and two new headers, based
   on the IANA registration process of RFC 3261.

10.1 IANA Registration of the 100rel Option Tag

   This specification registers a single option tag, Reg-Msg-Body.  The
   required information for this registration, as specified in RFC 3261,
   is:

      Name: 100rel

      Description: This option tag is for message body in Register
	When present in a Supported header, it indicates UA/REGISTRAR can support
	message in Register message


Authors' Addresses

   Vidyut Gupta
   House No. C-222 
   Kendriya Vihar, Sector 51
   Noida 201301 India
   Tel: +919911101964
   Email: vidyut_gupta@yahoo.com