Subject: [Sip] Invite Headrs

From: "girish" <[email-masked]>
Date: Fri, 7 Jan 2005 01:02:28 +0530

HI,
   To establish a Pre established session , a INVITE has to be sent to the UAS . 
    What would be the TO and From header of the INVITE Message? Will they be the same ?

Girish Pai
Bharti Telesoft Intl. Pvt. Ltd.
Bangalore
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Fri, 7 Jan 2005 18:33:32 -0600

WARNING: LONG

Normally, I wouldn't respond to something like this here, but would  
refer it to the sip-implementors list. However, this does pose a  
reasonable example for running down SIP details across the multiple  
bodies developing specifications related to SIP. Consequently, I'll  
give a long-winded, rambling, and potentially pointless discussion of  
how one might try to run this sort of question down. Perhaps somebody  
can suggest a more direct route . . .

>      What would be the TO and From header of the INVITE Message? Will  
What difference does it make, and why?

"Pre Established Session", as I understand it, is an OMA POC  
optimization technique wherein a POC client maintains a long-lived  
dialog with a POC application server, and that POC application server  
acts a B2BUA to bridge the long-lived dialog together with short-lived  
dialogs created dynamically between the POC application server and  
other network elements.

Since the To and From of the INVITE that establishes the long-lived  
dialog is only seen by the POC application server, it may not matter a  
whole lot what goes in there.

However, assuming we use a "POC as conferencing" design model, which  
then envisions the POC application server as a sort of specialized  
conference bridge, it would seem reasonable to populate To: with the  
identity of the POC application server or service provider, and From:  
with the AOR of the user sending that INVITE. This would facilitate  
reuse of the From: field by the POC Application Server in the  
establishment of further short-lived dialogs.

But assuming we're taking about "pre established sessions" in the OMA  
POC sense, we should observe that what goes into To: and From: isn't  
really in the domain of the IETF. Rather, OMA specifications are likely  
to describe what they expect here, and unless they need some guidance  
on the matter from IETF (whether they know it or not) we generally  
don't have a lot to say about their specifications.

If you're interested, the POC working group of OMA has some of their  
working documents categorized as "public" and they can be retrieved  
from the OMA web site at:

http://member.openmobilealliance.org/ftp/public_documents/POC/ 
Permanent_documents/

Note: The page at  
http://www.openmobilealliance.org/tech/wg_committees/poc.html makes a  
lot more sense as a starting point.

The Architecture, Control plane, and User Plane documents may be of  
interest:

see:
OMA-AD-PoC-V1_0-20041117-D.zip
OMA-CP-POC-V1_0-20041111-D.zip
OMA-UP-PoC-V1_0-20041005-D.zip

And in:

OMA-TS-PoC_ControlPlane-V1_0-20041117-D.zip

I found:

--------------

6.1.3.2.1 PoC Client initiates a Pre-established Session

Upon receiving a requestfrom a PoC User to initiate a Pre-established  
Session the PoC Client:

-       1. SHALL generate an initial SIP INVITE request as specified in  
subclause 6.1.3.1 "General";

-       2. SHALL set the Request-URI of the SIP INVITE request to the  
Conference-factory-URI for the PoC Service in the Home PoC Network of  
the PoC User;

-       3. SHALL include a MIME SDP body as a SDP offer according to  
rules and procedures of [RFC3264] and [RFC2327] as follows;

a)   set the IP address and the port number for the RTP Session

b)  set the supported codecs of the PoC Client

c)  if another IP address or port number is used instead of the default  
IP address and port number specified by [RFC3550], set the IP address  
and port number for the RTCP Session at the PoC Clientaccording to  
rules and procedures of [RFC3605];

d) set the offered Talk Burst Control Protocol and the port number(s)  
for the Talk Burst Control Protocol

e) if the PoC Client is not able/willing to receive media streams  
immediately then the PoC Client SHALL set the media to "'inactive"' as  
specified in [RFC3108] when generating the SDP offer;

-       5. SHALL send the SIP INVITE request towards the PoC Server  
according torules andprocedures of the SIP/IP core.

Upon receiving a SIP 200 "OK" response to the SIP INVITE request the  
PoC Client:

-       1. SHALL store the content of the received Contact header as  
the PoC Session Identity

