Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01

   From: Dean Willis <dean.willis@softarmor.com>

   I have yet to figure out how a multiuser UA  (including an event  
   server) is supposed to function if:

   1) The To: field does not indicate the user being targeted, which  
   happens if a UAC-side proxy retargets, as in the case of a speed-dial  
   service, and

   2) The request-URI does not indicate the user being targeted, which  
   happens in many cases including when the UAS-side proxy does contact- 
   routing AND the user-part of the contact isn't differentiated per- 
   user. It also occurs with some load-balancers. That's part of why we  
   don't specify bulk registration in RFC 3261, but instead recommend  
   using routing table entries.

This has been a known problem for ages -- a UA should register
different contacts for different AORs, so when a request comes in it
knows which AOR (which "line appearance") the request concerns.  I
wrote this in Oct. 2005 (draft-worley-sip-gruu-implement-00), and it
was old information then:

   As detailed below, when responding to requests, the UA should use the
   GRUU associated with the AOR through which the request was routed to
   the UA.  In order to ensure that the UA can determine this, it should
   register distinct URIs for each AOR it services.  (The From header
   may contain a different AOR which was routed to one of the UA's AORs,
   and so can not be depended on to provide the AOR through which the
   request was routed to the UA.)

      Guideline: The UA should register distinct URIs for each AOR it
      services.  (Note that it is not sufficient to generate from each
      AOR a contact 'sip:{user-part}@{IP-address}', since it is common
      for a UA to service two AORs with the same user part in different
      domains.)

Dale
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip