Subject: [Sip] Dual registration without Outbound

From: Dean Willis <[email-masked]>
Date: Sun, 5 Oct 2008 20:07:39 -0500

I'm hearing from some people that they're being forced to use Outbound  
even when there are no NATs to consider, because Outbound is the only  
way for a device to have dual registrations.

Personally, I seem to remember some systems that were doing multiple  
registrations long before Outbound, so I'm wondering who's missing  
what here, and what if anything we need to document or specify.

Thoughts?

--
Dean

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

---

From: <[email-masked]>
Date: Mon, 6 Oct 2008 08:40:59 +0300

Hi,

Problem with dual registrations without Outbound comes
with forking. When a device registers itself twice with
different Contact addresses, it will receive every request
destined to the AOR twice if the server implements parallel
forking or if the device rejects the first forked request.
 
On the other hand if the contact addresses are the same within
the dual registrations, without Outbound that is just a
registration refresh instead of dual registration, correct ?

Please tell if I miss some point of specified behaviour here.

For instance 3GPP is considering using Outbound to solve
this problem of multiple registrations even if there would 
not be any NATs in the access network.

---
A long time ago I posted a long email suggesting Outbound
to be split to two drafts, addressing two different problems:

- One that specifies the keepalive behaviour (needed for NATs)
- One that specifies multiple registration behaviour
  (needed for increased reliability) 

But it was not very popular suggestion and did not get
many responses. Perhaps the suggestion was raised too late,
at that time many were just waiting to get Outbound frozen
and published as RFC.

Regards,

Erkki

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Dean Willis
>Sent: 06.October.2008 04:08
>To: SIP IETF
>Subject: [Sip] Dual registration without Outbound
>
>

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 6 Oct 2008 08:51:18 +0300

> forking or if the device rejects the first forked request.

erkki,

i thought that dean meant with "dual registration" registering with two
different registrars (e.g. two srv records for the same domain).  in
that case, your problem does not occur if proxies are also paired with
the two registrars.

 >   (needed for increased reliability) 

and third draft should be about connection re-use.  

if iesg or whoever still exists whose task is to keep rfcs sane, it
should definitely bounce outbound i-d back to the working group so that
it can do the right thing rather that rushing outbound that only
includes application specific solution to these generic problems.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Oct 2008 08:01:13 +0200

Hi,

The 3GPP case actually talks about multiple registrations with the SAME
registrar. 

But, I don't think there will be a forking problem, because I assume the
instance-id will still be the same for all registrations from the same
UA.

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juha Heinanen
Sent: Monday, October 06, 2008 8:51 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Sip] Dual registration without Outbound

[email-masked] writes:

 > Problem with dual registrations without Outbound comes  > with
forking. When a device registers itself twice with  > different Contact
addresses, it will receive every request  > destined to the AOR twice if
the server implements parallel  > forking or if the device rejects the
first forked request.

erkki,

 > A long time ago I posted a long email suggesting Outbound  > to be
split to two drafts, addressing two different problems:
 >
 > - One that specifies the keepalive behaviour (needed for NATs)  > -
One that specifies multiple registration behaviour

-- juha

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

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 6 Oct 2008 09:05:24 +0300

> The 3GPP case actually talks about multiple registrations with the SAME

like registering over 3g and wlan?

 > instance-id will still be the same for all registrations from the same

in the above case, i would definitely want inbound call to be forked.

-- juha

---

From: <[email-masked]>
Date: Mon, 6 Oct 2008 09:14:27 +0300

Hi, 

>different registrars (e.g. two srv records for the same domain).

Not sure, perhaps. Hope that Dean will clarify what he meant and
whether I misunderstood his terminology.

>that case, your problem does not occur if proxies are also paired with

But even in that case I can not follow. Yes I see that is possible
without Outbound but on the other hand I fail to see Outbound providing
any added value for such a setup.

Or is the point exactly that :

- without Outbound you need multiple different registrars (having
different
  srv records for them) for such dual registration ?

- but with Outbound you could do similar thing with one single registrar
  while having multiple (or multihomed) proxies ?

Regards,

Erkki

>From: ext Juha Heinanen [mailto:[email-masked]] 
>Sent: 06.October.2008 08:51
>To: Koivusalo Erkki (Nokia-D/Helsinki)
>Cc: [email-masked]; [email-masked]

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 6 Oct 2008 09:23:19 +0300

> any added value for such a setup.

i'm not claiming that outbound gives any additional value.  it would
have given if it had forced dual registration when there is two outbound
proxies in the set.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Oct 2008 08:35:47 +0200

Hi, 

>>The 3GPP case actually talks about multiple registrations with the
SAME  > registrar. 
>like registering over 3g and wlan?

Yes, for example.

>>But, I don't think there will be a forking problem, because I assume
the instance-id will still be the same for all 
>>registrations from the same UA.
>

If you want to do that you simply register the same AoR twice using
basic 3261 registration, without Outbound, and the inbound call will be
forked. 

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Mon, 6 Oct 2008 01:35:59 -0500

> whether I misunderstood his terminology.

I wish I knew what I meant, actually.

The case I was asked about was in 3GPP-type networks. The one I'm  
familiar with is registering to two different proxies, as Juha  
described.

Apparently they are not the same.

Does IMS really need for a single UA to have two different  
registrations with one registrar, and for the requests to that UA to  
not be forked?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 6 Oct 2008 01:40:49 -0500

> have given if it had forced dual registration when there is two  

Outbound-15 4.2.1 says:

For each outbound proxy URI in the set, the UAC SHOULD send a REGISTER  
request using this URI as the default outbound proxy. (Alternatively,  
the UA could limit the number of flows formed to conserve battery  
power, for example). If the set has more than one URI, the UAC MUST  
send a REGISTER request to at least two of the default outbound  
proxies from the set.

As far as I can tell, that means that the UAC must dual register when  
there are two proxies.

Section 3.4 of Outbound, BTW, talks about how to dual-register with  
one registrar WITHOUT outbound.
--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 6 Oct 2008 09:43:25 +0300

> basic 3261 registration, without Outbound, and the inbound call will be

are you saying that if i use outbound, then the inbound call will NOT get
forked (which would be very bad)?

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Oct 2008 08:46:02 +0200

Hi, 

>The case I was asked about was in 3GPP-type networks. The one I'm
familiar with is registering to two different proxies,
>as Juha described.
registrations with one registrar, and for the requests to that
>UA to not be forked?

I don't have the exact 3gpp requirement in front of me, but in my
understanding the answer is Yes. And, AFAIU it has been decided to use
the Outbound mechanism for that.

I will take a look whether it would require any changes to the Outbound
spec, but at the moment I can't think of any. 

Keep-alives will not be sent in non-NAT scenarios, so I guess one
question is whether the Outbound spec assumes there are always NATs, and
therefor always requires keep-alives for Outbound flows.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Oct 2008 08:50:28 +0200

Hi, 

>>If you want to do that you simply register the same AoR twice using
basic 3261 registration, without Outbound, and the >>inbound call will
be forked. 
>
>are you saying that if i use outbound, then the inbound call will NOT
get forked (which would be very bad)?

I thought the whole idea of outbound was that the registrar chooses ONE
flow, and switches to another flow is the previous doesn't work. But, it
does not fork onto multiple flows.

Or, have I missunderstood everything???

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Oct 2008 08:54:34 +0200

Subclause 3.1 says the following:

"When a proxy goes to route a message to a UA for which it has a
   binding, it can use any one of the flows on which a successful
   registration has been completed.  A failure to deliver a request on a
   particular flow can be tried again on an alternate flow.  Proxies can
   determine which flows go to the same UA by comparing the
instance-id."

Note that the text says "can use ONE of the flows". So, to me that
doesn't mean that the request will be forked on multiple flows.

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christer Holmberg
Sent: Monday, October 06, 2008 9:50 AM
To: Juha Heinanen
Cc: [email-masked]; [email-masked]
Subject: Re: [Sip] Dual registration without Outbound

Hi, 

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 6 Oct 2008 09:57:33 +0300

> send a REGISTER request to at least two of the default outbound  

i thought that i lost this battle, but it is a nice surprise that the
text has been changed and with two proxies in the set, ua MUST register
with both.

now if the ua has two network interfaces (3g and wlan, for example) and
the user want to use both of them simultaneously, is it so that inbound call
gets forked?

and further, is there any text anywhere forcing the ua to register both
of its contacts with both proxies?

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 6 Oct 2008 09:59:03 +0300

> does not fork onto multiple flows.

yes, but if the UA has two contacts, e.g. wlan and 3g, as i asked in the
previous post?

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 6 Oct 2008 10:04:07 +0300

> doesn't mean that the request will be forked on multiple flows.

christer,

that makes sense, if both registrations use the same contact, but not,
if UA registers with two different contacts.  in that case, there MUST
be four registrations, two via both ob proxies and inbound call MUST get
forked.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Oct 2008 09:06:54 +0200

Hi, 

 > Note that the text says "can use ONE of the flows". So, to me that  >
>that makes sense, if both registrations use the same contact, but not,
if UA registers with two different contacts.  in 
>that case, there MUST be four registrations, two via both ob proxies
and inbound call MUST get forked.

I don't see any mentioning of the contact in the text above - it only
talks about instance-id.

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 6 Oct 2008 10:18:40 +0300

> I don't see any mentioning of the contact in the text above - it only

then the ua must use two instance ids (one for each contact) or outbound
i-d must be changed to allow forking if contacts are not the same.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Oct 2008 09:30:05 +0200

Hi, 

talks about instance-id.
>
>then the ua must use two instance ids (one for each contact) or
outbound i-d must be changed to allow forking if contacts >are not the
same.

I guess we would need to check whether the spec FORBIDS forking, but my
point was that I don't see any text which would REQUIRE forking for
different contacts, if the instance-id is the same.

Can I ask you, why would you want to use Outbound in you want forking to
occur?

Of course, if you don't use Outbound, you may need anohter mechanism to
negotiate support of keep-alives: the sip-keep draft provides such
mechanism :)

But, since I know that you don't think that keep-alive indicators are
needed in the first place, I guess there much be another reason why you
want to use Outbound.

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 6 Oct 2008 10:44:37 +0300

> Can I ask you, why would you want to use Outbound in you want forking to

now that outbound text has been changed and it mandates UA to register
via two ob proxies if only two is given, it allows a very simple
implementation of redundancy, because the two proxies can operate
totally independent of each other.  

