Hi Philip Yes, I agree that connection and relation to UE are maintained by P-CSCF and S-CSCF does not need them. But in some call scenarios, the S-CSCF connects to subsequent network elements like MRF and it is supposed to pass the "ue-addr" parameter it receives from P-CSCF (in Contact header) as is - without removing it
E.g. there are 2 scenarios Scenario-1: INVITE from Access-SBC to S-CSCF with ue-addr: Contact: *<sip:+12139598...@pcsf-prim.imsgroup0-017.wb3il01pcf.wb1il.uvp.itn.att.net:5060;gr=urn:uuid:227deca7-0d76-4ca6-8b5a-3ba63e6c4b89;b2bdlg=5cc32c49-5d93a27231a5f4a9-mw-po-lucentPCSF-000050;ue-addr=205.173.58.13>;+g.3gpp.icsi* -ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video;mobility="fixed" Scenario-2: INVITE from Interconnect SBC to S-CSCF with ue-addr: Contact: *<sip:+13139588066@[2001:1890:1001:2ff4::15]:5060;ue-addr=208.86.89.249>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting;+g.3gpp.ps2cs-srvcc-orig-pre-alerting* In case of Scenario-1: the S-CSCF is passing the ue-addr in Contact as is towards next hop but in Scenario-2, the S-CSCF is removing the ue-addr before passing the INVITE to next hop Question: why is S-CSCF removing ue-addr parameter in Scenario-2 and not removing in Scenario-1? Does the position of ue-addr parameter in Contact header matter? On Sun, Oct 6, 2019 at 12:00 PM Philipp Schöning <schoenin...@gmail.com> wrote: > Hi Ranjit, > > I can't answer the question, but I have another question: > Isn't the connection and relation to the UE maintained by the P-CSCF? > > From my perspective the S-CSCF does not have any relation to the UE. > > BR > Philipp > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
