Hi Daniel, Ok, I’ll try to explain more on this. We have an application server configured in the HSS with triggers to receive third party Register requests when the UE registers with the IMS core. The application server does receive the Register message when the UE registers but the register message does not contain all the information from the original Register request to the PCSCF. In particular, the UE sends a JWT token in the body of the Register message. The application server needs this information and according to 3GPP TS 24.229 this should be supported by the SCSCF with a configuration option in the HSS called “IncludeRegisterRequest”. When this configuration option is used the third party Register message sent to the application server will contain the original register message in the body of the register message. So, we’re looking for the SCSCF to do this. At this point as long as we can get the original Register request in the contents of the Third party register request it should be enough. Any help on this would be very appreciated. FYI … Below is an excerpt from the specification. 5.4.1.7A Including contents in the body of the third-party REGISTER request If there is a service information XML element provided in the HSS Filter Criteria for an AS (see 3GPP TS 29.228 [14]), then in the third-party REGISTER request the S-CSCF shall: - include in the message body the service information within the <service-info> XML which is a child XML element of an <ims-3gpp> element with the "version" attribute set to "1" element as described in subclause 7.6; and - set the value of the content type to the MIME type specified in subclause 7.6. If there is an Include Register Request XML element provided in the HSS Filter Criteria for an AS (see 3GPP TS 29.228 [14]), then in the third-party REGISTER request the S-CSCF shall: - include in the message body the incoming SIP REGISTER request within a "message/sip" MIME body as defined in RFC 3261 [26]; and - set the value of the content type to "message/sip". If there is an Include Register Response XML element provided in the HSS Filter Criteria for an AS (see 3GPP TS 29.228 [14]), then in the third-party REGISTER request, the S-CSCF shall: - include in the message body the 200 (OK) response to the incoming SIP REGISTER request within a "message/sip" MIME body as defined in RFC 3261 [26]; and - set the value of the content type to "message/sip". If there is more than one message body to be included in the third-party REGISTER request then in the third-party REGISTER request the S-CSCF shall: - include a multipart message body and set the value of the Content-Type header field to "multipart/mixed" as specified in RFC 2046 [149] and RFC 5621 [150]; and - set the Content-Type of the elements of the MIME body to the content type specified for the body. If there is only one message body to be included in the third-party REGISTER request then the S-CSCF sets the Content-Type header field to the content type specified for the body. From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Daniel-Constantin Mierla Sent: Wednesday, May 17, 2017 8:43 AM To: Kamailio (SER) - Users Mailing List &lt;sr-users(a)lists.kamailio.org&gt; Subject: Re: [SR-Users] IMS: Including contents in the body of third-party REGIISTER request. Hello, maybe you can give a more specific example of what is happening and what you would like to get. There might be some operations in the config scripting that can help. Cheers, Daniel On 16.05.17 17:31, Haggerty, Paul (phaggert) wrote: It looks like the Kamailio IMS modules don’t support including the original REGISTER request in third party registrations as defined in 3GPP TS 24.229. Can someone confirm this? Should this be a tracked defect or enhancement? In the meantime, is there any workaround available? Our application server needs to get the contents from the original REGISTER message from the UE. Thanks, Paul _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla www.twitter.com/miconda<http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda> Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com<http://www.asipto.com> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com<http://www.kamailioworld.com>

Hi, No the Register request is not sent out via Diameter, it is sent out via SIP. The Register request works just like any Third party register message except the SCSCF also includes the contents of the original Register request (from the UE) in the SIP message body. Paul From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: Thursday, May 18, 2017 4:16 AM To: Haggerty, Paul (phaggert) (U.S. Person) &lt;phaggert(a)harris.com&gt;om>; Kamailio (SER) - Users Mailing List &lt;sr-users(a)lists.kamailio.org&gt; Subject: Re: [SR-Users] IMS: Including contents in the body of third-party REGIISTER request. Hello, so, the register request has to be sent out in this case via diameter? If yes, then not much to be done in kamailio.cfg, needs an enhancement in the c code, if not supported yet -- IMS devs can comment more, I don't do much in that part of the code. Cheers, Daniel On 17.05.17 15:47, Haggerty, Paul (phaggert) wrote: Hi Daniel, Ok, I’ll try to explain more on this. We have an application server configured in the HSS with triggers to receive third party Register requests when the UE registers with the IMS core. The application server does receive the Register message when the UE registers but the register message does not contain all the information from the original Register request to the PCSCF. In particular, the UE sends a JWT token in the body of the Register message. The application server needs this information and according to 3GPP TS 24.229 this should be supported by the SCSCF with a configuration option in the HSS called “IncludeRegisterRequest”. When this configuration option is used the third party Register message sent to the application server will contain the original register message in the body of the register message. So, we’re looking for the SCSCF to do this. At this point as long as we can get the original Register request in the contents of the Third party register request it should be enough. Any help on this would be very appreciated. FYI … Below is an excerpt from the specification. 5.4.1.7A Including contents in the body of the third-party REGISTER request If there is a service information XML element provided in the HSS Filter Criteria for an AS (see 3GPP TS 29.228 [14]), then in the third-party REGISTER request the S-CSCF shall: - include in the message body the service information within the <service-info> XML which is a child XML element of an <ims-3gpp> element with the "version" attribute set to "1" element as described in subclause 7.6; and - set the value of the content type to the MIME type specified in subclause 7.6. If there is an Include Register Request XML element provided in the HSS Filter Criteria for an AS (see 3GPP TS 29.228 [14]), then in the third-party REGISTER request the S-CSCF shall: - include in the message body the incoming SIP REGISTER request within a "message/sip" MIME body as defined in RFC 3261 [26]; and - set the value of the content type to "message/sip". If there is an Include Register Response XML element provided in the HSS Filter Criteria for an AS (see 3GPP TS 29.228 [14]), then in the third-party REGISTER request, the S-CSCF shall: - include in the message body the 200 (OK) response to the incoming SIP REGISTER request within a "message/sip" MIME body as defined in RFC 3261 [26]; and - set the value of the content type to "message/sip". If there is more than one message body to be included in the third-party REGISTER request then in the third-party REGISTER request the S-CSCF shall: - include a multipart message body and set the value of the Content-Type header field to "multipart/mixed" as specified in RFC 2046 [149] and RFC 5621 [150]; and - set the Content-Type of the elements of the MIME body to the content type specified for the body. If there is only one message body to be included in the third-party REGISTER request then the S-CSCF sets the Content-Type header field to the content type specified for the body. From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Daniel-Constantin Mierla Sent: Wednesday, May 17, 2017 8:43 AM To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org><mailto:sr-users@lists.kamailio.org> Subject: Re: [SR-Users] IMS: Including contents in the body of third-party REGIISTER request. Hello, maybe you can give a more specific example of what is happening and what you would like to get. There might be some operations in the config scripting that can help. Cheers, Daniel On 16.05.17 17:31, Haggerty, Paul (phaggert) wrote: It looks like the Kamailio IMS modules don’t support including the original REGISTER request in third party registrations as defined in 3GPP TS 24.229. Can someone confirm this? Should this be a tracked defect or enhancement? In the meantime, is there any workaround available? Our application server needs to get the contents from the original REGISTER message from the UE. Thanks, Paul _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla www.twitter.com/miconda<http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda> Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com<http://www.asipto.com> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com<http://www.kamailioworld.com> -- Daniel-Constantin Mierla www.twitter.com/miconda<http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda> Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com<http://www.asipto.com> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com<http://www.kamailioworld.com>