> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Bob Penfield
> Sent: 14 October 2008 15:41
> To: Christer Holmberg; Juha Heinanen; [email protected]; Paul 
> Kyzivat; Dean Willis
> Subject: Re: [Sip] Dual registration without Outbound
> 
> For both GRUU and Outbound a given instance-id 
> (+sip-instance) actually represents a single UA contact 
> instance rather than just a single User Agent. The basic idea 
> behind GRUU is that a request addressed to a GRUU is 
> forwarded by the proxy to a specific Contact address. The 
> goal is the same with Outbound but it adds multiple 
> flows/paths to that UA Contact. This is reflected in the 
> proxy procedures in both GRUU and Outbound.
> 
> In both cases, the proxy does serial forking to Contacts with 
> the same instance-id.
> 
> For GRUU it starts with the most-recently registered binding 
> (according to section 6.1 of GRUU):
> 
>        The proxy MUST select the most recently refreshed
>        contact.  As with draft-ietf-sip-outbound, if a request to this
>        target fails with a 408 (Request Timeout) or 430 (Flow Failed)
>        response, the proxy SHOULD retry with the next most recently
>        refreshed contact.  Furthermore, if the request fails with any
>        other response, the proxy MUST NOT retry on any other contacts
>        for this instance.
> 
> For Outbound, it attempts the registered flows (according to 
> section 7 of Outbound):
> 
>    When a proxy uses the location service to look up a registration
>    binding and then proxies a request to a particular contact, it
>    selects a contact to use normally, with a few additional rules:
> 
>    o  The proxy MUST NOT populate the target set with more than one
>       contact with the same AOR and instance-id at a time.
>    o  If a request for a particular AOR and instance-id fails 
> with a 430
>       (Flow Failed) response, the proxy SHOULD replace the 
> failed branch
>       with another target (if one is available) with the same AOR and
>       instance-id, but a different reg-id.
>    o  If the proxy receives a final response from a branch 
> other than a
>       408 (Request Timeout) or a 430 (Flow Failed) response, the proxy
>       MUST NOT forward the same request to another target representing
>       the same AOR and instance-id.  The targeted instance has already
>       provided its response.
> 
> Therefore, a User Agent that is registering multiple Contacts 
> to allow the possibility of parallel forking would need to 
> have a separate instance-id for each Contact.
> 
> For User Agent's that have multiple interfaces, it could use 
> the MAC address of each interface to create a unique UUID URN 
> for each contact.
> 
> Thus, the following scenario is possible:
> 
>   UA_Contact_wlan;+sip-instance=ID_1;reg-id=1 ----- OB_1 ----- REG_1
>   UA_Contact_wlan;+sip-instance=ID_1;reg-id=2 ----- OB_2 ----- REG_2
>   UA_Contact_3g;+sip-instance=ID_2;reg-id=1   ----- OB_1 ----- REG_1
>   UA_Contact_3g;+sip-instance=ID_2;reg-id=2   ----- OB_2 ----- REG_2
> 
> Unfortunately, the current text in section 4.1 says that a UA 
> has "an Instance Identifier".
[JRE] In an earlier email I was trying to say roughly the same thing,
except the way I looked at it was that a device with multiple interfaces
would logically contain a UA for each interface, and each UA would than
have a single instance ID. In that case the text in section 4.1 still
works.

John
_______________________________________________
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