Hi, > Thank you. Looking again and comparing both the Scenarios, I think in > Scenario-1, the GRUU is present while in Scenario-2, the GRUU is absent. > Does this make a difference in CSCF interpreting the Contact URI parameter?
Not in general. But, again, in order to find out whether the GRUU has impacts on the ue-addr parameter you would have to ask the S-CSCF vendor, because there is no standard that defines the procedures for ue-addr. Regards, Christer On Mon, Oct 7, 2019 at 4:28 AM Christer Holmberg <mailto:christer.holmb...@ericsson.com> wrote: Hi, Since there is no standard specification (AFAIK) specifying the usage ue-addr I think you would have to ask the S-CSCF vendor about the behavior. Regards, Christer From: Ranjit Avasarala <mailto:ranjitka...@gmail.com> Date: Monday, 7 October 2019 at 6.42 To: Philipp Schöning <mailto:schoenin...@gmail.com>, "mailto:Sip-implementors@lists.cs.columbia.edu"; <mailto:Sip-implementors@lists.cs.columbia.edu>, Christer Holmberg <mailto:christer.holmb...@ericsson.com>, "mailto:pkyzi...@alum.mit.edu"; <mailto:pkyzi...@alum.mit.edu> Subject: Re: [Sip-implementors] Fwd: ue-addr parameter in SIP Contact header 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 <mailto: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 mailto: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
