Hi Christer 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?
Regards Ranjit On Mon, Oct 7, 2019 at 4:28 AM Christer Holmberg < 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 <ranjitka...@gmail.com> > *Date: *Monday, 7 October 2019 at 6.42 > *To: *Philipp Schöning <schoenin...@gmail.com>, " > Sip-implementors@lists.cs.columbia.edu" < > Sip-implementors@lists.cs.columbia.edu>, Christer Holmberg < > christer.holmb...@ericsson.com>, "pkyzi...@alum.mit.edu" < > 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 <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