-       2. SHALL interact with the User Plane as specified in  
[OMA-PoC-UP] "PoC Client procedure at Pre-established Session  
initialization".

When the SIP/IP Core corresponds with 3GPP/3GPP2 IMS, the PoC Client  
SHALL use 3GPP/3GPP2 IMS Session establishment mechanisms according to  
rules and procedures of [TS24.229] / [3GPP2X.S0013.4]with the  
clarifications given in this subclause.

--------------

Noting that this refers to 6.1.3.1, we look there and see:

--------------

6.1.3.1             General

The PoC Client SHALL generate an initial SIP INVITE request according 
to rules and procedures of [RFC3261]. The PoC Client

-       1. SHALL include an Accept-Contact header with the Poc 
feature-tag '+g.poc.talkburst' along with ‘require’ and ‘explicit’ 
parameters according to the rules and procedures of [RFC 3841]in all 
initial SIP INVITE requests.

-       2. SHALL include User-Agent header to indicate the PoC release 
version.

-       3. SHALL include value ''id'' in a Privacy header if anonymity 
is requested according to rules and procedures of [RFC3325].

NOTE 1:  If anonymity is not allowed for the PoC Group indicated with 
the Request-URI of the SIP INVITE based on the rules specified in the 
[POC XDM Specification] the PoC Session will not be allowed by the PoC 
server hosting the PoC Group.

-       4. SHALL include the feature tag '+g.poc.talkburst' in the 
Contact header.

-       5. SHALL include the option tag 'timer' in the Supported header.

-       6. SHOULD include an Allow header with all supported SIP 
methods.

-       7. SHOULD include the Session-Expires header with the refresher 
parameter set to ''uac''according to rules and procedures 
of[draft-ietf-sip-session-timer].

NOTE:  The use of the option tag 'precondition', as specified in 
[RFC3312], and the option tag '100rel', specified in [RFC3262], is not 
defined for POC-1 reference point.

On receipt of a final response to the SIP INVITE request, the PoC 
Client SHALLstore the list of SIP methods that the PoC Server 
supportsif received in the Allow header.

On receipt of the SIP 200 "OK" response to the initial SIP INVITE 
request the PoC Client SHALL start the SIP Session timer usingthe value 
received in the Session-Expires headeraccording to rules and procedures 
of[draft-ietf-sip-session-timer].

When the SIP/IP Core corresponds with 3GPP/3GPP2 IMS, the PoC Client 
SHALL use 3GPP/3GPP2 IMS Session establishment mechanisms according to 
rules and procedures of [TS24.229] / [3GPP2X.S0013.4]with the 
clarifications given in this subclause.

--------------

So, in the final analysis, OMA doesn't seem to say anything direct 
about populating the To: and From: fields of an INVITE intended to 
establish a "pre-established session". Instead, they defer to the rules 
of the "SIP/IP Core", referencing 3GPP's TS 24.229, which one can see 
at:

http://www.3gpp.org/ftp/Specs/html-info/24229.htm

Note that this reference is not normative unless one happens to be 
running POC on IMS.

Looking at 24.229, we find in 

5.1.2A   "Generic procedures applicable to all methods excluding the 
REGISTER method":

-----------

Where privacy is required, in any initial request for a dialog or 
request for a standalone transaction, the UE shall set the From header 
to "Anonymous".

NOTE 4:        The contents of the From header should not be relied 
upon to be modified by the network based on any privacy specified by 
the user either within the UE indication of privacy or by network 
subscription or network policy. Therefore the user should include the 
value "Anonymous" whenever privacy is explicitly required.As the user 
may well have privacy requirements, terminal manufacturers should not 
automatically derive and include values in this header from the public 
user identity or other values stored in or derived from the UICC. Where 
the user has not expressed a preference in the configuration of the 
terminal implementation, the implementation should assume that privacy 
is required. Users that require to identify themselves, and are making 
calls to SIP destinations beyond the IM CN subsystem, where the 
destination does not implement RFC 3325 [34], will need to include a 
value in the From header other than Anonymous.

------------

