Re: [Sip] Dual registration without Outbound

[Bob Penfield <[e-mail]>]

>-----Original Message-----
>From: Christer Holmberg [mailto:[e-mail]]
>Sent: Wednesday, October 15, 2008 4:04 AM
>To: Karthikeyan Gopal ; Bob Penfield; Elwell, John; Juha Heinanen; [e-mail]; Paul Kyzivat; Dean Willis
>Subject: RE: [Sip] Dual registration without Outbound
>
>
>Hi,
>
>>I guess the problem arises when you want to do a single REGISTER
>>request for both instances. If I the use case correctly, the UA would
>>send two REGISTER requests (one on each interface) and
>>both REGISTERs would have the two Contacts (one for each instance-id).
>>Something like this:
>>
>>First REGISTER to Outbound-proxy #1
>>
>>   REGISTER sip:example.com SIP/2.0
>>   Via: SIP/2.0/TCP 1.1.1.1;branch=z9hG4bKnashds7-1
>>   From: Bob <sip:[e-mail]>;tag=7F94778B653B-1
>>   To: Bob <sip:[e-mail]>
>>   Call-ID: 16CB75F21C70-1
>>   CSeq: 1 REGISTER
>>   Supported: path, outbound
>>   Route: <sip:ep1.example.com;lr>
>>   Contact: <sip:bob@1.1.1.1;transport=tcp>;reg-id=1
>>    ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
>>   Contact: <sip:bob@2.2.2.2;transport=tcp>;reg-id=2
>>    ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-BBCCDDEEFF00>"
>>
>>Second REGISTER to Outbound-proxy #2
>>
>>   REGISTER sip:example.com SIP/2.0
>>   Via: SIP/2.0/TCP 2.2.2.2;branch=z9hG4bKnashds7-2
>>   From: Bob <sip:[e-mail]>;tag=7F94778B653B-2
>>   To: Bob <sip:[e-mail]>
>>   Call-ID: 16CB75F21C70-2
>>   CSeq: 1 REGISTER
>>   Supported: path, outbound
>>   Route: <sip:ep2.example.com;lr>
>>   Contact: <sip:bob@2.2.2.2;transport=tcp>;reg-id=1
>>    ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-BBCCDDEEFF00>"
>>   Contact: <sip:bob@1.1.1.1;transport=tcp>;reg-id=2
>>    ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
>>
>>Thus the UA could receive requests for either Contact on either of the
>>two outbound flows.
>>
>>Is having two UA instances in the same request legal with the current
>>text?
>
>Isn't the edge proxy always going to send incoming request (towards the
>UA) to the address/port where the REGISTER came from, in order for the
>request to traverse the NAT?
>

That is exactly the desired effect. Since outbound ignores the Contact's address and sends it over the existing connection and it arrives over the interface that the REGISTER was sent on.

I did not see anything in Outbound that defines how the Authoritative Proxy chooses between the flows for a given contact, but, if it always tried reg-id=1 (i.e. the lowest reg-id) first, then if both flows were still up, two request would be forked (one on each flow) and the one for 1.1.1.1 would arrive on the interface for 1.1.1.1 and the other for 2.2.2.2 would arrive on the interface for 2.2.2.2.

If one of the flows was down, both requests would arrive on the other flow.

>So, I don't think you can perform the kind of "third party registration"
>which your example shows.

This is not really 3rd party registration since both requests arrive at the single User Agent that happens to have two Contact Instances.

>
>Regards,
>
>Christer
>





-----Original Message-----
From: Elwell, John [mailto:[e-mail]]
Sent: Tuesday, October 14, 2008 11:02 AM
To: Bob Penfield; Christer Holmberg; Juha Heinanen; [e-mail]; Paul
Kyzivat; Dean Willis
Subject: RE: [Sip] Dual registration without Outbound



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Bob Penfield
> Sent: 14 October 2008 15:41
> To: Christer Holmberg; Juha Heinanen; [e-mail]; 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
[e-mail] for questions on current sip Use
[e-mail] for new developments on the application of sip

DISCLAIMER:
------------------------------------------------------------------------
-----------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its
affiliates. Any views or opinions presented in this email are solely
those of the author and may not necessarily reflect the opinions of HCL
or its affiliates.
Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and / or publication of this message without
the prior written consent of the author of this e-mail is strictly
prohibited. If you have received this email in error please delete it
and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.

------------------------------------------------------------------------
-----------------------------------------------
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip