[IMS Tech] Using the Service-Route during re-registratiobn and de-registration
Rogier Noldus
Hello all,
When interpreting the text in RFC 3608 (Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration) literally, then the Service-Route may be used in any SIP Request that a UA sends, once registered. This would include the SIP Register request. However, what I see in literature and what I have seen in practice is that re-registrations does not use the Service-Route. As a result, re-registration will traverse again the I-CSCF.
Can someone confirm this? Is it explicitly or implicitly specified (e.g. in 3GPP TS 24.229) that a SIP Register for re-registration shall not use the Service-Route?
Thanks and regards
Rogier
Jose M Recio
De: imstech...@imsforum.org [mailto:imstech...@imsforum.org] En nombre de Rogier Noldus
Enviado el: viernes, 03 de octubre de 2008 11:31
Para: ims...@imsforum.org
Asunto: [IMS Tech] Using the Service-Route during re-registratiobn andde-registration
Rogier Noldus
Hello Jose,
Do you mean to say the following:
(1) according to IMS specification, a SIP User Agent should use the Service-route for re-registration and de-registration;
(2) and yes, literature does not reflect the above (why?), but shows signal sequence diagrams whereby the SIP Register will always traverse the I-CSCF (including HSS interrogation);
(3) and yes, commercial SIP clients do not comply with this part of the IMS spec and do indeed not include the Service-route in the re-registration and de-registration.
Regards
Rogier
Jose M Recio
Para: ims...@imsforum.org
Asunto: RE: [IMS Tech] Using the Service-Route during re-registrationandde-registration
Rogier Noldus
Hi,
Thanks all. Things are clear.
Specs aside (we all seem to eat, drink and sleep the TS 24.229 J), another functional reason why a subsequent Register shall not include the service-route is that the S-CSCF might have lost the registration data. This is often used as reason for frequent re-registrations. In this case where the registration data is lost, next time the SIP UA performs a registration (not including the service-route, as stated), the SIP Register will again go through I-CSCF, HSS query, and will be assigned to a S-CSCF. Possibly, the subscriber had in the meantime, since the S-CSCF had lost the registration data, performed registration through another SIP UA, and so the subscriber was then allocated to a S-CSCF already.
If the SIP UA would in the above-sketched situation include the service-route in the subsequent SIP Register, then things may go wrong! The SIP Register could end up in the wrong S-CSCF.
Regards
Rogier
From: Jose M Recio [mailto:re...@solaiemes.com]
Sent: Friday, October 03, 2008 11:48 PM
To: Rogier Noldus; ims...@imsforum.org
Subject: RE: [IMS Tech] Using the Service-Route during re-registrationandde-registration
Rogier,
Standards are clear, Service-Route should be honored by a compliant client. This means Service-Route received during the registration should be used to build subsequent requests, but not registration itself. This is because Service-Route is intended to help when requesting services once registration has been performed. Check 3GPP 24.229.
The fact is that there are not many IMS-clients around, mostly everybody is using modified SIP clients. I am not saying they are bad, just that they do not comply with some of the IMS mechanisms. Easing the communication between those clients and mostly standards-compliant IMS cores is one of the reasons why a SBC is sometimes not optional but a must.
JM
De: imstech-bounces@imsforum.org [mailto:imstech...@imsforum.org] En nombre de Rogier Noldus
Enviado el: viernes, 03 de octubre de 2008 15:12
Para: ims...@imsforum.org
Asunto: RE: [IMS Tech] Using the Service-Route during re-registrationandde-registration
Hello Jose,
Do you mean to say the following:
(1) according to IMS specification, a SIP User Agent should use the Service-route for re-registration and de-registration;
(2) and yes, literature does not reflect the above (why?), but shows signal sequence diagrams whereby the SIP Register will always traverse the I-CSCF (including HSS interrogation);
(3) and yes, commercial SIP clients do not comply with this part of the IMS spec and do indeed not include the Service-route in the re-registration and de-registration.
Regards
Rogier
From: Jose M Recio [mailto:re...@solaiemes.com]
Sent: Friday, October 03, 2008 2:56 PM
To: Rogier Noldus; ims...@imsforum.org
Subject: RE: [IMS Tech] Using the Service-Route during re-registratiobn andde-registration
Rogier,
I think part of the problem is that most of us are using not IMS clients, but more tweaked SIP clients, that do not follow all IMS SIP extensions.
What you comment about Service-Route could also be said about the several P-Identity headers, etc.
JM
De: imstech...@imsforum.org [mailto:imstech...@imsforum.org] En nombre de Rogier Noldus
Enviado el: viernes, 03 de octubre de 2008 11:31
Para: ims...@imsforum.org
Asunto: [IMS Tech] Using the Service-Route during re-registratiobn andde-registration
Nuno Saraiva
From: imstech...@imsforum.org [mailto:imstech...@imsforum.org] On Behalf Of Jose M Recio
Sent: sexta-feira, 3 de Outubro de 2008 13:56
To: Rogier Noldus; ims...@imsforum.org
Subject: RE: [IMS Tech] Using the Service-Route during re-registratiobnandde-registration
alan lloyd
Hi -
Is this the case the where the abstract architecture of IMS is made explicit / real with multiple Ps and Ss and the operator who implements it that way then expects the UE and the interface protocols between all functions to carry this data and remember “state”….
I must admit I don’t quite like “connectivity” architectures for this very reason – in that as more and more functions are perceived / placed the architecture, the more the protocols have to be updated to deal with interfaces between them… including the processes/ protocols in the user’s terminal.
Is this a strange expectation – if the operator wants a complex architecture – the terminal must be made more complex to deal with it !!
I believe that as system’s scale up they should stay as simple as possible and not affect the UE .. and “state” should be kept in as few places as possible in order to simplify management.
Best wishes alan
alan lloyd
Hi All,
As SIP seems to be directed at the replacement of SS7 and in addition its architecture offers a different set of access, AAA , session management and protocol processing to that of the web.
From the Service Route and a few other SIP fields we seem (correct me if I am wrong) passing network signaling and configurations complexity onto the UE. Thus complicating not just the UE, but also all the issues of web/sip convergence (single view, single management)..
For converged SIP/web systems
Would it be wrong to assume that as web/ims sessions could be orchestrated for example with a “SIP cookie”.. Could we use HTTP / web devices into IMS systems with a IMS/SIP session cookie and let a “webP-CSCF” type function do all that is necessary for the UE ? In this example the SIPcookie defines the UEs - register/invite/bye state , etc and carries any network managed protocol fields that are really of no interest to the UE/Browser.
Are we in a similar position with SIP / IMS to email where POP/SMTP was starting point for email and then Web mail came along?
Is there anyone working on converged web/sip access systems
Best wishes alan
Rogier Noldus
Hi all,
I think we’re now getting mixed up…
See my previous response (Sat 10/4/2008 12:08 AM). It’s true that the SIP UA does not use the Service-route for registration. But neither does the PCSCF use the service-route during re-registration. Hence, the re-registration will again traverse the I-CSCF. Rationale is that the subscriber might have got de-registered without the SIP UA knowing. Hence, re-registration as well as deregistration will always traverse I-CSCF.
Regards
Rogier
From: Vyas Dendukuri [mailto:vya...@yahoo.com]
Sent: Monday, October 06, 2008 6:26 PM
To: Nuno Saraiva; 'Jose M Recio'; Rogier Noldus; ims...@imsforum.org; alan....@wwite.com
Subject: RE: [IMS Tech] Using the Service-Route duringre-registratiobnandde-registration
Hi Rogier,
The UE in SIP Re-Registration dosen't use the Service Route, because the initial Register request when traversed via ICSCF the S-CSCF will send path header where it inform its IP address and the port number. And this information is stored by the P-CSCF, and hence when a Re-Register request is triggered by the UE the P-CSCF forwards the request directly to the S-CSCF instead of again sending to the I-CSCF.
And now the service route sent by the S-CSCF through the P-CSCF in final 200 OK response to the Register message.
BR
Vyas
--- On Sun, 10/5/08, alan lloyd <alan....@wwite.com> wrote:
From: alan lloyd <alan....@wwite.com>
Subject: RE: [IMS Tech] Using the Service-Route duringre-registratiobnandde-registration
To: "'Nuno Saraiva'" <nuno.s...@ericsson.com>, "'Jose M Recio'" <re...@solaiemes.com>, "'Rogier Noldus'" <rogier...@ericsson.com>, ims...@imsforum.org
Date: Sunday, October 5, 2008, 5:31 AM
Hi -
Is this the case the where the abstract architecture of IMS is made explicit / real with multiple Ps and Ss and the operator who implements it that way then expects the UE and the interface protocols between all functions to carry this data and remember “state”….
I must admit I don’t quite like “connectivity” architectures for this very reason – in that as more and more functions are perceived / placed the architecture, the more the protocols have to be updated to deal with interfaces between them… including the processes/ protocols in the user’s terminal.
Is this a strange expectation – if the operator wants a complex architecture – the terminal must be made more complex to deal with it !!
I believe that as system’s scale up they should stay as simple as possible and not affect the UE .. and “state” should be kept in as few places as possible in order to simplify management.
Best wishes alan
From: imstech...@imsforum.org [mailto:imstech...@imsforum.org] On Behalf Of Nuno Saraiva
Sent: Saturday, October 04, 2008 2:59 AM
To: Jose M Recio; Rogier Noldus; ims...@imsforum.org
Subject: RE: [IMS Tech] Using the Service-Route duringre-registratiobnandde-registration
Hi Rogier and Jose,
3GPP TS 24.229 only specifies that Service-Route received in Registration (AND Re-registrations) responses should be stored
which needs to be used to compose a Route header in future dialogs/transactions (containing both P-CSCF and content of SR, in the Route header).
Also according to TS24.229, the above (using the SR info to compose a Route Header) is to be used in Ue originating procedures for all methods except REGISTER
What we have been seing in practice is that most UA used today do not keep track of Service-Route, and simply continue to use ONLY the P-CSCF
address (for which registration was sucessfull), in the route header.
(Then, and since the P-CSCF MUST keep track of content of received SR, it can sucessfully route all Ue Originating traffic (except REGISTER)
to the S-CSCF listed in the received SR (200OK for Registration/Re-registration).
BR,
/Nuno
From: imstech...@imsforum.org [mailto:imstech...@imsforum.org] On Behalf Of Jose M Recio
Sent: sexta-feira, 3 de Outubro de 2008 13:56
To: Rogier Noldus; ims...@imsforum.org
Subject: RE: [IMS Tech] Using the Service-Route during re-registratiobnandde-registration
Rogier,
I think part of the problem is that most of us are using not IMS clients, but more tweaked SIP clients, that do not follow all IMS SIP extensions.
What you comment about Service-Route could also be said about the several P-Identity headers, etc.
JM
De: imstech...@imsforum.org [mailto:imstech-bounces@imsforum.org] En nombre de Rogier Noldus
Enviado el: viernes, 03 de octubre de 2008 11:31
Para: ims...@imsforum.org
Asunto: [IMS Tech] Using the Service-Route during re-registratiobn andde-registration
Hello all,
When interpreting the text in RFC 3608 (Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration) literally, then the Service-Route may be used in any SIP Request that a UA sends, once registered. This would include the SIP Register request. However, what I see in literature and what I have seen in practice is that re-registrations does not use the Service-Route. As a result, re-registration will traverse again the I-CSCF.
Can someone confirm this? Is it explicitly or implicitly specified (e.g. in 3GPP TS 24.229) that a SIP Register for re-registration shall not use the Service-Route?
Thanks and regards
Rogier
_______________________________________________
IMStech mailing list
Vyas Dendukuri
Hi Rogier,
The UE in SIP Re-Registration dosen't use the Service Route, because the initial Register request when traversed via I-CSCF the S-CSCF will send path header where it inform its IP address and the port number.And this information is stored by the P-CSCF,and hence when a Re-Register request is triggered by the UE the P-CSCF forwards the request directly to the S-CSCF instead of again sending to the I-CSCF.
And now the service route sent by the S-CSCF through the P-CSCF in final 200 OK responce to the Register message.
BR
Vyas
Vyas Dendukuri Mailto:vya...@yahoo.com/hotmail.com |
--- On Sun, 10/5/08, alan lloyd <alan....@wwite.com> wrote: |
From: alan lloyd <alan....@wwite.com> |
To: "'Nuno Saraiva'" <nuno.s...@ericsson.com>, "'Jose M Recio'" <re...@solaiemes.com>, "'Rogier Noldus'" <rogier...@ericsson.com>, ims...@imsforum.org |
|
|
|
|
_______________________________________________ IMStech mailing list IMS...@imsforum.org http://lists.imsforum.org/mailman/listinfo/imstech |
Tomasz Zieleniewski
We are working on a few projects considering converged SIP/web systems.
Our experience shows one important issue. Operators tend to purchase
ngn like services on their
existing VoIP infrastructures which are of course SIP based. They
stress the need of smooth
service migration to IMS. This constitutes a very critical business
factor. Services related to
sip/web convergence seem to be basic focus as applications delivered by IMS.
In that case webP-CSCF would not fit, especially at this stage of IMS
deployments.
Assuring service continuity would be difficult. The difficulty would
probably increase nonlineary
with the service complexity.
Beside 'Web' is a very wide word, there are plenty of different
technologies not only
HTTP but many more. Interaction between them and SIP in such case is
better perceived
as a form of protocol(technology) gateway. One can imagine plenty of
such cases and it would be
hard to arrange it all later on during VoIP to IMS migration.
We think that the best place to inject such functionality is the
application server.
We don't miss anything that is important we can still authenticate and
authorize
subscribers/services as well charge them in the proper way.
Kind regards
Tomasz Zieleniewski
alan lloyd
I made up for an abstract function that could provide SIP core services to
web users.. The purpose was to see if anyone had ventured into this space
at all.
Best wishes alan
-----Original Message-----
From: JulioGonzalez [mailto:julio.g...@mymail.roosevelt.edu]
Sent: Wednesday, October 08, 2008 8:38 AM
To: Tomasz Zieleniewski; alan....@wwite.com
Cc: ims...@imsforum.org
Subject: Re: [IMS Tech] web sip integration
Hi Alan, Tomass,
Can you please define what a webP-CSCF is? Is that a proxy that accepts SIP
messages and HTTP messages as well?
Regards,
Julio Gonzalez-Saenz
http://www.linkedin.com/in/saenz
Space exploration interested? Join my UAS group
IMS interested? Join IMS Forum group
Biological Computation interested? Join my DNAComp group
JulioGonzalez
alan lloyd
Hi All - I had a few off list responses and a few on.. The topic is being explored so that is good.
May I provide some opening thoughts?
For convergence we need to define a “system meeting point” - I like to take the perspective that the converged services management node (shall we say the SDP) applies common system functions, and once these are put in place then the different entry/ exit protocols can be treated in a common (converged) fashion. Common SDP functions could be authentication, authorization, presence, session control, registration, identity management and event management.
Currently when we define a new protocols and architectures we then apply a dedicated set of system management functions too. So we end up with different authentication systems, presence/online status, session management systems … and data models, etc, etc..
A foundation signal
IMS/SIP provides a Register method which enables “an authorized user” to let the system know they are on line or going off line.
The same register method/path could be used for IP based devices and web users as well as system service entities and content catalogues. Naturally the “Register” in these cases are internally manufactured based on interface interactions. That is, what ever is in the system (and has an IP address/domain name) and reaches an online status is “registered”.
First part of the SDP design – a common registration/deregistration function and IP policy based address management system.
Once registered, particularly the systems services, other system entities such as users, applications can subscribe to those services (e.g address books, message summaries, user presence)
Once IP assigned and registered the SDP notifies the DNS subsystem that the entity is available.
Second part of the design is a common presence status management function and publication via DNS.
The above design elements takes the position that all users, devices and services in the system can come and go in a dynamic fashion. The implication is that when “services” are designed, they have software to register (and de register) themselves on the system .. Many services / applications today are actually hard wired or connected with SOAs.. Is that a good approach given that system services need to be dynamic and agile? So because of e.g. dynamic third party services and service fail over/ reintroduction - a common dynamic registration arrangement for all system entities is much, better.
Events - within the system also need a coherent approach to identification, ranking, processing and reporting - and this function should be common and converged (within the SDP) as well.
The reason for mentioning the above is - converged services are often requested by operators but the actual convergence “architecture” needs a common point to work on… I think the functions as described above are exactly that..
If this starting point for a convergence discussion is OK -- I am more than happy to share thoughts about web user access paths through the SDP’s - IMS and identity system/ web sip protocols
Best wishes alan
alan lloyd
platform "level" .... if so ... fantastic we are on the same page
Lets us all know how the experiments go too (what are they? :-) )
Best wishes alan
-----Original Message-----
From: JulioGonzalez [mailto:julio.g...@mymail.roosevelt.edu]
Sent: Wednesday, October 08, 2008 7:00 PM
To: alan....@wwite.com; 'Tomasz Zieleniewski'
Cc: ims...@imsforum.org
Subject: RE: [IMS Tech] web sip integration
Thanks Alan..
We are making some SIPServlets/HTTPServlets experiments not at CSCF level
but in the application level..
JulioGonzalez
Rogier Noldus
Hi,
Quick comment. It is stated below that Service-route may contain: P-CSCF1, IBCF1, IBCF2, S-CSCF2. I doubt the correctness of that statement. Service-route may indeed have multiple entries, but in my opinion not IBCF and not P-CSCF.
Regarding P-CSCF1: the P-CSCF to use for outgoing SIP sessions will be the P-CSCF that is 'discovered' during the initial registration process. The P-CSCF may, as part of establishing security association with the SIP UA, indicate to the UA that it shall use a different port number from then onwards. This indication from P-CSCF to SIP UA, about the port number to use, is done in the 401 Unauthorized, i.e. before the registration is accepted by S-CSCF and hence before the S-CSCF had returned service-route.
So, the P-CSCF address to be used by SIP UA for outgoing SIP sessions is the discovered P-CSCF address, possibly modified by P-CSCF during the registration process.
IBCF: A subscriber is not associated with particular IBCF(s). If a SIP session is to be established through an IBCF, then that may be accomplished with e.g. external-DNS vs. internal-DNS. The IBCF to route through is as such determined per SIP session.
Ok, maybe IBCF could be included in the service-route, but then you tie a subscriber to one particular IBCF, whilst the IBCF contains no subscriber-specific data.
Rogier
-----Original Message-----
From: Dragos Vingarzan [mailto:dragos.v...@gmail.com]
Sent: Wednesday, October 08, 2008 12:31 PM
To: Nuno Saraiva
Cc: Jose M Recio; Rogier Noldus; ims...@imsforum.org
Subject: Re: [IMS Tech] Using the Service-Route during re-registratiobnandde-registration
And let's not assume that the Service-Route will always have just one
entry. This is the usual case, in a basic scenario, but in a realistic
one I would say that it would have at least P-CSCF1, IBCF1, IBCF2,S-CSCF2.
So the P-CSCF saves the entire list and should check it for every
initial request that it receives on the Gm interface. It can just reject
bad clients, or replace the entire route set with the right one.
Cheers,
-Dragos
Nuno Saraiva wrote:
> Hi Rogier and Jose,
>
> 3GPP TS 24.229 only specifies that Service-Route received in
> Registration (AND Re-registrations) responses should be stored
> which needs to be used to compose a Route header in future
> dialogs/transactions (containing both P-CSCF *and* content of SR, in
> the Route header).
>
> Also according to TS24.229, the above (using the SR info to compose a
> Route Header) is to be used in Ue originating procedures for *all
> methods except REGISTER*
>
> What we have been seing in practice is that most UA used today do not
> keep track of Service-Route, and simply continue to use ONLY the P-CSCF
> address (for which registration was sucessfull), in the route header.
>
> (Then, and since the P-CSCF MUST keep track of content of received SR,
> it can sucessfully route all Ue Originating traffic (except REGISTER)
> to the S-CSCF listed in the received SR (200OK for
> Registration/Re-registration).
>
> BR,
>
> /Nuno
>
>
>
> ------------------------------------------------------------------------
> *From:* imstech...@imsforum.org
> [mailto:imstech...@imsforum.org] *On Behalf Of *Jose M Recio
> *Sent:* sexta-feira, 3 de Outubro de 2008 13:56
> *To:* Rogier Noldus; imst...@imsforum.org
> *Subject:* RE: [IMS Tech] Using the Service-Route during
> re-registratiobnandde-registration
>
> Rogier,
> I think part of the problem is that most of us are using not IMS
> clients, but more tweaked SIP clients, that do not follow all IMS SIP
> extensions.
> What you comment about Service-Route could also be said about the
> several P-Identity headers, etc.
> JM
>
>
>
> ------------------------------------------------------------------------
> *De:* imstech...@imsforum.org
> [mailto:imstech...@imsforum.org] *En nombre de *Rogier Noldus
> *Enviado el:* viernes, 03 de octubre de 2008 11:31
> *Para:* ims...@imsforum.org
> *Asunto:* [IMS Tech] Using the Service-Route during re-registratiobn
> andde-registration
>
> Hello all,
>
> When interpreting the text in RFC 3608 (Session Initiation Protocol
> (SIP) Extension Header Field for Service Route Discovery During
> Registration) literally, then the Service-Route may be used in any SIP
> Request that a UA sends, once registered. This would include the SIP
> Register request. However, what I see in literature and what I have
> seen in practice is that re-registrations does not use the
> Service-Route. As a result, re-registration will traverse again the
> I-CSCF.
>
> Can someone confirm this? Is it explicitly or implicitly specified
> (e.g. in 3GPP TS 24.229) that a SIP Register for re-registration shall
> not use the Service-Route?
>
> Thanks and regards
>
> Rogier
>
> ------------------------------------------------------------------------
--
Best Regards,
Dragos Vingarzan
Jose M Recio
De: Rogier Noldus [mailto:rogier...@ericsson.com]
Enviado el: miércoles, 08 de octubre de 2008 12:44
Para: Dragos Vingarzan; Nuno Saraiva
CC: Jose M Recio; ims...@imsforum.org
Asunto: RE: [IMS Tech] Using the Service-Route during re-registration and de-registration
Dragos Vingarzan
entry. This is the usual case, in a basic scenario, but in a realistic
one I would say that it would have at least P-CSCF1, IBCF1, IBCF2,S-CSCF2.
So the P-CSCF saves the entire list and should check it for every
initial request that it receives on the Gm interface. It can just reject
bad clients, or replace the entire route set with the right one.
Cheers,
-Dragos
Nuno Saraiva wrote:
> Hi Rogier and Jose,
>
> 3GPP TS 24.229 only specifies that Service-Route received in
> Registration (AND Re-registrations) responses should be stored
> which needs to be used to compose a Route header in future
> dialogs/transactions (containing both P-CSCF *and* content of SR, in
> the Route header).
>
> Also according to TS24.229, the above (using the SR info to compose a
> Route Header) is to be used in Ue originating procedures for *all
> methods except REGISTER*
>
> What we have been seing in practice is that most UA used today do not
> keep track of Service-Route, and simply continue to use ONLY the P-CSCF
> address (for which registration was sucessfull), in the route header.
>
> (Then, and since the P-CSCF MUST keep track of content of received SR,
> it can sucessfully route all Ue Originating traffic (except REGISTER)
> to the S-CSCF listed in the received SR (200OK for
> Registration/Re-registration).
>
> BR,
>
> /Nuno
>
>
>
> ------------------------------------------------------------------------
> *From:* imstech...@imsforum.org
> [mailto:imstech...@imsforum.org] *On Behalf Of *Jose M Recio
> *Sent:* sexta-feira, 3 de Outubro de 2008 13:56
> *To:* Rogier Noldus; ims...@imsforum.org
> *Subject:* RE: [IMS Tech] Using the Service-Route during
> re-registratiobnandde-registration
>
> Rogier,
> I think part of the problem is that most of us are using not IMS
> clients, but more tweaked SIP clients, that do not follow all IMS SIP
> extensions.
> What you comment about Service-Route could also be said about the
> several P-Identity headers, etc.
> JM
>
>
>
> ------------------------------------------------------------------------
> *De:* imstech...@imsforum.org
> [mailto:imstech...@imsforum.org] *En nombre de *Rogier Noldus
> *Enviado el:* viernes, 03 de octubre de 2008 11:31
> *Para:* ims...@imsforum.org
> *Asunto:* [IMS Tech] Using the Service-Route during re-registratiobn
> andde-registration
>
> Hello all,
>
> When interpreting the text in RFC 3608 (Session Initiation Protocol
> (SIP) Extension Header Field for Service Route Discovery During
> Registration) literally, then the Service-Route may be used in any SIP
> Request that a UA sends, once registered. This would include the SIP
> Register request. However, what I see in literature and what I have
> seen in practice is that re-registrations does not use the
> Service-Route. As a result, re-registration will traverse again the
> I-CSCF.
>
> Can someone confirm this? Is it explicitly or implicitly specified
> (e.g. in 3GPP TS 24.229) that a SIP Register for re-registration shall
> not use the Service-Route?
>
> Thanks and regards
>
> Rogier
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> IMStech mailing list
> IMS...@imsforum.org
> http://lists.imsforum.org/mailman/listinfo/imstech
>
--
Best Regards,
Dragos Vingarzan
_______________________________________________
Dragos Vingarzan
the point that, according to the IETF RFC3608, that would be a general case.
The P-CSCF could be in there also. It does not break any standards, does it?
My view is: The main purpose of the Service-Route in the IMS is to
enforce the network's policy on originating requests.
The regarding registration - the Service-Route to be saved in the client
and P-CSCF is the one in the 2xx response. If you'd think in IETF terms
for the 401 and the challenge, the 2nd REGISTER is the first one +
challenge response. But a higher-layer IMS stack might never tell if
there were 2 REGISTER transaction due to the challenge or just one.
Yes, if you include IPSec security, then it might need to know that, but
I would say that even if it was introduced by 3GPP and is called
ipsec-3gpp, this is not an IMS exclusive feature, so I would implement
it in SIP stack. Anyway, too much detail...
The Service-Route is only to be used on initial requests. You have
already motivated why it should not be used on re-registration or
de-registration.
But it would never be used on the REGISTER after the 401 as according to
RFC3261, that is just the original message + authorization information.
So I don't see your point on why the P-CSCF can't be in there. It can
work without, but you have to put an extra restriction in the IMS client
that it would send all requests through a strict outbound proxy.
Cheers,
-Dragos
> > *To:* Rogier Noldus; ims...@imsforum.org
_______________________________________________
Rogier Noldus
Hi,
Ok, then we have the following situation:
- for enforcing that outbound initial SIP requests (SIP UA à network) traverses a (particular) IBCF, situated between P-CSCF and S-CSCF, the S-CSCF may add the address of the IBCF to the Service-route (over and above the address of the S-CSCF itself).
- for enforcing that inbound initial SIP requests (network à UA) traverse a (particular) IBCF, situated between S-CSCF and P-CSCF, the S-CSCF may add the address of the IBCF to the path header. It is hereby assumed that the path header may contain multiple entries.
And yes, P-CSCF may store the service-route and force that the outbound initial SIP requests are indeed routed via this service-route. When the P-CSCF stores the service route, as it does today, it should not matter whether the service route contains only a S-CSCF address or also a (particular) IBCF address.
I agree that THIG is a specific functional entity. A P-CSCF may include THIG.
Rogier
-----Original Message-----
From: Dragos Vingarzan [mailto:dragos.v...@gmail.com]
Sent: Wednesday, October 08, 2008 2:39 PM
To: Jose M Recio
Cc: Rogier Noldus; Nuno Saraiva; ims...@imsforum.org
Subject: Re: [IMS Tech] Using the Service-Route during re-registration and de-registration
As I said, the IBCF might have been an unfortunate example, considering
that as you point out, there is a standard saying otherwise. The thing
is that I still see the IBCF as a split-functionality from the I-CSCF in
Rel.5. There THIG was part of it and the I-CSCF was inserting itself in
the Service-Route or/and Path. I can't find a good explanation on why
and IBCF should not Service-Route, other than to keep it more
reliable... Isn't it more efficient to discover the IBCFs once and then
have the P-CSCF enforce that they are always used?
Then, because you mentioned also the Path header, it is kind of the same
story. I like to look at them as the way to indicate and enforce Network
Routing Policy. Service Route works for originating side and Path for
terminating. And then only the Service-Route is send towards the edge of
the network and the Path does not need enforcement as it is saved at the
core.
And there is nothing wrong in keeping state at the edge of the network.
It keeps the core network light and scalable... quite a big benefit of
SIP, I would say... kind of the same direction as keeping routing nodes,
like the CSCFs in proxy-mode.
Cheers,
-Dragos
Jose M Recio wrote:
> I agree with you, Rogier, the way is described in specs, Service-Route
> is designed to be useful only for the S-CSCF.
> P-CSCF does not include itself, is required only to check upstream and
> downstream Route set contents (*after* removing itself from the
> received ones), and if they aren't the same, as Dragos points, P-CSCF
> can replace the contents or drop the request altogether, but not
> include itself.
> In cases where topology hiding is used, the S-CSCF may insert the
> I-BCF in the Service-Route. This does not mean that the I-BCF itself
> processes and understands the header, the spec is clear: "In
> accordance with the procedures described in RFC 3608 [38], an IBCF
> does not insert its own routeable SIP URI to the Service-Route header."
> Part of the rationale for this design, I think, is keeping state in
> the user side at the minimum.
> The network keeps state (the chain of nodes) using the "Path" header.
>
>
> ------------------------------------------------------------------------
> *De:* Rogier Noldus [mailto:rogier...@ericsson.com]
> *Enviado el:* miércoles, 08 de octubre de 2008 12:44
> *Para:* Dragos Vingarzan; Nuno Saraiva
> *CC:* Jose M Recio; ims...@imsforum.org
> *Asunto:* RE: [IMS Tech] Using the Service-Route during
> > *To:* Rogier Noldus; ims...@imsforum.org
Dragos Vingarzan
that as you point out, there is a standard saying otherwise. The thing
is that I still see the IBCF as a split-functionality from the I-CSCF in
Rel.5. There THIG was part of it and the I-CSCF was inserting itself in
the Service-Route or/and Path. I can't find a good explanation on why
and IBCF should not Service-Route, other than to keep it more
reliable... Isn't it more efficient to discover the IBCFs once and then
have the P-CSCF enforce that they are always used?
Then, because you mentioned also the Path header, it is kind of the same
story. I like to look at them as the way to indicate and enforce Network
Routing Policy. Service Route works for originating side and Path for
terminating. And then only the Service-Route is send towards the edge of
the network and the Path does not need enforcement as it is saved at the
core.
And there is nothing wrong in keeping state at the edge of the network.
It keeps the core network light and scalable... quite a big benefit of
SIP, I would say... kind of the same direction as keeping routing nodes,
like the CSCFs in proxy-mode.
Cheers,
-Dragos
Jose M Recio wrote:
> I agree with you, Rogier, the way is described in specs, Service-Route
> is designed to be useful only for the S-CSCF.
> P-CSCF does not include itself, is required only to check upstream and
> downstream Route set contents (*after* removing itself from the
> received ones), and if they aren't the same, as Dragos points, P-CSCF
> can replace the contents or drop the request altogether, but not
> include itself.
> In cases where topology hiding is used, the S-CSCF may insert the
> I-BCF in the Service-Route. This does not mean that the I-BCF itself
> processes and understands the header, the spec is clear: "In
> accordance with the procedures described in RFC 3608 [38], an IBCF
> does not insert its own routeable SIP URI to the Service-Route header."
> Part of the rationale for this design, I think, is keeping state in
> the user side at the minimum.
> The network keeps state (the chain of nodes) using the "Path" header.
>
>
> ------------------------------------------------------------------------
> *De:* Rogier Noldus [mailto:rogier...@ericsson.com]
> *Enviado el:* miércoles, 08 de octubre de 2008 12:44
> *Para:* Dragos Vingarzan; Nuno Saraiva
> *CC:* Jose M Recio; ims...@imsforum.org
> *Asunto:* RE: [IMS Tech] Using the Service-Route during
> > *To:* Rogier Noldus; ims...@imsforum.org
_______________________________________________
Rogier Noldus
Hello Kjell,
I have not come across this distinction in ENUM (which is by no means an indication that such indication ain’t there J).
When an entity, typically S-CSCF, performs ENUM query, it provides to ENUM only the R-URI (in arpa format). So, how is the Route header (which Route header?) taken into consideration in the ENUM query?
What I can imagine is that ENUM will or won’t return the SIP URI to the requesting entity (S-CSCF), depending on the network that this S-CSCF belongs to. Example:
- If S-CSCF from country A queries ENUM for a subscriber belonging to country B, then ENUM does not return the SIP URI of that person; the call will take a breakout to Circuit Switched domain;
- If S-CSCF from country A queries ENUM for a subscriber belonging to country A, then ENUM will return the SIP URI of that person.
(ENUM forms part of DNS structure, so ENUM in one IMS network could obtain subscriber data from ENUM in another IMS network.)
It is my understanding that operators will gradually start allowing ENUM access from S-CSCFs from other IMS networks in the same country. I think cross-country border ENUM access will take a while.
Regards
Rogier
From:
kjell...@telenor.com [mailto:kjell...@telenor.com]
Sent: Friday, October 10, 2008
12:55 PM
To: Rogier Noldus
Cc: ims...@imsforum.org
Subject: IMS routing between
networks
Hi Rogier,
I am sorry for interrupting this ongoing discussion. But you trigger my attention by mentioning external-DNS vs. internal-DNS. I have also seen in ENUM discussions that they distinguish between target address (Request URI) and Route header (interconnect point). Do you or anybody else have any information on how this is implemented in ENUM/DNS?
Kjell S.
> *To:* Rogier Noldus; ims...@imsforum.org
kjell...@telenor.com
Hi Rogier,
I am sorry for interrupting this ongoing discussion. But you trigger my attention by mentioning external-DNS vs. internal-DNS. I have also seen in ENUM discussions that they distinguish between target address (Request URI) and Route header (interconnect point). Do you or anybody else have any information on how this is implemented in ENUM/DNS?
Kjell S.
Fra: imstech...@imsforum.org [mailto:imstech...@imsforum.org] På vegne av Rogier Noldus
Sendt: 8. oktober 2008 12:44
Til: Dragos Vingarzan; Nuno Saraiva
Kopi: ims...@imsforum.org
> *To:* Rogier Noldus; ims...@imsforum.org
Christopher Avila
ENUM is also used when IMS node is receiving calls from PSTN/PLMN.
The MGCF/SG queries the DNS/ENUM for the subscriber ENUM , if the
subscriber is found, the DNS/ENUM sends the subscriber SIP-URI to the
MGCF/SG
This will contain the IMS Domain where the subscriber belongs. Now the
MGCF will route the call to the corresponding subscriber IMS Domain.
Some IMS solutions use E-DNS because many queries from UAs are perfomed
from outside the IMS Domain. The node I-DNS is always used for all the
IMS traffic and queries inside the IMS domain.
KR
///Mario Christopher
Rogier Noldus wrote:
>
> Hello Kjell,
>
> I have not come across this distinction in ENUM (which is by no means
> an indication that such indication ain’t there J).
>
> When an entity, typically S-CSCF, performs ENUM query, it provides to
> ENUM only the R-URI (in arpa format). So, how is the Route header
> (which Route header?) taken into consideration in the ENUM query?
>
> What I can imagine is that ENUM will or won’t return the SIP URI to
> the requesting entity (S-CSCF), depending on the network that this
> S-CSCF belongs to. Example:
>
> - If S-CSCF from country A queries ENUM for a subscriber belonging to
> country B, then ENUM does not return the SIP URI of that person; the
> call will take a breakout to Circuit Switched domain;
>
> - If S-CSCF from country A queries ENUM for a subscriber belonging to
> country A, then ENUM will return the SIP URI of that person.
>
> (ENUM forms part of DNS structure, so ENUM in one IMS network could
> obtain subscriber data from ENUM in another IMS network.)
>
> It is my understanding that operators will gradually start allowing
> ENUM access from S-CSCFs from other IMS networks in the same country.
> I think cross-country border ENUM access will take a while.
>
> Regards
>
> Rogier
>
> ------------------------------------------------------------------------
>
> *From:* kjell...@telenor.com [mailto:kjell...@telenor.com]
> *Sent:* Friday, October 10, 2008 12:55 PM
> *To:* Rogier Noldus
> *Cc:* ims...@imsforum.org
> *Subject:* IMS routing between networks
>
> Hi Rogier,
>
> I am sorry for interrupting this ongoing discussion. But you trigger
> my attention by mentioning external-DNS vs. internal-DNS. I have also
> seen in ENUM discussions that they distinguish between target address
> (Request URI) and Route header (interconnect point). Do you or anybody
> else have any information on how this is implemented in ENUM/DNS?
>
> Kjell S.
>
> *Fra:* imstech...@imsforum.org
> [mailto:imstech...@imsforum.org] *På vegne av* Rogier Noldus
> *Sendt:* 8. oktober 2008 12:44
> *Til:* Dragos Vingarzan; Nuno Saraiva
> *Kopi:* ims...@imsforum.org
> *Emne:* RE: [IMS Tech] Using the Service-Route during re-registration
kjell...@telenor.com
Another question is how the tel URI is used in IMS. There are some guidelines on tel URI and ENUM, where the tel URI is translated to a SIP URI. Tel URI is not routable within IMS. But a session with a tel URI can be terminated in the IMS network if the HSS support the tel URI format Public User Identity. My understanding is that this will be a termination from f.i. fixed network when a routing decision has made that this is a user in the particular IMS network.
Does this mean that there are two options:
1. Provision minimum two Public User Identities per user in the HSS, one SIP URI and one tel URI
2. Provision only one SIP URI per user in the HSS?
If option 2 is used, then
a. the MGCF would use SIP URI as the Request or
b. an ENUM translation between tel URI and SIP URI will be made somewhere?
To me it seems reasonable to provision as a minimum only one SIP URI per usetr in the HSS, and leaving the tel URI to be treated by ENUM.
Comments?
BR
Kjell S.
Franz Edler
> To me it seems reasonable to provision as a minimum only one SIP URI per
> user in the HSS, and leaving the tel URI to be treated by ENUM.
No. You forgot that an IMS user also should have the possibility to call
users in PSTN. In this case it is necessary to always provide a tel URI in
P-Asserted-Identity header field, otherwise a CLI cannot be assigned if the
call terminates in PSTN.
Regards
Franz
Rogier Noldus
Hello Kjell,
Normally, a subscriber is provisioned with both a SIP URI and a Tel URI; or multiple SIP URIs etc. The Tel URI is needed for terminating call handling from the CS network, as you mention correctly. The Tel URI is also used for Calling line presentation when the call takes a breakout to CS domain. When the subscriber establishes a call with SIP URI as P-asserted-identity, PAI, (set by P-CSCF), then the SCSCF adds the Tel URI to the PAI. When the call takes a breakout to CS domain, then the Tel URI is used to set the Calling party number in ISUP IAM.
Bear the following in mind: when a call arrives from CS domain, then the MGCF may generate a SIP URI as Request URI, e.g. sip:+4612...@operator.se; user=phone. However, the destination party may not be provisioned in HSS under sip:+4612...@operator.se; user=phone. Rather, the destination party may be registered as sip:john....@enterprise.se and tel:+4612345678. So, I-CSCF transforms the R-URI from SIP URI format to Tel URI format. Now the I-CSCF queries HSS and HSS finds a match.
Anyway, complicated matter this SIP URI and Tel URI. Bottom line is that for being able to breakout calls to CS domain and receive calls from CS domain, the subscriber needs a Tel URI in HSS, in addition to SIP URI. The Tel URI and SIP URI will be placed in the same Registration set in HSS.
Regards
Rogier
-----Original Message-----
From: imstech...@imsforum.org [mailto:imstech...@imsforum.org] On Behalf Of kjell...@telenor.com
Sent: Wednesday, March 11, 2009 9:12 PM
To: ims...@imsforum.org
Subject: [IMS Tech] Use of tel URI - provisioning in the HSS
Hi,
Another question is how the tel URI is used in IMS. There are some guidelines on tel URI and ENUM, where the tel URI is translated to a SIP URI. Tel URI is not routable within IMS. But a session with a tel URI can be terminated in the IMS network if the HSS support the tel URI format Public User Identity. My understanding is that this will be a termination from e.g. fixed network when a routing decision has made that this is a user in the particular IMS network.
Amit Agarwala
I wonder how Google Voice shall get plugged into these legacy/IMS/Next-Gen domains. I am sure most would’ve already seen it, but just for the record:
Be very afraid: Google Voice has landed...
12/03/2009 - by TelecomTV One
Today is the day many in the telecoms industry have been expecting (and, let's face it, fearing) for years... well for at least 18 months. For it was in July 2007, after much rumour and speculation, that Google bought an Internet-based voice service called GrandCentral and locked itself in a room with it. Today it's revealed what it's been up to all that time. Google has entered the voice market.
http://web20.telecomtv.com/pages/?newsid=44648&id=e9381817-0593-417a-8639-c4c53e2a2a10
How do we think this shall change the telecom landscape?
Amit Agarwala
Hmm. Yes, I think “personalization” is lost in the whole game. “Presence” shall be another great one.
So if I were to summarize what you explained in detail (thank you):
- IMS should align focus to enhancing core next-gen pieces like enhance services through effective personalization etc.
- I also think that too much T&M is spent on the access layer side (call connection, call completion), ignoring the services that subscribers & businesses really need.
- If we aren’t careful, then Internet may takeover a lot of telecom functionality – I think we are already witnessing that threat
Thank you. I wear a dual head – product lead for an SCE/SDP as well as process lead for presales. Unenviable it becomes sometimes.
Warm regards,
Amit
From: alan lloyd
[mailto:alan....@wwite.com]
Sent: Wednesday, March 18, 2009
10:42 AM
To: am...@Amdale.com; ims...@imsforum.org
Subject: RE: [IMS Tech] Use of tel
URI - provisioning in the HSS
Thanks Amit – so much cruelty J… In a world that is all roses J
I agree with Tom too
I think the telco will be providing the cable/wire/wireless infrastructure and services such as govt and corporate for many years to come. What that means in terms of revenue really depends on govt policy, coverage, population and how rich the society is… OTT services like Gvoice will grow as did email as will distributed application services used between and within organisations.. The technical reason being Unix or windows “sockets” and port 80 .. any one can use IP connectors.. and web
As for SMS adverts yes – but personalization, opt in and click to buy… The ads have got to be good .
Where does that leave telco: Coming at IMS from a SDP / identity/and info engineering perspective I just see that the mechanisms of Diameter/AAA/HSS as being “its anchor to legacy” as it is technology which is dedicated to the mobile world – Whereas Internet and the commercial world have moved on to personalization and services and different forms of AAA.
I did mention a while back I thought Diameter /HSS was going to be a restriction for a truly end user oriented services rich IMS. No comments received – except they are the chosen standards.
IMHO The complexity of the AAA functions and its management and provisioning within systems is related to the service dimension and service differentiation offered.. IMS to date has focused on changes to the voice call method of connection (SS7 to SIP), and not the extensibility of its (personalized, self care) service management. Good old octet based Diameter – is the choice. Please correct me too if I have that wrong.
So if IMS is to move on it has to deal with end user “services” instead of user to user connections and rework its AAA to be more extensive ( as per a service delivery platform ) – I also have to respect that operators and OTT businesses have their rights to their own businesses and technologies..
Best wishes alan
From: Amit Agarwala
[mailto:am...@amdale.com]
Sent: Wednesday, March 18, 2009
2:33 PM
To: alan....@wwite.com;
ims...@imsforum.org
Subject: RE: [IMS Tech] Use of tel
URI - provisioning in the HSS
Hi Alan,
Yes, cruelly, it is more a business topic than technology. Let me rephrase it, though may become a little tangential.
Tom commented yesterday (with respect to Broadband operators) that “They don’t see the OTT players as access competitors; they see them as service competitors”. I think this holds for Carriers too.
That said, Google Voice is just the big named one, but falls into the same class of apps being discussed – Skype / GTalk / etc that are access agnostic. The last vestiges of operators unwilling to share networks are dying (one such example http://web20.telecomtv.com/pages/?newsid=44661&id=e9381817-0593-417a-8639-c4c53e2a2a10).
We’ve already witnessed advertising led free SMSs (http://www.160by2.com/ is one – 80 char message, 80 char advert). I think all get their money - operators (who charge regular money for the SMS), consumers (free SMS, though only 80 chars at a time). Advertisers are the only one shooting in the dark here. But so was the case with Google when AdSense started.
So in essence, technologically, do we think that legacy has enough punch left in it, with services being orthogonally built with IP on the periphery?
From: alan lloyd
[mailto:alan....@wwite.com]
Sent: Wednesday, March 18, 2009
5:54 AM
To: am...@Amdale.com;
ims...@imsforum.org
Subject: RE: [IMS Tech] Use of tel
URI - provisioning in the HSS
Hi I would like to answer this but it’s a forum question now not a tech one
BR alan
Amit Agarwala
Hi Alan,
Yes, cruelly, it is more a business topic than technology. Let me rephrase it, though may become a little tangential.
Tom commented yesterday (with respect to Broadband operators) that “They don’t see the OTT players as access competitors; they see them as service competitors”. I think this holds for Carriers too.
That said, Google Voice is just the big named one, but falls into the same class of apps being discussed – Skype / GTalk / etc that are access agnostic. The last vestiges of operators unwilling to share networks are dying (one such example http://web20.telecomtv.com/pages/?newsid=44661&id=e9381817-0593-417a-8639-c4c53e2a2a10).
We’ve already witnessed advertising led free SMSs (http://www.160by2.com/ is one – 80 char message, 80 char advert). I think all get their money - operators (who charge regular money for the SMS), consumers (free SMS, though only 80 chars at a time). Advertisers are the only one shooting in the dark here. But so was the case with Google when AdSense started.
So in essence, technologically, do we think that legacy has enough punch left in it, with services being orthogonally built with IP on the periphery?
From: alan lloyd
[mailto:alan....@wwite.com]
Sent: Wednesday, March 18, 2009
5:54 AM
To: am...@Amdale.com;
ims...@imsforum.org
Subject: RE: [IMS Tech] Use of tel
URI - provisioning in the HSS
Hi I would like to answer this but it’s a forum question now not a tech one
BR alan
alan lloyd
Thanks Amit , exactly… IMS - Too much T&M on a connection process in the telco paradigm, not enough on services in the new internet paradigm…
IMS - unless one is really careful perhaps will see some operators investing in it and then loosing out on the personalized services revenue base even faster..
I am developing material for customer centricity seminar at the moment…
One of the slides is about moving from the old world of transactions (connections) to “the productivity and cost of a transaction”… That is what does a user do when they log on, what do they see, what can they do that may earn revenue – and what does this system cost to operate – give a user may do 20 interactions to log on, send their presence status and search – and then spend a $...and make a micro payment… what has that system earnt? How does the telco BSS/OSS and IMS work in this micro revenue space?
New service delivery systems have to lightweight, fast and easy to prove and deploy..
Hope this helps
Best wishes alan
alan lloyd
Thanks Amit – so much cruelty J… In a world that is all roses J
I agree with Tom too
I think the telco will be providing the cable/wire/wireless infrastructure and services such as govt and corporate for many years to come. What that means in terms of revenue really depends on govt policy, coverage, population and how rich the society is… OTT services like Gvoice will grow as did email as will distributed application services used between and within organisations.. The technical reason being Unix or windows “sockets” and port 80 .. any one can use IP connectors.. and web
As for SMS adverts yes – but personalization, opt in and click to buy… The ads have got to be good .
Where does that leave telco: Coming at IMS from a SDP / identity/and info engineering perspective I just see that the mechanisms of Diameter/AAA/HSS as being “its anchor to legacy” as it is technology which is dedicated to the mobile world – Whereas Internet and the commercial world have moved on to personalization and services and different forms of AAA.
I did mention a while back I thought Diameter /HSS was going to be a restriction for a truly end user oriented services rich IMS. No comments received – except they are the chosen standards.
IMHO The complexity of the AAA functions and its management and provisioning within systems is related to the service dimension and service differentiation offered.. IMS to date has focused on changes to the voice call method of connection (SS7 to SIP), and not the extensibility of its (personalized, self care) service management. Good old octet based Diameter – is the choice. Please correct me too if I have that wrong.
So if IMS is to move on it has to deal with end user “services” instead of user to user connections and rework its AAA to be more extensive ( as per a service delivery platform ) – I also have to respect that operators and OTT businesses have their rights to their own businesses and technologies..
Best wishes alan
From: Amit Agarwala
[mailto:am...@amdale.com]
Sent: Wednesday, March 18, 2009
2:33 PM