24.229, as far as I can tell, says little about the From: header field, 
and almost nothing about the From: header field needed for IMS. So, the 
reference from the OMA document seems a little spurious. Digging 
deeper, we find that there are examples in 24.228. Unfortunately, 
although they discuss the use of the user's requested public identity 
in From: fields, these example do little to illuminate the use of the 
To: field (generally using a Tel: URL). Now, since I vaguely recall 
from years of working with 3GPP that 24.x specs are "stage 3" based on 
the 23.x stage 2 specs, I decided to fall back to stage 2 and see if 
there is anything helpful.

In 23.228, we find something useful:

--------------
4.3.3   Identification of users

There are various identities that may be associated with a user of IP 
multimedia services. This section describes these identities and their 
use.

4.3.3.1           Private user identities

Every IM CN subsystem user shall have one or more private user 
identities. The private identity is assigned by the home network 
operator, and used, for example, for Registration, Authorisation, 
Administration, and Accounting purposes. This identity shall take the 
form of a Network Access Identifier (NAI) as defined in RFC 2486 [14]. 
It is possible for a representation of the IMSI to be contained within 
the NAI for the private identity.

-  The Private User Identity is not used for routing of SIP messages.

-  The Private User Identity shall be contained in all Registration 
requests, (including Re-registration and De-registration requests) 
passed from the UE to the home network.

-  An ISIM application shall securely store one Private User Identity. 
It shall not be possible for the UE to modify the Private User Identity 
information stored on the ISIM application.

-  The Private User Identity is a unique global identity defined by the 
Home Network Operator, which may be used within the home network to 
uniquely identify the user from a network perspective.

-  The Private User Identity shall be permanently allocated to a user 
(it is not a dynamic identity), and is valid for the duration of the 
user’s subscription with the home network.

-  The Private User Identity is used to identify the user’s information 
(for example authentication information) stored within the HSS (for use 
for example during Registration).

-  The Private User Identity may be present in charging records based 
on operator policies.

-  The Private User Identity identifies the subscription (e.g. IM 
service capability) not the user.

-  The Private User Identity is authenticated only during registration 
of the user, (including re-registration and de-registration).

-  The HSS needs to store the Private User Identity.

-  The S-CSCF needs to obtain and store the Private User Identity upon 
registration and unregistered termination.

4.3.3.2           Public user identities

Every IM CN subsystem user shall have one or more public user 
identities [8]. The public user identity/identities are used by any 
user for requesting communications to other users. For example, this 
might be included on a business card.

-  Both telecom numbering and Internet naming schemes can be used to 
address users depending on the Public User identities that the users 
have.

-  The public user identity/identities shall take the form of SIP URL 
(as defined in RFC 3261 [12] and RFC2396 [13]) or the "tel:"-URL format 
[15].

-  An ISIM application shall securely store at least one Public User 
Identity (it shall not be possible for the UE to modify the Public User 
Identity), but it is not required that all additional Public User 
Identities be stored on the ISIM application.

-       A Public User Identity shall be registered either explicitly or 
implicitly before the identity can be used to originate IMS sessions 
and IMS session unrelated procedures.

-       A Public User Identity shall be registered either explicitly or 
implicitly before terminating IMS sessions and terminating IMS session 
unrelated procedures can be delivered to the UE of the user that the 
Public User Identity belongs to. Subscriber-specific services for 
unregistered users may nevertheless be executed as described in chapter 
5.12.

-  It shall be possible to register globally (i.e. through one single 
UE request) a user that has more than one public identity via a 
mechanism within the IP multimedia CN subsystem (e.g. by using an 
Implicit Registration Set). This shall not preclude the user from 
registering individually some of his/her public identities if needed.

-  Public User Identities are not authenticated by the network during 
registration.

-  Public User Identities may be used to identify the user’s 
information within the HSS (for example during mobile terminated 
session set-up).

--------------

So, from this we learn that the From: should be populated (if we aren't 
requesting anonymity) with a sip: or tel: URL and display name string 
corresponding to a public identity of the requesting user. And if we 
ARE requesting anonymity (which doesn't seem all that useful in this 
context), we set it to "Anonymous".

I'm not at all sure why some people think figuring this stuff out is 
easy. After all, I've only been working with this stuff for about six 
years, and I was able to address this basic question with only an hour 
or so of research,

And I still don't know what goes in the To:. But I suspect it doesn't 
really matter very much.

--
Dean