Re: [Sip-implementors] Fwd: ue-addr parameter in SIP Contact header

[Paul Kyzivat]

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: 
*;+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: 
*;+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 > 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

Re: [Sip-implementors] Fwd: ue-addr parameter in SIP Contact header

[Christer Holmberg]

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 
 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 
Date: Monday, 7 October 2019 at 6.42
To: Philipp Schöning , 
"mailto:Sip-implementors@lists.cs.columbia.edu; 
, Christer Holmberg 
, "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: 
;+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: 
;+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  
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

Re: [Sip-implementors] Fwd: ue-addr parameter in SIP Contact header

[Christer Holmberg]

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 
Date: Monday, 7 October 2019 at 6.42
To: Philipp Schöning , 
"Sip-implementors@lists.cs.columbia.edu" 
, Christer Holmberg 
, "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: 
;+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: 
;+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
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

Re: [Sip-implementors] Fwd: ue-addr parameter in SIP Contact header

[Ranjit Avasarala]

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 
> *Date: *Monday, 7 October 2019 at 6.42
> *To: *Philipp Schöning , "
> 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:
> *;+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:
> *;+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 
> 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