Ranjit,

Based on the further detail you provide below I conclude that this is most likely a question about 3GPP IMS behavior and specifications. I suggest that you take this to a 3GPP forum. (I don't know what that would be. Hopefully one of the people here who are involved in 3GPP can make say more.)

        Thanks,
        Paul

On 10/6/19 11:42 PM, Ranjit Avasarala wrote:
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 <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
    Sip-implementors@lists.cs.columbia.edu
    <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

Reply via email to