if UA has two different contacts and if outbound i-d does not mandate
the UA to register BOTH of them with BOTH ob proxies, then the above
(and only benefit) of outbound i-d goes away again, because we would
again be in the situation where redundancy is lost.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 6 Oct 2008 11:19:36 +0300

Christer Holmberg writes:

 > That still dooesn't answer my question: why do you want forking? Why
 > can't the registrar simply choose ONE working flow?

forking increases changes that the call actually gets through, because
one of the access networks may not be reachable at the moment.  also, if
both 3g and wlan is reachable, call comes through many seconds earlier
through wlan and is usually also free.  i understand that mobile
operators don't have incentive to fork the call if one of the legs is
free and the other costs money.

 > And, the UA can make normal (non-outbound) registrations via each of the
 > two ob proxies. They will still operate indepenent of each other - and
 > you will get forking.

"can" but is not forced to, which breaks the whole thing.

 > Even the UA has two contacts, and registers each once (using normal reg
 > procedures), you will still have redundancy: if one contact doesn't work
 > then the registrar will try anohter.

yes, but then you have only one registrar, which breaks redundancy at
server side.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Oct 2008 10:06:09 +0200

Hi, 

>>Can I ask you, why would you want to use Outbound in you want forking
to occur?
>now that outbound text has been changed and it mandates UA to register
via two ob proxies if only two is given, it allows >a very simple
implementation of redundancy, because the two proxies can operate
totally independent of each other.  

>if UA has two different contacts and if outbound i-d does not mandate
the UA to register BOTH of them with BOTH ob 
>proxies, then the above (and only benefit) of outbound i-d goes away
again, because we would again be in the situation 
>-where redundancy is lost.

Regards,

Christer

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Oct 2008 12:07:35 +0200

Hi, 

>forking increases changes that the call actually gets through, because
one of the access networks may not be reachable at >the moment.  also,
if both 3g and wlan is reachable, call comes through many seconds
earlier through wlan and is usually >also free.  i understand that
mobile operators don't have incentive to fork the call if one of the
legs is free and the 
>other costs money.

Yes, because earning money is simply wrong :)

>>And, the UA can make normal (non-outbound) registrations via each of
the two ob proxies. They will still operate 
>>indepenent of each other - and  > you will get forking.
>

Even if you allow (if it is even forbidden, that is) forking for
outbound it is still going to be a "can". No matter if you use outbound
or not, you would need to configure your registrar if to do forking,
whether  to do serial- or paralell forking, etc etc etc. 

>>Even the UA has two contacts, and registers each once (using normal
reg procedures), you will still have redundancy: if >>one contact
doesn't work then the registrar will try anohter.
server side.

So, you want to register both contacts to both registars, right?

Example:

UA_Contact_wlan ----- OB_1 ----- REG_1
UA_Contact_wlan ----- OB_1 ----- REG_2
UA_Contact_3g   ----- OB_2 ----- REG_1
UA_Contact_3g   ----- OB_2 ----- REG_2

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 6 Oct 2008 13:25:09 +0300

no, like this:

 > UA_Contact_wlan ----- OB_2 ----- REG_2
 > UA_Contact_3g   ----- OB_1 ----- REG_1

if outbound does not mandate that UA must register each contact with
both ob proxies, my pleasant surprise was a too early one and ob draft
falls back to the useless bin.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Oct 2008 12:36:37 +0200

Hi, 

 > UA_Contact_3g   ----- OB_2 ----- REG_2

Now, in your example, if OB_1 and REG_2 fail you don't still don't have
redundancy :)

>if outbound does not mandate that UA must register each contact with
both ob proxies, my pleasant surprise was a too
>early one and ob draft falls back to the useless bin.

I don't have the spec in front of me, but I don't think it currently
talks about multiple contacts.

I guess this all comes back to Dean's question whether we need some new
text into the draft.

In order to avoid delaying the Outbound spec even more, I guess it could
also be an extension draft:"Outbound with multiple contacts", or
something like that...

Regards,

Christer

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 6 Oct 2008 13:48:51 +0300

> Now, in your example, if OB_1 and REG_2 fail you don't still don't have

in the very common case that i have described earlier on this mailing
list, obx and regx are paired and run on the same host.  they are not
separate entities that can fail on their own.

 > also be an extension draft:"Outbound with multiple contacts", or

huh, once ob is out as rfc, it is way too late to do anything about it.
ob i-d must be got right the first shot.  another (better) alternative
is to publish the component rfcs that we have identified first and once
they are out, start working on ob i-d.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Mon, 6 Oct 2008 11:27:46 -0500

> text has been changed and with two proxies in the set, ua MUST  

That's why I kept saying we had fixed that part of outbound per your  
request.

> the user want to use both of them simultaneously, is it so that  

My understanding was that there is a contact prioritization. The proxy  
uses the first contact as long as the flow associated with that  
contact has keepalive. If that flow fails, then the proxy falls over  
to the second contact and flow.

> of its contacts with both proxies?

Only in 3GPP specs, I believe.

---

From: Dean Willis <[email-masked]>
Date: Mon, 6 Oct 2008 11:32:40 -0500

> falls back to the useless bin.

Assume a UA has two different interfaces, and it registers each of its  
interfaces with a different proxy/registrar. Further assume that those  
two proxy registrars collude with respect to mapping the user's AUR  
onto those contacts.

What's not redundant about this, and why is it useless?

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Oct 2008 18:36:19 +0200

Hi, 

>>and further, is there any text anywhere forcing the ua to register
both of its contacts with both proxies?
>Only in 3GPP specs, I believe.

3GPP does not say anything about registering contacts with multiple
registrars - with or without outbound.

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 6 Oct 2008 19:43:18 +0300

> two proxy registrars collude with respect to mapping the user's AUR  

that "collude" thing is exactly what i tried to avoid.  if ua is
required to register all of its contacts via both proxies, then
redundancy of the service can be implemented by running the
two proxy/registrars completely independent of each other thus greatly
simplifying the implementation.

if that requirement is not there, ob becomes totally useless again and
there was no advantage that the text was changed according to my
wishes.  you may as well go and change it back to what it was before.

 > What's not redundant about this, and why is it useless?

see above.  if we assume that ob set share common knowledge of the
registrations (e.g. via database), then registering via only some of the
ob proxies works fine.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Mon, 6 Oct 2008 12:38:59 -0500

> registrars - with or without outbound.

He said proxies, not registrars. Two different P-CSCFs, one for each  
radio. One S-CSCF.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 6 Oct 2008 12:41:06 -0500

Why do I get the feeling that you won't be happy even when every UA is  
forced to register every contact it has or might obtain have with  
every registrar that ever existed or will exist ;-)?

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 6 Oct 2008 20:48:55 +0300

> every registrar that ever existed or will exist ;-)?

dean,

that is not true.  i sincerely hoped that outbound would help me to
implement redundant proxy/registrar without a need to for load
balancers, database clusters, or forwarding of requests between
proxies simply by being able to assume that if i have two ob proxies,
each ua would register all contacts that it has via both of them.  

this is a VERY simple, easy to understand and implement requirement
compared to anything else this working group has ever produced.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Oct 2008 20:12:25 +0200

Hi, 

radio. One S-CSCF.

I guess he can speak for himself, but the use-case he has presented
actaully talks about two different S-CSCFs.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Oct 2008 16:37:31 -0400

I think I am missing something here. I presume that the knowledge of the 
UA is limited to:
- to proxy addresses
- an AOR to register

Presumably the address of the registrar is derived from the AOR to 
register by removing the user part. So the UA, when registering, doesn't 
specify two different registrars. Whether there are two or not is a 
function of how the proxy routes the register request. So whether the 
two registers for the same contact go to one registrar or two is unknown 
to the UA. In some configurations this would give you redundancy, and in 
others it would not.

Then, what causes the UA to register two different contacts? Are the 
wlan contact and the 3g contact registered to *different* AORs? If not I 
don't see the point. If anything, I would expect that 3g and wlan 
represent access networks and hence differing proxies, not AORs or 
registrars.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 7 Oct 2008 23:27:50 +0200

Hi, 

>I think I am missing something here. I presume that the knowledge of
>Presumably the address of the registrar is derived from the AOR to
register by removing the user part. So the UA, when 
>registering, doesn't specify two different registrars. Whether there
are two or not is a function of how the proxy routes 
>the register request. So whether the two registers for the same contact
go to one registrar or two is unknown to the UA. 
>In some configurations this would give you redundancy, and in others it
would not.
>Then, what causes the UA to register two different contacts? Are the
wlan contact and the 3g contact registered to 
>*different* AORs? If not I don't see the point. If anything, I would
expect that 3g and wlan represent access networks 
>and hence differing proxies, not AORs or registrars.

In the 3GPP case different contacts can be registered for the *SAME*
AOR. 

And, as you say, the edge proxies may be "access network dependent", so
it may not even be possible to e.g. register the wlan contact via the 3g
edge proxy, etc.

Regards,

Christer

	Thanks,
	Paul

Christer Holmberg wrote:
>  > UA_Contact_wlan ----- OB_1 ----- REG_1  > UA_Contact_wlan ----- 
> OB_1 ----- REG_2
>  > UA_Contact_wlan ----- OB_1 ----- REG_1  > UA_Contact_wlan ----- 
> OB_2 ----- REG_2
> Now, in your example, if OB_1 and REG_2 fail you don't still don't 
> have redundancy :)
> 
> I guess this all comes back to Dean's question whether we need some 
> new text into the draft.
> 
> In order to avoid delaying the Outbound spec even more, I guess it 
> could also be an extension draft:"Outbound with multiple contacts", or

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Oct 2008 17:41:29 -0400

> In the 3GPP case different contacts can be registered for the *SAME*

Not just in 3gpp. That should be true most anywhere. Typically they 
represent different UAs.

The question is: why would a *single* UA establish two distinct contacts 
and register them for the same AOR?

> it may not even be possible to e.g. register the wlan contact via the 3g

So you are saying that the contact addresses are themselves access 
network dependent??? So that the ip address of the contact is only 
accessible via a particular access network and proxy?

This *really* isn't the internet, is it!!!

	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 7 Oct 2008 23:53:07 +0200

> and register them for the same AOR?

I don't know if the following is used, but I've been thinking about it:

A PBX (a UA with AoR sip:[email-masked]) has two PSTN numbers asigned in its 
SIP provider/registrar:

1) +34111111
2) +34222222

Imagine it just creates a registration with:
  Contact: <sip:ua@UA_IP>

