REGISTER in IMS and special Headers
Hello Benny,
As promised, here are small piece of information to some IMS-specific
details for SIP.
First let me thank you for adding the AKAv1-MD5 and AKAv2-MD5 support,
and the Service-Route support as well. Without them making an IMS client
would be very hard :)
There's a small document presenting the IMS-specific SIP features
http://project.swissgeek.org/IMS_Overview.pdf
There might be three very important features that could be added to
pjsip to make it almost 100% IMS-Compliant
- Support for private/public address.
In IMS, an IMS Subscription (IMSU) is created, then we attach to it a
Private Address (IMPI). This is what identify the user to the operator.
In this IMPI you specify which authentication scheme might be used,
which Registrar should handle this user ect. The IMPI is also used as
the "username" for the authentication process during the REGISTER.
To this IMPI you add several Public Address (IMPU). Which means, for one
user, you can have several public sip Address the user might be
contacted through. A public address might as well be shared between
several private address (like sip:support@mycompany.com might point to
the 6 engineers providing the support)
I'm still looking at how the registration of multiple public address for
the same device should be handled (either one REGISTER with all the IMPU
or multiple REGISTER).
- Support for Authorization in IMS
As described before, a user is identified by its private address. This
information is needed by the I-CSCF to redirect a REGISTER message to
the correct S-CSCF (registrar).
If you look at a standard REGISTER, there's only the sip contact address
in the from/to headers. This can't be used to "guess" the private user
identity.
That's why in IMS network the initial REGISTER message contains already
the "Authorization" field, with only the following fields :
- username = private address
- realm = IMS domain
- uri = IMS domain
here's a capture of a REGISTER sent by an IMS client
REGISTER sip:glam-oims.net SIP/2.0
Call-ID: f0f9c6d1bf2075b698a440114e5842d5@10.8.0.6
CSeq: 1 REGISTER
From: "bota" sip:bota@glam-oims.net;tag=9523050
To: "bota" sip:bota@glam-oims.net
Via: SIP/2.0/UDP
10.8.0.6:5060;branch=z9hG4bK6a5cea8e23abe690ef759704cd83fcc6
Max-Forwards: 70
Expires: 3600
P-Access-Network-Info: IEEE-802.11
Authorization: Digest
username="bota-private@glam-oims.net",realm="glam-oims.net",nonce="",uri="glam-oims.net",response=""
User-Agent: IMS-Communicator 070605
Supported: path
Contact: sip:bota@10.8.0.6:5060
Content-Length: 0
As you can see, there's already the Authorization field, but without a
valid response. This will allow the network to identify the user with
it's private address and route the REGISTER to the correct Registrar.
A flag in the pjsua_acc_config telling to send the initial register with
this field would be very helpfull :)
- Support for P-Access-Network-Info
It would be nice to have in the pjsua_acc_config a field where we can
specify the network access method. If this field is not empty, pjsip
would then put this header in every request sent from this account.
This information is often used by SIP A/S and MediaServer to determine
the capability of the access method and offer media stream adapted to it.
A streaming server would send a 12mbit/s Video to a user using IEE-802.3
(ethernet) while sending à 300kb/s video to a user with a
P-Access-Network-Info of 3GPP-UMTS.
That's it. Sorry for this long mail. If anyone comfortable with IMS see
any mistake/errors in the information provided here, I would gladly
accept your corrections.
Have a nice day.
Olivier B.
--
Olivier Beytrison
Telecommunication Engineer
Mobile: +41 (0)78 619 73 53
Mail: olivier@heliosnet.org
GPG: 0x4FB83528 http://pgp.mit.edu/
Hi Oliver,
I'm just curious: Besides the Digest-AKA, which has been integrated to PJSIP
by Benny, and the remarks you sent in your mail: What RFC's would you
consider to be "mandatory for PJSIP" in order to evolve to a IMS compliant
UA?
Regards
Hello Roland,
That's a pretty tough question you asked =)
Okay I'll try my best to not forget one :)
If we start from this reference :
http://www.pjsip.org/sip_media_features.htm#sip_features all those
features are needed for an IMS Client.
The one that should be supported as well are :
RFC3321 and RFC3322 for Signaling Compression
RFC3323 about the Private Field for privacy
RFC3325 (very important) Private Extensions to SIP for Asserted Identity
within Trusted Networks
RFC3329 Security between the UA and First hope
RFC3455 Private Header (P-Header) Extensions to SIP for the 3GPP
RFC3486 Compressing SIP (for SigComp)
RFC3892 should be fully supported for Session Mobility
RFC4083 is interesting as well, describing the requirement of SIP by the
3GPP
That's it I think. I've based this list on this page
http://www.tech-invite.com/Ti-sip-RFCs.html.
If anything else comes to my mind, I'll complete the list.
Regards,
Olivier B.
Roland Klabunde a écrit :
Hi Oliver,
I'm just curious: Besides the Digest-AKA, which has been integrated to PJSIP
by Benny, and the remarks you sent in your mail: What RFC's would you
consider to be "mandatory for PJSIP" in order to evolve to a IMS compliant
UA?
Regards
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
--
Olivier Beytrison
Telecommunication Engineer
Mobile: +41 (0)78 619 73 53
Mail: olivier@heliosnet.org
GPG: 0x4FB83528 http://pgp.mit.edu/
Oh, that sounds to be a lot of work... It seems that this is Pandora's box,
Benny mentioned somewhen :)
Wouldn't you agree, that this big amount of requirements could prevent IMS
from leaving the labs and getting really successful?
Or do I overinterpret this, and implementing the MUST HAVE could be done
with a snip?
BTW: Are you working on PJSIP's IMS capabilities?
Regards
----- Original Message -----
From: "Olivier Beytrison" olivier@heliosnet.org
To: "pjsip embedded/DSP SIP discussion" pjsip@lists.pjsip.org
Sent: Sunday, October 28, 2007 12:31 PM
Subject: Re: [pjsip] REGISTER in IMS and special Headers
Hello Roland,
That's a pretty tough question you asked =)
Okay I'll try my best to not forget one :)
If we start from this reference :
http://www.pjsip.org/sip_media_features.htm#sip_features all those
features are needed for an IMS Client.
The one that should be supported as well are :
RFC3321 and RFC3322 for Signaling Compression
RFC3323 about the Private Field for privacy
RFC3325 (very important) Private Extensions to SIP for Asserted Identity
within Trusted Networks
RFC3329 Security between the UA and First hope
RFC3455 Private Header (P-Header) Extensions to SIP for the 3GPP
RFC3486 Compressing SIP (for SigComp)
RFC3892 should be fully supported for Session Mobility
RFC4083 is interesting as well, describing the requirement of SIP by the
3GPP
That's it I think. I've based this list on this page
http://www.tech-invite.com/Ti-sip-RFCs.html.
If anything else comes to my mind, I'll complete the list.
Regards,
Olivier B.
Roland Klabunde a écrit :
Hi Oliver,
I'm just curious: Besides the Digest-AKA, which has been integrated to
PJSIP
by Benny, and the remarks you sent in your mail: What RFC's would you
consider to be "mandatory for PJSIP" in order to evolve to a IMS compliant
UA?
Regards
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
--
Olivier Beytrison
Telecommunication Engineer
Mobile: +41 (0)78 619 73 53
Mail: olivier@heliosnet.org
GPG: 0x4FB83528 http://pgp.mit.edu/
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Yeah, that's a sort of Pandora's box. This name fits IMS very well.
In my opinion, it's not the requirement which prevents IMS from leaving
the labs. Let's not forget that the whole IMS concept is still very
young, and not yet ready to be deployed as a carrier grade network
infrastructure. So far I can just think about iptel (Spanish operator)
who partially deployed IMS (this might be wrong, I'll check later on).
Beginning September I attended the NGMAST conference in Cardiff (Next
Generation Mobile Applications, Services and Technologies). A lot of
IMS-related topics has been discussed. Part of what I'm about to tell
you is based on the discussion and keynotes made during this conference.
It seems that the telco operators are not going to implement the IMS as
a whole network architecture. They will rather pick up some parts of it
(like the SOA, or SIP A/S) where they can make money on it.
As of today, there's no mobile device which is IMS Compliant. And this
for a very simple reason : I don't know any device mobile who support
IPSec. And IPSec is a prerequisite to access an IMS Domain.
And that's where the snake bites his own tail.
The mobile phone company (Nokia, Siemens, Ericsson ect) are not focusing
on making native IMS-compliant phones, because there's no available
networks to connect to which such a phone.
The telco operators are not moving to IMS because there's no mobile
phone who might connect to their network.
I see the migration from the Circuit Switched network to IMS as hard as
moving the internet from IPv4 to IPv6. I think the people from the 3GPP
and the main companies involved in developing IMS should really think on
a smooth way to migrate from the current architecture to IMS. It has
already be partially done with the "Early-IMS" concept, allowing
standard SIP application to connect to an IMS network.
Now looking at the list of RFCs from my previous mail, they all do not
need to be implemented, except maybe 2 or 3 of them. (3455,3325).
SigComp would be very useful as well in the future, but right now, most
people says that sigcomp is not really needed. So it's not widely used
on the IMS testbeds. The privacy headers are only necessary on a device
where you can use IPSec. This leave us with the Private headers
(P-Header) and the Private extensions (Asserted and Preferred identities)
Well, that's it. It's mainly my opinion, but also based on discussion I
had with people involved in the IMS development in big companies.
Oh, and no, unfortunately right now I don't have the time to dig into
the pjsip core code and implement myself the IMS capabilities, even if I
would enjoy it :) But maybe at a later time, once my project is over.
Regards,
Olivier B.
Roland Klabunde a écrit :
Oh, that sounds to be a lot of work... It seems that this is Pandora's box,
Benny mentioned somewhen :)
Wouldn't you agree, that this big amount of requirements could prevent IMS
from leaving the labs and getting really successful?
Or do I overinterpret this, and implementing the MUST HAVE could be done
with a snip?
BTW: Are you working on PJSIP's IMS capabilities?
Regards
----- Original Message -----
From: "Olivier Beytrison" olivier@heliosnet.org
To: "pjsip embedded/DSP SIP discussion" pjsip@lists.pjsip.org
Sent: Sunday, October 28, 2007 12:31 PM
Subject: Re: [pjsip] REGISTER in IMS and special Headers
Hello Roland,
That's a pretty tough question you asked =)
Okay I'll try my best to not forget one :)
If we start from this reference :
http://www.pjsip.org/sip_media_features.htm#sip_features all those
features are needed for an IMS Client.
The one that should be supported as well are :
RFC3321 and RFC3322 for Signaling Compression
RFC3323 about the Private Field for privacy
RFC3325 (very important) Private Extensions to SIP for Asserted Identity
within Trusted Networks
RFC3329 Security between the UA and First hope
RFC3455 Private Header (P-Header) Extensions to SIP for the 3GPP
RFC3486 Compressing SIP (for SigComp)
RFC3892 should be fully supported for Session Mobility
RFC4083 is interesting as well, describing the requirement of SIP by the
3GPP
That's it I think. I've based this list on this page
http://www.tech-invite.com/Ti-sip-RFCs.html.
If anything else comes to my mind, I'll complete the list.
Regards,
Olivier B.
Roland Klabunde a écrit :
Hi Oliver,
I'm just curious: Besides the Digest-AKA, which has been integrated to
PJSIP
by Benny, and the remarks you sent in your mail: What RFC's would you
consider to be "mandatory for PJSIP" in order to evolve to a IMS compliant
UA?
Regards
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
--
Olivier Beytrison
Telecommunication Engineer
Mobile: +41 (0)78 619 73 53
Mail: olivier@heliosnet.org
GPG: 0x4FB83528 http://pgp.mit.edu/
Hi Olivier,
thanks for the detailed discussion of the IMS topics. Let's see what we can
get out of PJSIP in order to make it a ~90+x % compliant IMS UA :)
Thanks
Regards
Hi Olivier,
thanks for the detailed discussions, it's been very enlightening!
Reading briefly, it looks like it's not too difficult to add basic
IMS support in PJSUA-LIB, so hopefully this can be done soon (and
thanks for the information on how this should be done in
pjsua-lib!). Can't promise anything beyond basic support though, and
especially it won't be anywhere near 90% compliant. Stuffs like PoC,
that's just awful!
-benny
Roland Klabunde wrote:
Hi Olivier,
thanks for the detailed discussion of the IMS topics. Let's see what we can
get out of PJSIP in order to make it a ~90+x % compliant IMS UA :)
Thanks
Regards