RE: Action item from yesterday's meeting

Francois,

Please see my comments below. Essentially, I assumed no-proxy. In the case
there is a proxy, Senthil pointed out a solution in which all UAs (i.e., UA1 as
well as UA2) have midcom agents on them and only the approved UAs are permitted
to talk with each other (P2P). Both examples (i.e,with or without proxy) would
work only when the midcom agents are able to specify realm-specific end-points
as input to their PER. 

regards,
suresh

> Cullen, 
> 
> Thanks for suggesting a new application and simplifying the 
> protocol sequence for the apllication. This, I believe, is 
> yet another example illustrating the problem with the current 
> model as you will see in my comments below. I am making the 
> following assumptions w.r.t. the example. Do let me know if 
> you disagree. Thanks. 
> 
> 1. I have not seen any mention of proxies. If you assume a 
> proxy, we need to redraw the picture with proxy in one of the 
> realms. So, I will assume no proxies. 
> 
> 2. The NAT middlebox in use is a twice NAT. I.e., It has 
> address maps to translate source and destination endpoints of 
> a session flow. A0, A1 are IP addresses in private space and 
> are non-overlapping with A2, A3 in the external address 
> space. For simplicity, let us assume, the address A1 is 
> statically mapped to A3 for destination endpoint on outbound flows. 
> 
> 3. There is a midcom agent on UA1 that is responsible for 
> interacting with NAT and ensuring that the application works 
> between UA1 and UA2. I.e., there is no other entitity outside 
> of UA1 that is acting as midcom agent. 
> 
> 3. Name service is external to this application. I.e., nodes 
> learn of IP addresses for a name from an independent name 
> service in their realm. So, when a caller UA1 uses its name 
> service to lookup UA2, it resolves to A1. This is because, 
> the private address space in the current example includes 
> just A0 and A1. 

I don't see how this is relevant. 

UA2 will send it's media address A3 in the SDP. This is why it 
will know A3. 

For signalling, UA1 will send the messages to wherever it's proxy 
is (which is a fixed address). 

[suresh] Francois - The assumption I made (Assumption #1) is that there is no
proxy. The UA1 will use name service to resolve the proxy to an IP address, if
there is a proxy. The underlying point is that each realm has a name service
that is indepndent of the application or the midcom agent and will return an
IP-address within the realm of the caller.

Or are you thinking about a case where U2 would use a FQDN instead 
of an IP address inside the SDP? 

In that particular case one would have to assume that this address 
is routable otherwise the FQDN would be meaningless. 

I'm getting more confused... 

[suresh] Senthil presented a solution in a follow on e-mail in response, which
assumes a proxy in the path. The calle's midcom agent will use (A2, A3) in its
medcom PER query to reserve an inbound session from UA2 to UA1. This will
facilitate the NATto permit inbound session.


> 4. In the outset, UA1 uses  name service to resolve UA2. Name 
> service returns the IP address of UA2 to be A1. 


=====