Then when the proxy receives a call for +34111111 or +34222222 it will 
transform the RURI into:
   INVITE sip:ua@UA_IP SIP/2.0

So how could the UA know which number was dialed? Note that reading the "To" 
header is not valid since the call could has been previously forwarded.

But now imagine that the UA uses two registrations, the first one with:
  Contact: <sip:+34111111@UP_IP>
and the second with:
  Contact: <sip:+34222222@UP_IP>

So if the proxy receives a call for +34111111 it could select the location of 
UA matching the username, and the UA would know which PSNT number was used.

Anyway I don't know how "llegal" is selecting an AoR location based on 
the "Contact" username.

-- 
Iñaki Baz Castillo

---

From: Dean Willis <[email-masked]>
Date: Tue, 7 Oct 2008 17:17:18 -0500

On Oct 7, 2008, at 3:37 PM, Paul Kyzivat wrote:

> register by removing the user part. So the UA, when registering,  
> doesn't specify two different registrars. Whether there are two or  
> not is a function of how the proxy routes the register request. So  
> whether the two registers for the same contact go to one registrar  
> or two is unknown to the UA. In some configurations this would give  
> you redundancy, and in others it would not.
>
> wlan contact and the 3g contact registered to *different* AORs? If  
> not I don't see the point. If anything, I would expect that 3g and  
> wlan represent access networks and hence differing proxies, not AORs  
> or registrars.
>

Some IMS networks have mechanisms for discovering the  edge proxy  
based on the air interface. This, a UA might discover one proxy for  
its 3g interface, and another for its WLAN interface. In other words,  
one proxy for each Contact.

So, that's "proxy" discovery.

Registrar discovery is a separate process. With config-framework, the  
UA is configured with a set of proxies with which it may register.  
Under outbound-015, if there are two or more outbound proxies in the  
configured set, the UA must register through at least two of those  
proxies. This assumes a singular contact at the UA.

Juha has, IIRC, proposed that the UA must register with at least two  
of those proxies for each contact. This, I believe, has some merit.  
I'm not sure it's a MUST, but it certainly seems a reasonable SHOULD.

Of course, when the configuration mechanism is different and only one  
proxy is provided per contact, we have a different case.

It seems like we are developing two conflicted use cases here -- one  
for a singular contact with redundant registration paths, and another  
for redundant contacts, each with singular registration path.

Then there may be yet another case, multiple contacts, each with  
redundant registration paths.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 7 Oct 2008 17:23:20 -0500

On Oct 7, 2008, at 4:41 PM, Paul Kyzivat wrote:
>
>
> The question is: why would a *single* UA establish two distinct  
> contacts and register them for the same AOR?
>

Because it has two different network interfaces, with two separate IP  
addresses, and it wants to use them both in case one of those contacts  
fails. Keepalive is then used so that the proxy-registrar can note a  
failed Contact.

This is the classic dual-homed node use case, and it affects  
everything from DNS entries to BGP route advertisement. It's a general  
thorn in the sides of people who think of networks as acyclical graphs  
or trees. Sometimes, leaf nodes have multiple stems for good reasons.

> This *really* isn't the internet, is it!!!

This isn't just a registration problem.

Imagine an enterprise that's connected to two ISPs. Each ISP provides  
an SBC for the enterprise.

Now you need two sets of telephone-routing tables to reach that  
enterprise.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Oct 2008 18:38:48 -0400

Iñaki,

What you describe is perfectly fine, and is in fact the reasonable thing 
to do. You have distinct AORs corresponding to the two numbers, and a 
separate contact for each.

What I was asking about was creating multiple Contact addresses for the 
*same* AOR.

Christer has provided me with an explanation. Specifically that 
different access networks have unique ip addresses. If so, then I guess 
I would want to register them with the same AOR. And in fact, if I had 
multiple AORs to register I might want to fabricate a pair of unique 
contact addresses, each unique to the AOR but carrying the the two 
different IP addresses.

Then the question arises whether I want the registrations using the two 
contacts treated as a single flow.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 8 Oct 2008 01:34:09 +0200

> What I was asking about was creating multiple Contact addresses for the

Perpahs I didn't explain correctly:

I mean that UA (with name "[email-masked]") sends two REGISTER for the same AoR:

1)
REGISTER sip:server
From: sip:[email-masked]
To: sip:[email-masked]
Contact: sip:+34111111@my_ip

1)
REGISTER sip:server
From: sip:[email-masked]
To: sip:[email-masked]
Contact: sip:+34222222@my_ip

When the proxy receives a call with RURI = +34111111, it ask the location 
sevice which returns "[email-masked]".
But the proxy, instead fo calling both locations in parallel (or 
sequentially), it just calls the location with the Contact username matching 
the incoming RURI (+34111111).

Not sure if it's a good idea.

Regards.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 8 Oct 2008 01:45:22 +0200

I am becoming concerned that we are now at this late stage going into
requirement inflation. This appears to be such.

I do not remember a requirement to provide redundant connections to
registrars as amongst the original requirements.

   1.  Must be able to detect that a UA supports these mechanisms.
   2.  Support UAs behind NATs.
   3.  Support TLS to a UA without a stable DNS name or IP address.
   4.  Detect failure of a connection and be able to correct for this.
   5.  Support many UAs simultaneously rebooting.
   6.  Support a NAT rebooting or resetting.
   7.  Minimize initial startup load on a proxy.
   8.  Support architectures with edge proxies.

Regards

Keith

> Behalf Of Dean Willis
> Sent: Tuesday, October 07, 2008 11:17 PM
> To: Paul Kyzivat
> Cc: [email-masked]; Christer Holmberg
> > doesn't specify two different registrars. Whether there are 
> two or not 
> > is a function of how the proxy routes the register request. 
> So whether 
> > the two registers for the same contact go to one registrar 
> or two is 
> > unknown to the UA. In some configurations this would give you 
> > redundancy, and in others it would not.
> >
> > wlan contact and the 3g contact registered to *different* 
> AORs? If not 
> > I don't see the point. If anything, I would expect that 3g and wlan 
> Some IMS networks have mechanisms for discovering the  edge 
> proxy based on the air interface. This, a UA might discover 
> one proxy for its 3g interface, and another for its WLAN 
> interface. In other words, one proxy for each Contact.
> 
> Registrar discovery is a separate process. With 
> config-framework, the UA is configured with a set of proxies 
> with which it may register.  
> Under outbound-015, if there are two or more outbound proxies 
> in the configured set, the UA must register through at least 
> two of those proxies. This assumes a singular contact at the UA.
> 
> Juha has, IIRC, proposed that the UA must register with at 
> least two of those proxies for each contact. This, I believe, 
> has some merit.  
> Of course, when the configuration mechanism is different and 
> only one proxy is provided per contact, we have a different case.
> 
> It seems like we are developing two conflicted use cases here 
> -- one for a singular contact with redundant registration 
> paths, and another for redundant contacts, each with singular 
> registration path.
> 
> Then there may be yet another case, multiple contacts, each 
> with redundant registration paths.
> 
> --
> Dean
> 
> [email-masked] for questions on current sip

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 7 Oct 2008 20:04:48 -0500

Right.

Outbound has a "redundancy" mechanism for the proxy embedded in the spec.

What is being asked is a redundancy mechanism for the UA (based on dual homing).

My reaction is that I don't see why a redundancy mechanism  for the UA should even
be tied to draft-ietf-sip-outbound. It seems to be attempting to use a small side effect
of outbound.

Rather, I think this should be a new draft, and it should be independent from outbound.
We already have a mechanism that allows for a q-value in a contact to indicate a desire for
different forking priorities.

I think another URI parameter for a Contact indicating that 2 different contacts are 
effectively the same (because of dual homing) would do the trick, and would not 
require outbound. Or maybe a parameter that says "alternative" to indicate that it's an
alternative to a specific contact (that has the advantage of telling the Registrar which
one is preferred which is apparently required).

Bottom line is I don't think Outbound is a good sledgehammer to use for this problem.

> Behalf Of DRAGE, Keith (Keith)
> Sent: Tuesday, October 07, 2008 16:45
> To: Dean Willis; Paul Kyzivat
> I am becoming concerned that we are now at this late stage 
> going into requirement inflation. This appears to be such.
> 
> I do not remember a requirement to provide redundant 
> connections to registrars as amongst the original requirements.
> 
> Behalf Of 
> > Dean Willis
> config-framework, the 
> least two 
> paths, and 
> > another for redundant contacts, each with singular 
> registration path.
> >

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Oct 2008 03:45:06 +0200

Hi, 

>>And, as you say, the edge proxies may be "access network dependent",
so it may not even be possible to e.g. register the 
>>wlan contact via the 3g edge proxy, etc.
>
network dependent??? So that the ip address of the 
>contact is only accessible via a particular access network and proxy?
>

I am not sure I understand. Typically each access network assigns IP
addresses to the UA independent from each other. The wlan network has a
no idea what IP address the 3g network assigns to the UA, and vice
versa.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Oct 2008 03:48:43 +0200

>Registrar discovery is a separate process. With config-framework, the
UA is configured with a set of proxies with which 
>it may register.  
configured set, the UA must register through at 
>least two of those proxies. This assumes a singular contact at the UA.
>
>Juha has, IIRC, proposed that the UA must register with at least two of
those proxies for each contact. This, I believe, 
>I'm not sure it's a MUST, but it certainly seems a reasonable SHOULD.

I don't agree. In my opinion the important thing is the number of
registartions for the instance-id. Whether different contacts are used
or not is irrelevant.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Oct 2008 04:55:31 +0200

Hi,

I am not sure I understand.

The location service does not return the AOR - it returns the contact associated with the AOR.

So, the RURI should contain the AOR ([email-masked]), for which the location service then returns the two registered contacts.

Regards,

Christer

> Behalf Of Iñaki Baz Castillo
> Sent: Wednesday, October 08, 2008 2:34 AM
> To: [email-masked]
> > What you describe is perfectly fine, and is in fact the reasonable 
> > thing to do. You have distinct AORs corresponding to the 
> two numbers, 
> > and a separate contact for each.
> >
> When the proxy receives a call with RURI = +34111111, it ask 
> the location sevice which returns "[email-masked]".
> But the proxy, instead fo calling both locations in parallel 
> (or sequentially), it just calls the location with the 
> Contact username matching the incoming RURI (+34111111).
>

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 8 Oct 2008 09:36:21 +0300

> registartions for the instance-id. Whether different contacts are used

i don't know what instance-id is and i don't even care to know at this
point.  

