Have you seen this: https://trac.pjsip.org/repos/wiki/FAQ#ims ? Best regards, Benny On Sat, Nov 12, 2011 at 10:49 PM, steve <steven at timelessgardens.com> wrote: > I believe this might be needed from standards 24229**** > > ** ** > 5.1.1.2.2 Initial registration using IMS AKA**** > > On sending a REGISTER request, as defined in subclause 5.1.1.2.1, the UE > shall additionally populate the header fields as follows:**** > > a) an Authorization header field, with:**** > > - the "username" header field parameter, set to the value of the > private user identity;**** > > - the "realm" header field parameter, set to the domain name of the > home network;**** > > - the "uri" header field parameter, set to the SIP URI of the domain > name of the home network;**** > > - the "nonce" header field parameter, set to an empty value; and**** > > - the "response" header field parameter, set to an empty value;**** > > NOTE 1: If the UE specifies its FQDN in the hostport parameter in the > Contact header field and in the sent-by field in the Via header field, then > it has to ensure that the given FQDN will resolve (e.g., by reverse DNS > lookup) to the IP address that is bound to the security association.**** > > NOTE 2: The UE associates two ports, a protected client port and a > protected server port, with each pair of security association. For details > on the selection of the port values see 3GPP TS 33.203 [19].**** > > b) additionally for the Contact header field, if the REGISTER request is > protected by a security association, include the protected server port > value in the hostport parameter;**** > > c) additionally for the Via header field, for UDP, if the REGISTER > request is protected by a security association, include the protected > server port value in the sent-by field; and**** > > d) a Security-Client header field set to specify the signalling plane > security mechanism the UE supports, the IPsec layer algorithms the UE > supports and the parameters needed for the security association setup. The > UE shall support the setup of two pairs of security associations as defined > in 3GPP TS 33.203 [19]. The syntax of the parameters needed for the > security association setup is specified in annex H of 3GPP TS 33.203 [19]. > The UE shall support the "ipsec-3gpp" security mechanism, as specified in > RFC 3329 [48]. The UE shall support the IPsec layer algorithms for > integrity and confidentiality protection as defined in 3GPP TS 33.203 [19], > and shall announce support for them according to the procedures defined in > RFC 3329 [48].**** > > On receiving the 200 (OK) response to the REGISTER request defined in > subclause 5.1.1.2.1, the UE shall additionally:**** > > 1) If the UE supports multiple registrations and the REGISTER request > contained the "+sip.instance" header field parameter and the "reg-id"header field parameter in the Contact header field, and the "outbound" > option-tag in the Supported header field, the UE shall check whether the > option-tag "outbound" is present in the Require header field. If the > option-tag "outbound" is present, then the UE shall use the bidirectional > flow as defined in RFC 5626 [92] as follows:**** > > a) for UDP, the bidirectional flow consists of two unidirectional flows, > i.e. the first unidirectional flow is identified with the UE's protected > client port, the P-CSCF's protected server port, and the respective IP > addresses. The UE uses this flow to send the requests and responses to the > P-CSCF. The second unidirectional flow is identified with the P-CSCF's > protected client port, the UE's protected server port and the IP addresses. > The second unidirectional flow is used by the UE to receive the requests > and responses from the P-CSCF; or**** > > b) for TCP, the bidirectional flow is the TCP connection between the UE > and the P-CSCF. This TCP connection was established by the UE, i.e. from > the UE's protected client port and the UE's IP address to the P-CSCF's > protected server port and the P-CSCF's IP address. This TCP connection is > used to exchange SIP messages between the UE and the P-CSCF; and**** > > 2) set the security association lifetime to the longest of either the > previously existing security association lifetime (if available), or the > lifetime of the just completed registration plus 30 seconds.**** > > NOTE 3: If the UE receives Authentication-Info, it will proceed > as described in RFC 3310 [49].**** > > When a 401 (Unauthorized) response to a REGISTER is received the UE shall > behave as described in subclause 5.1.1.5.1.**** > > ** ** > > not 100% sure but getting closer**** > > ** ** > > ** ** > ------------------------------ > > *From:* steve [mailto:steven at timelessgardens.com] > *Sent:* Saturday, November 12, 2011 9:34 AM > *To:* 'pjsip at lists.pjsip.org' > *Subject:* lte over IMS**** > > ** ** > > Any chance of getting3FPP lte/ims auth, headers, with secureSIP > incorporated into PJSIP? p.s. As far as i can tell its not**** > > Looking around competitors like Doubango may support via IMSDroid -- > like to see pjsip/pjsua set up ......**** > > As a pjsip advocate, please advice??**** > > thanks in advance**** > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20111115/187b7407/attachment.html>
