Hi, 

>>But, in scenarios where the outbound- and registrar proxies are NOT 
>>co-located, and only one registrar is used, I see no reason why people

>>shall be forced to register both contacts to both outbound 
>>proxies. In cases where the contact is access network dependent it may

>>not even be possible to do so.
> 
>I don't understand the last statement. You can put *any* 
>syntactically valid URI in a Contact of a REGISTER.

Yes, but syntactically valid does not necessarily mean globablly
reachable.

For example, the contacts could be part of private address domain, and
the edge proxy itself performs the NATting for that address domain. In
that case the contact can only be reached via those specific edge
proxy/proxies.

Another example is when different IP versions are used. An IPv6 contact
can't be registered with an IPv4 edge proxy (unless you have a IP
version converter in between, that is).


BUT, I don't think the main issue is whether a contact CAN be registerd
with all edge proxies, but WHY one would be mandated to do so.

Outbound provides you with multiple flows to reach a user. I doesn't
matter if each flow is not associated with the same contact, as long as
the user can be reached on any of the flows.

Regards,

Christer



> Perhaps you mean it won't work once registered, when combined 
> with the resulting Service-Route. In that case the edge proxy 
> (P-CSCF) may be asked to route to a URI that is not on the 
> access network that it is intended to use. But I guess that 
> is just one aspect of the closed nature of 3gpp.
> 
> The problem I see developing here is the idea that the 
> registration behavior of the UA is dependent on its 
> understanding the topology of the network. Its one thing to 
> expect it to know of a couple of attachment points. Its 
> another thing to expect it to know more about what is behind 
> those attachment points.
> 
>       Thanks,
>       Paul
> 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Reply via email to