the only thing that matters to me as a user is that if UA is connected
to IP networks and thus has two contacts, it must register both of them
via both of its two outbound proxies (either in a single register
request listing both contacts or in two separate register requests
listing one each).

this guarantees that if the two outbound proxies are implemented as
independent proxy/registrar pairs, inbound call to the UA via either
proxy is able to fork the call to both contacts.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 8 Oct 2008 09:54:26 +0300

> independent from outbound.

so do you now finally agree to base outbound drfat on two new drafts
that are also independent of outbound: dialog connection re-use and
keepalive?

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 8 Oct 2008 09:56:54 +0300

> registrars as amongst the original requirements.

i have not asked for redundant connections to registrars.  the
connections are to outbound proxies.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 8 Oct 2008 10:02:39 +0300

> represent access networks and hence differing proxies, not AORs or 

my sip uri is sip:[email-masked] and the nokia phone on my desk is
currently registered to proxy of tutpro.com domain via both its wlan
interface and its 3g interface.  there is no need to have two different
proxies.

by the way, when my phone is on wlan and gprs network, the methods
supported by wlan contact and gprs contact are not the same (if that
matters anything to the instance-id business).

-- juha

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 08 Oct 2008 08:47:53 +0100

> Behalf Of Juha Heinanen
> Sent: 08 October 2008 07:36
> To: Christer Holmberg
> Cc: [email-masked]; Paul Kyzivat; Dean Willis
[JRE] I thought we were discussing sip-outbound. Instance-id is a
fundamental part of sip-outbound, so please read the draft. Christer is
correct - the important thing is whether the UA registers as one
instance-id or as two instance-ids (in the latter case, effectively
behaving as two UAs within the same device). This is a device decision,
and I don't believe we need normative statements in the draft to address
this. Some informative hints might be appropriate.

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Oct 2008 09:49:05 +0200

Hi, 

>>I don't agree. In my opinion the important thing is the number of
registartions for the instance-id. Whether 
>>different contacts are used  > or not is irrelevant.
> 
point. 

"instance-id:  This specification uses the word instance-id to refer
      to the value of the "sip.instance" media feature tag in the
      Contact header field.  This is a Uniform Resource Name (URN) that
      uniquely identifies this specific UA instance." 

While each registration flow gets an own reg-id, all registrations flows
from the UA shares the same instance-id.

>the only thing that matters to me as a user is that if UA is 
>connected to IP networks and thus has two contacts, it must 
>register both of them via both of its two outbound proxies 
>(either in a single register request listing both contacts or 
>in two separate register requests listing one each).
> 
>this guarantees that if the two outbound proxies are 
>implemented as independent proxy/registrar pairs, inbound 
>call to the UA via either proxy is able to fork the call to 
>both contacts.

They are still logically two separate functions, and I believe it has
been said that registrar redundancy is not within the scope.

Having said that, I don't think anything forbids you from doing what you
want. 

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.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Oct 2008 09:52:04 +0200

You talk about co-located outbound/registrar proxies, so you DO have
multiple registarars.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Oct 2008 09:57:08 +0200

>>Then, what causes the UA to register two different 
>>contacts? Are the wlan contact and the 3g contact 
>>registered to *different* AORs? If not I don't see the 
>>point. If anything, I would expect that 3g and wlan 
>>represent access networks and hence differing proxies, not 
>>AORs or registrars.
> 
>my sip uri is sip:[email-masked] and the nokia phone on my 
>desk is currently registered to proxy of tutpro.com domain 
>via both its wlan interface and its 3g interface.  there is 
>no need to have two different proxies.
> 
>by the way, when my phone is on wlan and gprs network, the 
>methods supported by wlan contact and gprs contact are not 
>the same (if that matters anything to the instance-id business).

If the phone performs SIP outboun registrations over the different
accesses, I assume the instance-id value is the same for both
registrations.

And, yes, in many cases you probably will be able to reach the same
outbound/edge proxy via all accesses.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Oct 2008 09:33:56 -0400

> Not sure if it's a good idea.

Its certainly not an idea that appeals to me.

It requires an entirely non-standard routing algorithm within the proxy, 
selecting contact URI from among the available candidates in a very 
weird way.

Its an axiom of sip that UAs may choose their contact addresses as they 
wish. The encoding of any semantic information into that address is the 
business of the UA and not for any other server to second guess.

In your example, the same proxy is responsible for the following AORs:
- tel:+34111111
- tel:+34222222
- sip:[email-masked]

and probably:

- sip:[email-masked]
- sip:[email-masked]

Rather than have the UA register for [email-masked] and have the proxy do 
a weird mapping based on registered contact addresses, its much more 
straightforward to have the UA register as follows:

REGISTER sip:domain.com
From: sip:[email-masked]
To: sip:[email-masked]
Contact: sip:+34111111@my_ip

REGISTER sip:domain.com
From: sip:[email-masked]
To: sip:[email-masked]
Contact: sip:+34222222@my_ip

(Its required to use the sip form of the AOR rather than the tel form. 
Can't have a tel as the To of a REGISTER.)

	Thanks,
	Paul

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 8 Oct 2008 16:34:26 +0300

>       uniquely identifies this specific UA instance." 

what does "specific UA instance" mean?

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 8 Oct 2008 16:36:51 +0300

> You talk about co-located outbound/registrar proxies, so you DO have

yes, but that is not relevant here.  someone else may have only one.
what matters are registrations via outbound proxies which may end up to
1 or 10 registrars.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Oct 2008 09:48:53 -0400

> cases where the contact is access network dependent it may not even be

I don't understand the last statement. You can put *any* syntactically 
valid URI in a Contact of a REGISTER.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Oct 2008 09:54:48 -0400

> interface and its 3g interface.  there is no need to have two different

That's a sensible arrangement. I suppose the wlan and 3g interfaces have 
different IP addresses, and so you have a separate contact for each? So 
you register two contacts to the same AOR via the same proxy, right?

> matters anything to the instance-id business).

In that case the choice of one instance id or two is a value judgment on 
your part. I would expect the default choice would be that they would 
have the same instance id. You might prefer distinct instance IDs if you 
want them considered independent devices. For instance, if one is 
IM-only and the other is voice-only then you might want them treated 
independently. But if they have overlapping capabilities, then you may 
have to then suffer having them both "ring" for the same call, which 
could be annoying. (But you might be able to program them to hide that.)

	Thanks,
	Paul

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 8 Oct 2008 17:00:57 +0300

Christer Holmberg writes:

 > >what matters are registrations via outbound proxies which may 
 > >end up to 1 or 10 registrars.
 > 
 > Well, then again I see no reason why the UA should have to register each
 > contact with all of the proxies.

some people may not care about simple implementation of redundancy.

 > Outbound says that the UE regiesters a number of flows. Whether all
 > those flows come from the same same contact is inrelevant. If one flow
 > fails, another fail is tried. It doesn't matter if that other flow
 > happens to be associated with another contact. So, you have redundancy.

could you please explain to me, how does that work for inbound calls to
the UA that need to get parallel forked to all contacts that the UA has
registered for its AoR?

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 8 Oct 2008 17:05:19 +0300

> you register two contacts to the same AOR via the same proxy, right?

exactly.  and if 3g connection is lost and replaced by 2g connection,
also the method list in the contacts will differ.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Oct 2008 16:18:11 +0200

Hi, 

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

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 8 Oct 2008 17:24:04 +0300

Christer Holmberg writes:

 > If you want to register multiple contacts, and you want the registrar to
 > fork to them, you use normal 3261 proceudres - and then you configure
 > the proxy to perform parallel forking.

this starts to go circles.  UA can do whatever it wants without any rfc.
proxy operator, however, has no way to know that UA does the right thing
if it is not mandated by an rfc and rfc3261 does not mandate registering
via multiple proxies.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 8 Oct 2008 17:31:35 +0300

> the user can be reached on any of the flows.

this is all true, but then it makes no sense for ob draft to mandate
registering via at least two ob proxies.  the ua can register with one
and if that flow dies, register with another one.  your requirement is
satisfied and there is no need for ob draft to mandate two flows.

i'm sorry that i brought the "minimum two" issue up.  the current text
does not help me to achieve my goal and it can very well be removed.  as
side effect, it makes no sense to implement outbound, because it does
not add any value.  UAs are already using keepalives without outbound.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Oct 2008 15:42:15 +0200

>>>i have not asked for redundant connections to registrars. 
multiple registarars.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Oct 2008 16:40:20 +0200

Hi, 

>>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.
> 
>this is all true, but then it makes no sense for ob draft to 
>mandate registering via at least two ob proxies.  the ua can 
>register with one and if that flow dies, register with 
>another one.  your requirement is satisfied and there is no 
>need for ob draft to mandate two flows.

I have never said that a user should only register with one ob proxy.

As specified, one should register with at least two ob proxies, but my
point is that it doesn't matter if those two registrations are bound to
the same contact, as long as the user can be reached on both of the
registrations.

Regards,

Christer

> 
> i'm sorry that i brought the "minimum two" issue up.  the 
> current text does not help me to achieve my goal and it can 
> very well be removed.  as side effect, it makes no sense to 
> implement outbound, because it does not add any value.  UAs 
> are already using keepalives without outbound.
> 
> -- juha
>

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 8 Oct 2008 17:50:31 +0300

> the same contact, as long as the user can be reached on both of the

it DOES matter if you consider complexity of implementing redundant
proxy/registrar.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Oct 2008 16:11:14 +0200

Hi, 
 
>>Outbound says that the UE regiesters a number of flows. 
>>Whether all those flows come from the same same contact is 
>>inrelevant. If one flow  fails, another fail is tried. It 
>>doesn't matter if that other flow happens to be associated 
>>with another contact. So, you have redundancy.
> 
>could you please explain to me, how does that work for 
>inbound calls to the UA that need to get parallel forked to 
>all contacts that the UA has registered for its AoR?

Again, that has nothing to do with Outbound. Outbound tries to ensure
that there is at least ONE flow on which you can be reached.

OR, you use normal 3261 procedures combined with Outbound, but then you
would register each contact using independent outbound procedures for
each contact. You could register each contact via each outbound proxy,
but from a outbound perspective the contacts would not be related.

Regards,

Christer

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 8 Oct 2008 11:47:30 -0500

No.

I'm saying a new draft on redundant registration is needed, and we can leave
outbound AS IS.

I thought about this more.

I think what it means, is NOT using "Supported: outbound", but using 
the +sip.instance and reg-id in the REGISTER. Perhaps with a different
"Support: redundant-registrations" or whatever.

