Subject: [Sipping] RE: Question on draft-ejzak-sipping-p-em-auth-01.txt

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Fri, 7 Jul 2006 09:47:42 -0500

Hi Gonzalo,
I tried to make clear in the draft that the procedures are needed when gating is performed near the UAs and not at the border.

If gating procedures were defined for the IMS IBCF/TrGW, it could perform the role you describe for outgoing traffic.  According to current procedures, the TrGW is only allocated to perform IP version interworking, and performs no gating.

Since a TrGW is not otherwise needed in many interconnect scenarios, the header provides a very efficient way of signaling the need for gating to the P-CSCF (or other gating entity at the originating side).

Another use case to consider is when IMS is transiting traffic from one network to another.  In this case the originating network may have a different early media policy than the transit network, so you would not want to force the transit network policy on the originating network.

Richard

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Friday, July 07, 2006 4:58 AM
> To: [email-masked]
> Cc: sipping
> Subject: Question on draft-ejzak-sipping-p-em-auth-01.txt
> 
> 
> Hi,
> 
> the draft now talks a great deal about how the network will open and 
> close its gates to authorized and unauthorized early media 
> respectively. 
> However, it seems that you can implement this gating function 
> in every 
> scenario at the terminating side without any extension:
> 
> 1) if an INVITE arrives to an IMS terminal, the terminal's 
> P-CSCF will 
> make sure that the PCRF does not allow early media in any direction.
> 
> 2) if an INVITE arrives to a PSTN gateway, the gateway will 
> allow early 
> media in both directions.
> 
> 3) if an INVITE arrives to an AS, the AS will allow early media in 
> whatever direction it needs.
> 
> 4) if an INVITE leaves the IMS network (i.e., the trusted 
> domain), the 
> I-BCF will not allow early media in any direction.
> 
> Could you please clarify in which scenarios this extension is 
> needed in 
> order to perform the gating function?
> 
> Thanks,
> 
> Gonzalo
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 12 Jul 2006 01:02:29 +0300

Hi,

> I tried to make clear in the draft that the procedures
> are needed when gating is performed near the UAs and not at the
> border.
> 
> If gating procedures were defined for the IMS IBCF/TrGW, it could
> perform the role you describe for outgoing traffic.

So, is there a requirement that unauthorized early media needs to be cut 
as close to the UA as possible?

> Since a TrGW is not otherwise needed in many interconnect scenarios,
> the header provides a very efficient way of signaling the need for
> gating to the P-CSCF (or other gating entity at the originating
> side).

If the idea is not to have an SBC (including a media proxy) when going 
from the IMS to the public Internet, then this may make sense. If 
effectively, everybody will implement such an SBC in their networks, 
this arguments would be quite weak.

> Another use case to consider is when IMS is transiting traffic from
> one network to another.  In this case the originating network may
> have a different early media policy than the transit network, so you
> would not want to force the transit network policy on the originating
> network.

Could you elaborate on this? What do you mean by transit network? It 
seems that the originating and the terminating networks would not be 
part of the trusted domain, and so, it would not be possible to use this 
header.

Cheers,

Gonzalo