The reg-ids will distinguish the multiple registrations. The +sip.instance
will correlate them.

This will be in line with what we did with GRUU which also can use the
+sip.instance.

A new draft describing this should be fairly simple to do, and we wouldn't
derail the process, and it would be very much in line with sip-outbound.

Makes sense?

> From: Juha Heinanen [mailto:[email-masked]] 
> Sent: Tuesday, October 07, 2008 23:54
> To: Audet, Francois (SC100:3055)
> Cc: DRAGE, Keith (Keith); Dean Willis; Paul Kyzivat; 
> [email-masked]; Christer Holmberg
>  > Rather, I think this should be a new draft, and it should 
> be  > independent from outbound.
> 
> so do you now finally agree to base outbound drfat on two new 
> drafts that are also independent of outbound: dialog 
> connection re-use and keepalive?
> 
> -- juha
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 8 Oct 2008 22:31:16 +0200

> selecting contact URI from among the available candidates in a very

Yes, true.

> business of the UA and not for any other server to second guess.

True again.

> a weird mapping based on registered contact addresses, 

Why "weird"? it could be done based on a private ENUM that maps PSTN numbers 
to SIP users without the need of having PSTN numbers as userinfo in the local 
SIP users.

I could allow a user sip:[email-masked] registering for the AoR sip:
[email-masked], but then I need to control in the registrar if the 
user "[email-masked]" has permissions to register that AoR. IMHO it's easier if 
the mapping PSTN<->SIP is done by the proxy instead of depending on the 
users, isn't?

> its much more

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 10 Oct 2008 14:10:22 -0500

Juha,

I think outbound will help us to implement redundant proxy/registrar
without the need for load balancers/clusters/etc.

But it's not currently in the spec. I view it as something of high
priority that we should be looking at. But we'll never get there if we 
don't get outbound out the door first.

> Sent: Monday, October 06, 2008 10:49
> To: Dean Willis
>  > Why do I get the feeling that you won't be happy even when 
> every UA is  > forced to register every contact it has or 
> might obtain have with  > every registrar that ever existed 
> or will exist ;-)?
> 
> dean,
> 
> that is not true.  i sincerely hoped that outbound would help 
> me to implement redundant proxy/registrar without a need to 
> for load balancers, database clusters, or forwarding of 
> requests between proxies simply by being able to assume that 
> if i have two ob proxies, each ua would register all contacts 
> that it has via both of them.  
> 
> this is a VERY simple, easy to understand and implement 
> requirement compared to anything else this working group has 
> ever produced.
> 
> -- juha
> 
> 
> 
>  >
>  > >> Assume a UA has two different interfaces, and it 
> registers each of  > >> its  > >> interfaces with a different 
> proxy/registrar. Further assume that  > >> those  > >> two 
> proxy registrars collude with respect to mapping the user's 
> AUR  > >> onto those contacts.
>  > >
>  > > that "collude" thing is exactly what i tried to avoid.  
> if ua is  > > required to register all of its contacts via 
> both proxies, then  > > redundancy of the service can be 
> implemented by running the  > > two proxy/registrars 
> completely independent of each other thus greatly  > > 
>  > > if that requirement is not there, ob becomes totally 
> useless again and  > > there was no advantage that the text 
> was changed according to my  > > wishes.  you may as well go 
> and change it back to what it was before.
>  >

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 10 Oct 2008 22:39:25 +0300

> don't get outbound out the door first.

it takes years for UA vendors to implement outbound draft and more than
10 years the followup version.  by then, sip may be already replaced by
something else.  so if you want outbound to have any value, it needs to
be get right the first shot.

also, it was not clear to me (and looks like also some experts), what
instance-id means and what effect it has to forking to multiple
contacts.  if everything in outbound is not crystal clear, it makes no
sense to publish it.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 10 Oct 2008 15:35:56 -0500

Nobody is talking about a "second version" of outbound.

Somebody just need to write a draft on high-availability. 

> Sent: Friday, October 10, 2008 12:39
> Cc: Dean Willis; [email-masked]; Christer Holmberg
> Subject: RE: [Sip] Dual registration without Outbound
> 
> Francois Audet writes:
> 
>  > But it's not currently in the spec. I view it as something 
> of high  > priority that we should be looking at. But we'll 
> never get there if we  > don't get outbound out the door first.
> 
> it takes years for UA vendors to implement outbound draft and 
> more than 10 years the followup version.  by then, sip may be 
> already replaced by something else.  so if you want outbound 
> to have any value, it needs to be get right the first shot.
> 
> also, it was not clear to me (and looks like also some 
> experts), what instance-id means and what effect it has to 
> forking to multiple contacts.  if everything in outbound is 
> not crystal clear, it makes no sense to publish it.
> 
> -- juha
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 11 Oct 2008 06:09:11 +0200

Juha,

At one point you requested that a USER should establish at least two
register flows, and that was accepted.

That has NOT changed.

The only new thing is that the USER may use different contacts for
different flows. BUT, it is still the same USER, and that USER should
still register at least two register flows - either all flows from the
same contact, or from different contacts.

As far as I know, you have never before requested that the registrar,
for incoming requests, shall perform paralell forking on all registered
flows.

Regards,

Christer

> Sent: Wednesday, October 08, 2008 5:51 PM
> To: Christer Holmberg
> Cc: Paul Kyzivat; Dean Willis; [email-masked]
>  > As specified, one should register with at least two ob 
> proxies, but my  > point is that it doesn't matter if those 
> two registrations are bound to  > the same contact, as long 
> as the user can be reached on both of the  > registrations.
> 
> it DOES matter if you consider complexity of implementing 
> redundant proxy/registrar.
> 
> -- juha
>

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 11 Oct 2008 09:35:46 +0300

> Nobody is talking about a "second version" of outbound.

it would be "second" version, because it would need to add to UA's
outbound behavior compared to ob rfc.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 11 Oct 2008 09:53:58 +0300

> for incoming requests, shall perform paralell forking on all registered

it is not SHALL, but it MUST BE POSSIBLE to do if the user wants that to
happen.

in my example the same UA instance registers AoR sip:[email-masked] over
its gprs and 3g interfaces with different contact addresses (one from
ggsn and the other one from lan).

first, like today without outbound, it must be possible with outbound
that incoming call to sip:[email-masked] gets parallel forked to the two
contacts of this UA instance.  now i tried to figure out what ob draft
says about it and found this:

7. Authoritative Proxy Procedures: Forwarding Requests

   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.

to me this clearly means that parallel forking is not anymore possible
when UA implements outbound, which would be a VERY SEVERE restriction
and change of RFC3261 behavior.

second, if the UA instance may choose to register one of its two
contacts via ob proxy 1 and the other via ob proxy 2, it makes
simple implementation of redundancy with two proxy/registrar pairs
impossible.

these two issues currently make outbound useless to me (and i have not
read even half of the current version, so there may be many more in the
closet).

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Sun, 12 Oct 2008 00:09:53 +0300

Dean Willis writes:

 > Seems like what you are asking for is for a proxy to require parallel
 > forking to multiple contacts regsitered by a single UA. 

huh, i'm not asking anything beyond what is in rfc3261 and what is
currently working fine in practise.  or can you point to text in rfc3261
that prohibits a single UA registering several contacts for a single
AoR and that prohibits a proxy parallel forking to those contacts when
the contacts share the same q value?

 > That is not
 > only out of scope for outbound, it is also undesirable behaivior (as
 > in totally broken) for a great number of use cases. 

i didn't know that normal rfc3261 compliant behavior is outside of scope
of outbound.  was it listed in outbound requirements that outbound
should obsolete forking that has been there from the very beginning and
that many applications rely on?  could you quote the requirements text
on that?

also, what wrong or undesirable there is in the forking example that i
have described in earlier messages?
 
 > Consequently, this
 > means it would require a great deal of documentation around the use
 > cases for which it makes sense. I do not think this can be done
 > reasonably in the outbound draft.

outbound should not change current rfc3261 compliant forking behavior.
it has to support it and if more text is needed, then it is outbound
editors' problem.  forking is much more important than outbound
especially when many UAs have already implemented things like keepalives
without outbound.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Sun, 12 Oct 2008 15:56:53 +0300

Dean Willis writes:

 > There is a big difference between not preventing behavior and
 > requiring behavior.

looks like you try on purpose to misunderstand what i have required.  i
have never said that proxy is REQUIRED to fork.  it just must be
POSSIBLE for the proxy to fork even when outbound is in use.

so if i upgrade my current phone that registers both of its contacts to
outbound capability, it must still be possible for this phone to
register both contacts and proxy to fork incoming calls to both of them.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 12 Oct 2008 20:04:20 +0200

Hi Juha,

>>There is a big difference between not preventing behavior and requiring behavior.
>

I think you once did say that forking shall be required, because otherwise the UA can't be sure that the proxy actually will fork. But, maybe I missunderstood.

So, eventhough my personal opinion is that parallel forking shouldn't occur for Outbound, I don't think it is prohibited. The outbound spec doesn't say much about how specific flows are chosen.

Regards,

Christer

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Sun, 12 Oct 2008 21:09:54 +0300

Christer Holmberg writes:

  > So, eventhough my personal opinion is that parallel forking
  > shouldn't occur for Outbound, I don't think it is prohibited. The
  > outbound spec doesn't say much about how specific flows are chosen.

did you read the paragraph that i quoted?  to me it clearly makes
forking impossible when outbound is used.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 12 Oct 2008 20:11:48 +0200

Hi,

>when UA implements outbound,

Ok, I admit I forgot about that text.

>which would be a VERY SEVERE restriction and change of RFC3261 behavior.
>

So, does the outbound spec forbid registering each contact via two proxies? Or, do you want to mandate THAT?

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Sun, 12 Oct 2008 21:33:01 +0300

Christer Holmberg writes:

 > So, does the outbound spec forbid registering each contact via two
 > proxies? Or, do you want to mandate THAT?

i have told this already at least three times:

if it is not mandated that UA has to register all its contacts via at
least two ob proxies (if set has two or more), then simple
implementation of redundancy becomes impossible.  

also, reliability will necessarily suffer also in complex implementation
when one of the contacts would not be available via more than one proxy.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 12 Oct 2008 20:41:19 +0200

Hi,

>implementation of redundancy becomes impossible.  

The problem is that there are also cases where the ob proxies and registrars ARE separated, and what you propose may not be needed in such scenarios.

Why don't you simply configure your UA to register each contact with multiple ob/registrar proxies?

>when one of the contacts would not be available via more than one proxy.

If both contacts are "equal" I don't think that will be a problem. There will be two ways to reach the UA, as if a single contact was used.

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Sun, 12 Oct 2008 22:11:17 +0300

Christer Holmberg writes:

 > The problem is that there are also cases where the ob proxies and
 > registrars ARE separated, and what you propose may not be needed in
 > such scenarios.

i know that and i hoped that outbound would make a simple, redundant
implementation possible.  it was very close, when it was accepted that
at least two ob proxies must be used.  now this multiple contact thing
killed it.

 > multiple ob/registrar proxies?

the problem is that many UAs don't support that kind of configuration,
because there has been no rfc that would mandate them to do so.  i was
hoping that ob would do it.

 > If both contacts are "equal" I don't think that will be a
 > problem. There will be two ways to reach the UA, as if a single
 > contact was used.

they are NOT equal and you cannot assume it.  for example, gprs
connectivity might be much more reliable than wlan connectivity or vice
versa.  

but this is all theory anyhow, because ob draft is badly broken, because
it does not support forking at all and thus is in grave conflict
with rfc3261.

-- juha

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 13 Oct 2008 09:19:50 +0100

> Sent: 11 October 2008 22:10
> To: Dean Willis
> Cc: [email-masked]; Paul Kyzivat; Christer Holmberg
[JRE] Yes, indeed, retention of forking is very important. With RFC
3261, multiple UAs can register and incoming requests will be forked to
them. With sip-outbound, this is still the case, provided these multiple
UAs choose different instance IDs. This still holds true if two UAs are
implemented in the same device, e.g., in your example, a dual mode
device would have a GPRS UA with one instance ID and a WLAN UA with a
second instance ID. If each registers, calls will be forked to both. To
be sip-outbound compliant, of course, each has to register at least
twice, so you will have at least two registrations (flows) with one
instance ID, and at least two registrations (flows) with the second
instance ID. An incoming request would be forked, such that it arrives
at the device twice (and only twice), once following one of the flows
for the first instance ID (GPRS) and once following one of the flows for
the second instance ID (WLAN).

Perhaps we need some informative text to describe this particular use
case.

John

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 13 Oct 2008 13:08:04 +0300

Dean Willis writes:

 > Um, perhaps I missed something. What is that prevents a UA from
 > registering two different interfaces with discrete instance IDs and
 > having a forking proxy fork to both instances?

i don't think nothing prevents that, but in my example, there is only
one sip ua and one instance of it.  both contacts of this instance belong
to the same ua:

   Proxies can
   determine which flows go to the same UA by comparing the instance-id.

if my phone would have two instance-ids, according to the above, i would
have too UAs, which is not the case today and i don't want that to be
the case when/if i one day upgrade its software to support outbound rfc.

it is amazing how hard it is to you to admit that outbound i-d as
currently written is badly broken.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 13 Oct 2008 13:12:10 +0300

Elwell, John writes:

 > second instance ID. 

see my previous email.  i don't want two UAs, but like today, only one
that has two contacts.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 13 Oct 2008 11:12:29 -0500

It would be a "high-availability" draft.

If we are lucky, maybe there is no impact on the UA (but I doubt it). 

> Sent: Friday, October 10, 2008 23:36
> it would be "second" version, because it would need to add to 
> UA's outbound behavior compared to ob rfc.
> 
> -- juha
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 13 Oct 2008 21:18:36 +0200

Hi,

I don't think the spec is broken. I think the spec was written based on
the assumption that a UA instance is not interested in receiving an
INVITE multiple times in parallel (the UA will return 484 for all but
one INVITE) - which I don't think is desired even in normal forking
scenarios - but that it should be possible to, if one flow is down,
choose another flow to reach the UA (read: serial forking).

And, IF you would use two instance-ids (as proposed by Dean), why does
the forking proxy need to know whether they belong to the same UA or
not? Why doesn't it simply do paralell forking?

Regards,

Christer

> Sent: Monday, October 13, 2008 1:08 PM
> To: Dean Willis
> Cc: Christer Holmberg; Paul Kyzivat; [email-masked]
>  > Um, perhaps I missed something. What is that prevents a UA 
> from  > registering two different interfaces with discrete 
> instance IDs and  > having a forking proxy fork to both instances?
> 
> i don't think nothing prevents that, but in my example, there 
> is only one sip ua and one instance of it.  both contacts of 
> this instance belong to the same ua:
> 
>    Proxies can
> instance-id.
> if my phone would have two instance-ids, according to the 
> above, i would have too UAs, which is not the case today and 
> i don't want that to be the case when/if i one day upgrade 
> its software to support outbound rfc.
> 
> it is amazing how hard it is to you to admit that outbound 
> i-d as currently written is badly broken.
> 
> -- juha
>

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 13 Oct 2008 22:27:03 +0300

Christer Holmberg writes:

 > scenarios - 

the assumption and your conclusion is plain wrong.  in the example i
gave, it is very useful and desired that if wlan connectivity works,
phone gets the invite about 10 seconds faster than over gprs and the
call id free.  when second invite comes, my phone rejects it (i don't
remember the code, but that doesn't really matter to me).

 > but that it should be possible to, if one flow is down,

cannot do that it the other flow is not reachable through the proxy and
the other proxy to which the contact was registered is down.  this is
because the contact was not registered with both due to the brain damage
of ob draft and its instance-id business.

 > not? Why doesn't it simply do paralell forking?

the proxy does not, but i don't want to complicate configuration of the
UA simply in order to cope with the brain damage of ob draft.  also,
don't want that the UA has to send two invites for one contact each.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 13 Oct 2008 22:38:46 +0300

> don't want that the UA has to send two invites for one contact each.

typo: i don't want that the UA has to send two REGISTERs for one contact
each.  that is, UA must be able to register both of its contacts in a
single register request.

this is my last message about this topic (i need to save cycles to code
writing).  i have already learned many times that this working group
does not care about real world requirements or even rfc3261
compatibility unless something in 3gpp gets broken.

-- juha

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 13 Oct 2008 21:39:23 +0200

Hi, 

>>I don't think the spec is broken. I think the spec was 
>>written based on the assumption that a UA instance is not 
>>interested in receiving an INVITE multiple times in 
>>parallel (the UA will return 484 for all but one INVITE) - 
>>which I don't think is desired even in normal forking scenarios - 
> 
>the assumption and your conclusion is plain wrong.  in the 
>example i gave, it is very useful and desired that if wlan 
>connectivity works, phone gets the invite about 10 seconds 
>faster than over gprs and the call id free.  when second 
>invite comes, my phone rejects it (i don't remember the code, 
>but that doesn't really matter to me).

484.

>cannot do that it the other flow is not reachable through the 
>proxy and the other proxy to which the contact was registered 
>is down.  this is because the contact was not registered with 
>both due to the brain damage of ob draft and its instance-id business.

If specs had brains they would write themselves for us... :)
 
>>And, IF you would use two instance-ids (as proposed by 
>>Dean), why does the forking proxy need to know whether 
>>they belong to the same UA or not? Why doesn't it simply 
>>do paralell forking?
> 
>the proxy does not, but i don't want to complicate 
>configuration of the UA simply in order to cope with the 
>brain damage of ob draft.  also, don't want that the UA has 
>to send two invites for one contact each.

Why would the UA have to send two INVITEs just because it uses different
instance-ids?

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 13 Oct 2008 21:44:52 +0200

Hi,

>>brain damage of ob draft.  also, don't want that the UA 
>>has to send two invites for one contact each.
> 
>typo: i don't want that the UA has to send two REGISTERs for 
>one contact each.  that is, UA must be able to register both 
>of its contacts in a single register request.

You will still have to send a REGISTER for each flow that you establish
- no matter whether you use the same contact/instance-id or not.

Or, do you also want to change outbound so that you can establish
multiple flows with a single REGISTER?

Regards,

Christer

---

From: Bob Penfield <[email-masked]>
Date: Tue, 14 Oct 2008 10:40:45 -0400

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):

   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".

cheers,
(-:bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Monday, October 13, 2008 3:45 PM
To: Juha Heinanen; [email-masked]; Paul Kyzivat; Dean Willis
Subject: Re: [Sip] Dual registration without Outbound

Hi,

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 14 Oct 2008 16:02:23 +0100

> Behalf Of Bob Penfield
> Sent: 14 October 2008 15:41
> To: Christer Holmberg; Juha Heinanen; [email-masked]; Paul 
> Kyzivat; Dean Willis
> 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.
> 
> 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.
> 
[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

---

From: Bob Penfield <[email-masked]>
Date: Tue, 14 Oct 2008 13:37:57 -0400

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:[email-masked]>;tag=7F94778B653B-1
   To: Bob <sip:[email-masked]>
   Call-ID: 16CB75F21C70-1
   CSeq: 1 REGISTER
   Supported: path, outbound
   Route: <sip:ep1.example.com;lr>
   Contact: <sip:[email-masked];transport=tcp>;reg-id=1
    ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
   Contact: <sip:[email-masked];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:[email-masked]>;tag=7F94778B653B-2
   To: Bob <sip:[email-masked]>
   Call-ID: 16CB75F21C70-2
   CSeq: 1 REGISTER
   Supported: path, outbound
   Route: <sip:ep2.example.com;lr>
   Contact: <sip:[email-masked];transport=tcp>;reg-id=1
    ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-BBCCDDEEFF00>"
   Contact: <sip:[email-masked];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?

cheers,
(-:bob

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

John

---

From: "Karthikeyan Gopal " <[email-masked]>
Date: Wed, 15 Oct 2008 11:01:01 +0530

Why two UA instance? What is the use case?
If UA want's to register with 2 flow say 2 proxies we can have same 
Instance-id and vary the reg-id value.
Regards,
Karthikeyan.G

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bob Penfield
Sent: Tuesday, October 14, 2008 11:08 PM
To: Elwell, John; Christer Holmberg; Juha Heinanen; [email-masked]; Paul
Kyzivat; Dean Willis
Subject: Re: [Sip] Dual registration without Outbound

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:

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?

cheers,
(-:bob

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: Tuesday, October 14, 2008 11:02 AM
To: Bob Penfield; Christer Holmberg; Juha Heinanen; [email-masked]; Paul
Kyzivat; Dean Willis

John

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.

-----------------------------------------------------------------------------------------------------------------------

---

From: Dean Willis <[email-masked]>
Date: Wed, 15 Oct 2008 00:35:49 -0500

> and change of RFC3261 behavior.

This seems to me to mean that if you have two interfaces on a given UA
and want them treated as separate instances (so that the requests can be
forked) that you do so by using different instance IDs for each interface.

---

From: Dean Willis <[email-masked]>
Date: Wed, 15 Oct 2008 00:41:12 -0500

> see my previous email.  i don't want two UAs, but like today, only one

What requires there to be two "real" UAs to have two instance-id values?
A single UA with two interfaces and one instance-id per interface seems
reasonable to me.

It's also reasonable that that UA might have two different interfaces
that share an instance-id. It's really a choice between different
deployment scenarios.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 15 Oct 2008 00:44:08 -0500

> choose another flow to reach the UA (read: serial forking).

IIRC, it was a deliberate choice (a feature of the spec) that it prevent
 redundant message delivery, as that would most likely screw up a UA.

The whole point of the instance-id is so that the proxy can know that
two contacts refer to the same UA, and therefore NOT fork request to
both contacts.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 15 Oct 2008 09:51:51 +0200

Hi, 

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.

I think the use-cases we are talking about still only has a single UA
(if you refer to actual application software).

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 15 Oct 2008 09:58:22 +0200

Hi, 

The issue is that Juha wants incoming INVITEs to be paralelly forked to
both contacts. Outbound does not do paralell forking - it tries one
flow, and if that doesn't work it tries another one.

Regards,

Christer

-----Original Message-----

cheers,
(-:bob

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: Tuesday, October 14, 2008 11:02 AM
To: Bob Penfield; Christer Holmberg; Juha Heinanen; [email-masked]; Paul
Kyzivat; Dean Willis

> To: Christer Holmberg; Juha Heinanen; [email-masked]; Paul Kyzivat; Dean

> Willis
> (+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

> In both cases, the proxy does serial forking to Contacts with the same

> For Outbound, it attempts the registered flows (according to section 7

> of Outbound):
> 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.
>

John

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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 15 Oct 2008 10:03:44 +0200

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).
two outbound flows.
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? 

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

Regards,

Christer

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: Tuesday, October 14, 2008 11:02 AM
To: Bob Penfield; Christer Holmberg; Juha Heinanen; [email-masked]; Paul
Kyzivat; Dean Willis

John

DISCLAIMER:

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 15 Oct 2008 09:28:11 +0100

Christer,

It might well be the same software stack from the IP layer or the
transport layer upwards, but logically it acts as two UAs (with some
application software at the top to bind the two together). At least from
the proxy perspective it looks like two UAs. Viewing it your way is
perhaps also valid (but requires a minor change to sip-outbound).

John

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: 15 October 2008 08:52
> To: Elwell, John; Bob Penfield; Juha Heinanen; [email-masked]; 
> Paul Kyzivat; Dean Willis

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 15 Oct 2008 10:31:30 +0200

Hi, 

transport layer upwards, but logically it acts as two UAs (with some
application software at the top to bind the two together). 
>At least from the proxy perspective it looks like two UAs. Viewing it
your way is perhaps also valid (but requires a minor change to
sip-outbound).

And, if I understood correctly, that is the change Juha has been asking
for :)

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 15 Oct 2008 09:51:54 +0100

> Sent: 15 October 2008 09:32
[JRE] Exactly. But viewing it my way possibly requires less change to
sip-outbound, since much of it talks about one instance ID per UA (e.g.,
section 3.1).

Whichever way we view it, the following statement in 4.1 seems to be
problematic:
"Instance ID MUST NOT change as the device moves from one network to
   another."

John

---

From: Bob Penfield <[email-masked]>
Date: Wed, 15 Oct 2008 11:07:56 -0400

>Sent: Wednesday, October 15, 2008 4:04 AM
>To: Karthikeyan Gopal ; Bob Penfield; Elwell, John; Juha Heinanen; [email-masked]; Paul Kyzivat; Dean Willis

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.

>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.

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: Tuesday, October 14, 2008 11:02 AM
To: Bob Penfield; Christer Holmberg; Juha Heinanen; [email-masked]; Paul
Kyzivat; Dean Willis

John

DISCLAIMER:

---

From: Bob Penfield <[email-masked]>
Date: Wed, 15 Oct 2008 11:11:47 -0400

>Sent: Wednesday, October 15, 2008 4:52 AM
>To: Christer Holmberg; Bob Penfield; Juha Heinanen; [email-masked]; Paul Kyzivat; Dean Willis

If the UA uses the interface's MAC address to generate the instance-id, it would not change when you move between networks.

---

From: Dean Willis <[email-masked]>
Date: Wed, 15 Oct 2008 17:29:30 -0500

> "Instance ID MUST NOT change as the device moves from one network to

If the instance ID is derived from the MAC address, then clearly the  
instance will change depending on the type of network being used.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Oct 2008 18:52:42 -0400

>> "Instance ID MUST NOT change as the device moves from one network to

I've always viewed this as one worthwhile objective, but that there may 
be conflicting objectives that lead to multiple instance ids.

For instance, if I sell my device to Dean, he may not want it to have 
the same instance id it had when it was mine.

Or I may want to change ids so that it appears to others that I have two 
devices rather than one. (Maybe someone will try to correlate my 
location to the device I am using, and I want to throw them off.)

And with soft devices it is very subjective when what I have is one 
logical device or several.

I think all we can do is hope that the same instance id is used when the 
user is willing for some continuity of device identity to be perceived.

Trying to register the "same UA" concurrently with two different 
instance ids in an attempt to get parallel forked call attempts via 
different networks is creative but a bit ugly. For one thing its hard in 
general to guarantee that the two will be parallel forked. And the UA 
will have to attempt to correlate the two in order to realize they are 
the same and so process correctly. An SBC between the forking proxy and 
the UA is likely to disturb the CallID, the From, and the caller's 
Contact address. With those messed up the correlation will get difficult.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 16 Oct 2008 08:02:40 +0200

Hi, 

instance ids in an attempt to get parallel forked call attempts via
different networks is creative but a bit ugly. For one thing 
>its hard in general to guarantee that the two will be parallel forked.
And the UA will have to attempt to correlate the two in order to realize
they are the same and so process correctly. An 
>SBC between the forking proxy and the UA is likely to disturb the
CallID, the From, and the caller's Contact address. With those messed up
the correlation will get difficult.

IF there is a need to do parallell forking to the "same UA", I think
it's better to simply allow it in Outbound - instead of trying to find
hacks on how to get around the current restrictions.

However, parallell forking in outbound should not be the default
behavior, because I strongly think that in most cases people only want
to receive the initial request on a SINGLE flow - no matter if they use
one or more contacts.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 16 Oct 2008 09:14:57 +0100

> From: Bob Penfield [mailto:[email-masked]] 
> Sent: 15 October 2008 16:12
> To: Elwell, John; Christer Holmberg; Juha Heinanen; 
> [email-masked]; Paul Kyzivat; Dean Willis
> If the UA uses the interface's MAC address to generate the 
> instance-id, it would not change when you move between networks.
[JRE] I think Dean already answered this. If the instance ID is derived
from the MAC address, then when moving between networks employing a
different MAC technology, by definition the instance ID will change.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Oct 2008 09:30:25 -0400

> to receive the initial request on a SINGLE flow - no matter if they use

Making this behavior "possible but not default" means that there must be 
two options: "do it", and "don't do it". The choice of which to do would 
need to be encoded somewhere. This matters a lot to the UA, so I think 
this option would have to be encoded as part of the registration 
request. Thus outbound would have to change to accommodate it.

In any case, changing the mechanism for requesting this behavior 
wouldn't really change the issues I raised about detecting when the same 
call is delivered via both paths.

	Thanks,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 16 Oct 2008 18:15:42 -0500

Did we reach a conclusion on this thread?

I think it has always been clear that forking is possible, and you do it by
using different +sip.instance.

I don't see any reason to change the spec.

---

From: Dean Willis <[email-masked]>
Date: Thu, 16 Oct 2008 18:50:26 -0500

On Oct 16, 2008, at 8:30 AM, Paul Kyzivat wrote:
>
> Making this behavior "possible but not default" means that there  
> must be two options: "do it", and "don't do it". The choice of which  
> to do would need to be encoded somewhere. This matters a lot to the  
> UA, so I think this option would have to be encoded as part of the  
> registration request. Thus outbound would have to change to  
> accommodate it.

If you want outbound's redundant-flow functionality, which is  
dependent on requests NOT forking to each flow to a UA, use outbound  
as specified.

If instead you want your two contacts treated as two different  
instances so that requests will fork to them, use two different  
instance-id values. Essentially, you're using single-contact/single  
flow Outbound (i.e., keepalive and reverse-routing of requests without  
redundant-flow) simultaneously on two different contacts (which may  
well be two different interfaces).

If you want both outbound's features simultaneously on multiple  
instances (or use virtual interfaces by having multiple instances on  
the same interface), then apply outbound as specified on each  
instance, where there are at least two proxies configured for each  
instance.

About the only thing I can see needing to document somewhere is the  
concept of using multiple instance-ids to make virtual interfaces, and  
that's pretty simple.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Oct 2008 20:08:15 -0400

I agree.

	Paul

Dean Willis wrote:
>> Making this behavior "possible but not default" means that there must 
>> be two options: "do it", and "don't do it". The choice of which to do 
>> would need to be encoded somewhere. This matters a lot to the UA, so I 
>> think this option would have to be encoded as part of the registration 
> If you want outbound's redundant-flow functionality, which is dependent 
> on requests NOT forking to each flow to a UA, use outbound as specified.
> 
> If instead you want your two contacts treated as two different instances 
> so that requests will fork to them, use two different instance-id 
> values. Essentially, you're using single-contact/single flow Outbound 
> (i.e., keepalive and reverse-routing of requests without redundant-flow) 
> simultaneously on two different contacts (which may well be two 
> different interfaces).
> 
> instances (or use virtual interfaces by having multiple instances on the 
> same interface), then apply outbound as specified on each instance, 
> where there are at least two proxies configured for each instance.
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 17 Oct 2008 08:44:11 +0100

+1

John 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 17 October 2008 01:08
> To: Dean Willis
> Cc: Christer Holmberg; Elwell, John; Bob Penfield; Juha 
> Heinanen; [email-masked]

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 17 Oct 2008 10:08:08 +0200

Hi,

The please-perform-parallel-forking-to-the-same-intance-id extension
indication would then be brought as a separate draft.

Regards,

Christer

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 17. lokakuuta 2008 10:44
To: Paul Kyzivat; Dean Willis
Cc: Christer Holmberg; Bob Penfield; Juha Heinanen; [email-masked]
Subject: RE: [Sip] Dual registration without Outbound

+1

John 

> Cc: Christer Holmberg; Elwell, John; Bob Penfield; Juha Heinanen; 
> [email-masked]

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 17 Oct 2008 10:26:53 +0100

Christer,

It is not clear why would need anything else. Why would you need to
parallel fork to the same instance ID, when you can use different
instance IDs?

John 

> Sent: 17 October 2008 09:08
> To: Elwell, John; Paul Kyzivat; Dean Willis
> Cc: Bob Penfield; Juha Heinanen; [email-masked]

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 17 Oct 2008 11:33:18 +0200

Hi, 

I don't need it, but Juha does :)

Regards,

Christer

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 17 Oct 2008 12:40:38 +0300

> parallel fork to the same instance ID, when you can use different

just one clarifying question:

it was not clear to me if separate instance ids need to be used for
different contacts of the same ua, can a single register request contain
both contacts and their instance ids?  for example, if my ua has two
contacts and ob set has two proxies, does my ua need to send two or four
register requests?

if four, i cannot accept a draft which causes such a mess.

-- juha

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 17 Oct 2008 12:59:53 +0100

I believe that Dean's description in his most recent posting described
the situation well. I think in that case you do indeed need to register
4 times, but I don't regard that as a mess. I just think we need a small
amount of clarifying text in the present draft.

John 

> Sent: 17 October 2008 10:41
> To: Elwell, John
> Cc: Christer Holmberg; Paul Kyzivat; Dean Willis; Bob 
> Penfield; [email-masked]

---

From: <[email-masked]>
Date: Fri, 17 Oct 2008 15:17:54 +0300

Hi,

Agreed.

I've been trying to follow this thread here and there and finally got
some clarity by reading Dean's mail below. In general high availability
and also parallel forking are nice, but I'm definitely against any
normative statements on how many flows UA needs to use. For instace the
case Juha is describing, i.e. parallel registrations over GPRS and WLAN
with parallel forking would have a trade off that the device battery
would run out much sooner with a single GPRS- *or* WLAN-bound
registration. So, for that reason I don't think that would be the best
default choice for an UA in a battery powered wireless device.

What Dean is describing below seems good as it is up to the UA to decide
what to do while everything seems possible and there shouldn't be
serious IOP issues even if UAs preferred different strategies. And above
all we don't need to agree beforehand on what would be the best way.

Markus 

>Behalf Of ext Elwell, John
>Sent: 17 October, 2008 10:44
>Cc: Bob Penfield; [email-masked]; Christer Holmberg

---

From: Dean Willis <[email-masked]>
Date: Fri, 17 Oct 2008 09:09:48 -0500

> indication would then be brought as a separate draft.

Do we need such an extension when there is a workaround -- using  
different instance-id?

---

From: Dean Willis <[email-masked]>
Date: Fri, 17 Oct 2008 09:55:39 -0500

> if four, i cannot accept a draft which causes such a mess.

Keep in mind that the processing of the REGISTER request forms the  
flow-path. As the request and response traverse the proxies, the  
information needed for service-route and path are discovered and stored.

Let us first think about registrations from different physical  
interfaces. Since the edge proxy on each interface is likely to be  
different, the flow-path needed for each registration is different.  
Clearly each outbound registration from a different interface requires  
a separate REGISTER request in order to assure formation of a correct  
flow-path.

In the typical outbound case, the edge proxy is also different for  
each reg-id. That's the goal of the redundancy function of outbound --  
allowing multiple edge proxy bindings. Since the edge proxy is  
recorded into the flow-path by the passage of the REGISTER request and  
response through that proxy, separate REGISTER requests would appear  
to be needed for each edge proxy (and consequently for each reg-ID  
from a given instance).

So the general solution for two instances, each of which has two  
registration flows through different edge proxies, would appear to  
require for REGISTER requests. This model provides full single-failure  
interface redundancy, flow redundancy, edge-proxy redundancy,  
transport redundancy, and possibly (depending on the registrar design)  
registrar redundancy, and provides multiple-failure redundancy in a  
number of scenarios. More importantly, it allows survivability for a  
dialog in the event of any single failure (except perhaps a total  
registrar failure).

Now it is entirely possible, Juha, that you have in mind some sort of  
reduced case-case use for Outbound. I think what you want requires two  
instances, each of which has a single flow-path to the registrar.  
Thus, only two registrations would be required. This provides a weaker  
survival model in-dialog than the two-instance/two-flow (2x2)  model,  
but has a different recovery model than the one-instance/two-flow base  
model of Outbound. There might be cases where this is seen as more  
suitable, although I can't identify one off-hand.

--
Dean

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 17 Oct 2008 10:19:26 -0500

On Oct 17, 2008, at 9:55 AM, Dean Willis wrote:

> require for REGISTER requests. This model provides full single- 
> failure interface redundancy, flow redundancy, edge-proxy  
> redundancy, transport redundancy, and possibly (depending on the  
> registrar design) registrar redundancy, and provides multiple- 
> failure redundancy in a number of scenarios. More importantly, it  
> allows survivability for a dialog in the event of any single failure  
> (except perhaps a total registrar failure).

That should have been a "four register requests", not  "for register  
requests":

So the general solution for two instances, each of which has two  
registration flows through different edge proxies, would appear to  
require four REGISTER requests. This model provides full single- 
failure interface redundancy, flow redundancy, edge-proxy redundancy,  
transport redundancy, and possibly (depending on the registrar design)  
registrar redundancy, and provides multiple-failure redundancy in a  
number of scenarios. More importantly, it allows survivability for a  
dialog in the event of any single failure (except perhaps a total  
registrar failure).

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sat, 18 Oct 2008 14:55:01 +0200

(As individual)

At the moment, it may be that there is a useful information or BCP that
could back the existing mechansisms up, but I am not seeing in this
thread at the moment a significant justification for a new extension.

And of course such an informational or BCP would only exist if someone
volunteered to draft one.

Regards

Keith 

> Sent: Friday, October 17, 2008 3:10 PM
> To: Christer Holmberg
> Cc: Bob Penfield; [email-masked]; Paul Kyzivat; Elwell, John
> Do we need such an extension when there is a workaround -- 
> using different instance-id?
> 
> --
> Dean

---

From: <[email-masked]>
Date: Tue, 21 Oct 2008 08:51:14 +0300

Hi Francois,

>I'm saying a new draft on redundant registration is needed, 
>and we can leave outbound AS IS.
>
>The reg-ids will distinguish the multiple registrations. The 
>+sip.instance will correlate them.

Funny, but your proposal reminds me about the email which
I sent to sip mailing list in Nov 2006:

http://www.ietf.org/mail-archive/web/sip/current/msg17495.html

What I proposed that time was essentially this:
----
Outbound draft has bundled together two different things
that actually are orthogonal, both as problems and as
solutions too. The only reason to keep them together in
one single spec is that in some environments it makes
sense to use them together, but the problem is that in
some other environments separation would be desirable.

Those two items could be described like this:

- A mechanism with which an UA would be able to maintain a
  persistent flow through a NAT/firewall towards an outbound 
  proxy, keep the flow alive and monitor its state. The
  mechanism would also define how the authoritative and edge 
  proxies would use the persistent flow and Path header for 
  forwarding incoming requests to the UA.

- A mechanism with which an UA instance would be able to achieve
  high availability towards its home domain, by maintaining
  multiple simultaneous registrations without the need to
  receive multiple forked copies of a single incoming request.
  This resiliency would enable the UA to protect its connectivity
  against edge proxy failures or access network connectivity 
  failures. This mechanism would introduce the reg-id parameter
  to Contact and allow the authoritative proxy to forward
  requests to the UA using the set of registered Contacts
  and corresponding Paths.
----

I proposed to split Outbound to two drafts along with those
lines:
a) flow keepalive draft
b) multiple registration draft

Interestingly enough I find the proposed flow keepalive draft
to highly correlate to the Outbound original requirements
(from Keith's recent email):

On the other hand, the multiple reg draft does not have any direct
relation to these requirements, even if you could argue multiple
registrations would be needed to make the solution more robust
against NAT reboots (item 6). To me it really attacks SIP proxy
reboots or any network failures for multihomed UAs, something
_not_ within the original requirements of Outbound.

>The reg-ids will distinguish the multiple registrations. The 
>+sip.instance will correlate them.

The only real difference between our proposals is that you
suggest usage of +sip.instance and reg-id to be defined in
a rather similar way in two drafts: Outbound and a new one.
I was proposing to move all that stuff to another draft so
that implementations could implement support for keepalives
and multiple registration either separately or combined,
depending on the problems they try to solve.

P.S. Personally I believe all this discussion is just too late,
decisions have been taken years ago and most of the WG members
are probably too tired with this subject to do any work for it.

Regards,

Erkki

>Behalf Of ext Francois Audet
>Sent: 08.October.2008 19:48
>To: Juha Heinanen
>Cc: [email-masked]; Paul Kyzivat; Christer Holmberg; DRAGE,Keith 
>(Keith); Dean Willis

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 21 Oct 2008 09:53:04 +0200

Hi, 

>_not_ within the original requirements of Outbound.

Isn't the second part ("be able to correct for this") of item 4 related
to Outbound?

>a rather similar way in two drafts: Outbound and a new one.

I personally think that the definition of instance-id belongs to the
gruu spec.

But, I assume that has been discussed before, so...

>depending on the problems they try to solve.

To me the main problem is not that the keepalives are defined in
Outbound, but that it is currently not possible to negotiate the usage
of them without Outbound. But, the intention of the keep draft is to
solve that.

Regards,

Christer

---

From: <[email-masked]>
Date: Tue, 21 Oct 2008 11:48:30 +0300

Hi, 

>>   4.  Detect failure of a connection and be able to correct for this.

I can read that as a requirement for the UA to re-establish 
flows which the UA detects as failed. The requirement itself
does not say anything about how quickly all that should be
done, but nevertheless the design decision in Outbound was
to add support for multiple flows for redundancy and elimination
of blackout periods for a single flow failure. 

As pointed out earlier, I would have been happier to see that 
solution defined in a separate draft as there is a demand for
a separate multi-registration draft without keepalive support.

Regards,

Erkki

>From: ext Christer Holmberg [mailto:[email-masked]] 
>Sent: 21.October.2008 10:53
>To: Koivusalo Erkki (Nokia-D/Helsinki); [email-masked]; [email-masked]
>Cc: [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]