Subject: Re: [martini] draft-vanelburg-martini-friends-00

From: Laura Liess <[email-masked]>
Date: Fri, 18 Jun 2010 14:12:42 +0200

+1

I agree with Paul. Having two completly different "standards" is not a
good choice. In the end everybody will need to implement both,
whatever the intention now.

 Laura

From: Paul Kyzivat <pkyzivat at cisco.com>
To: "martini at ietf.org" <martini at ietf.org>
Date: Wed, 16 Jun 2010 19:35:23 -0400
List-id: Discussion of en-mass SIP PBX registration mechanisms
<martini.ietf.org>

--------------------------------------------------------------------------------
Somehow I missed this draft before, but following the interim meeting
today I read it.

IIUC this proposal is similar to the original "shaken" proposal (I
think that was the one) to use the Contact-URI from REGISTER as a
Route header rather than using it to rewrite the R-URI (which was
adapted for martini by the gin draft).

There were pros and cons to both of those proposals. IMO we eventually
decided to pursue -gin because its balance of pros to cons was
thought, at the time, to be better than the alternative.

Now -friends essentially proposes to adopt both approaches. ISTM that
is the worst of all possible worlds. Its double the work for those who
want to support both, and it presents interop problems for those who
don't support both. And its just two solutions to the same problem -
there is almost no benefit to having both over having one.

IMO there needs to be a *choice* among alternative approaches. (They
pay us the big bucks to make hard choices.) Potentially we could make
such a choice, if we had two proposals of comparable completeness to
choose among. For that I think we would need another draft, that
fleshes out the "domain federation" approach. (Maybe -shaken or
another of Hadriel's early drafts on the subject could be a starting
point.) Just pointing to an ETSI document isn't enough.

Some tricky things that have come up along the way with -gin would
also need to be dealt with in this alternative. Among them is GRUU,
especially temporary GRUUs. Something similar to what Adam has
proposed for -gin is probably needed to address the same issues.

Also, some issues unique to this approach need to be addressed.
Specifically, how does the registered contact that becomes a Route
header interact with
- existing Route headers in the incoming request?
- Path headers that were registered?

There may also be issues with routing spirals when using GRUUs. This
was a knotty problem in IMS. (I wrote some text regarding that which
may or may not have made it into 24.229.) (To be fair, this issue may
also exist with -gin, so it will need to be investigated/solved either
way.)

I liked Jonathan's original proposal to switch registration routing to
use Route headers. I could be happy with a Martini approach that went
in that direction if it deals with all the loose ends.

So to the authors of -friends (and their friends) I suggest that if
you want to see a martini solution that uses the "domain federation"
approach, please submit a draft that spells out all the details needed
to define that.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Jun 2010 14:50:25 +0200

Hi,

I agree with Laura and others.

Also, let's keep in mind that the possibility of having two solutions has been on the table for a long time. Many people did not agree to the restrictions (e.g related to numbering) that were suggested for GIN, and it was suggested that we first do GIN, since there was a time issue, and then work on a solution that do not have the same restrictions.

Ie the idea was not to close MARTINI after GIN is done.

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Laura Liess
> Sent: 18. kesäkuuta 2010 15:13
> To: [email-masked]
> Subject: Re: [martini] draft-vanelburg-martini-friends-00
> 
> +1
> 
> I agree with Paul. Having two completly different "standards" 
> is not a good choice. In the end everybody will need to 
> implement both, whatever the intention now.
> 
>  Laura
> 
> 
> 
> 
> List-id: Discussion of en-mass SIP PBX registration 
> mechanisms <martini.ietf.org>
> 
> Somehow I missed this draft before, but following the interim 
> meeting today I read it.
> 
> 
> IIUC this proposal is similar to the original "shaken" 
> proposal (I think that was the one) to use the Contact-URI 
> from REGISTER as a Route header rather than using it to 
> rewrite the R-URI (which was adapted for martini by the gin draft).
> 
> 
> There were pros and cons to both of those proposals. IMO we 
> eventually decided to pursue -gin because its balance of pros 
> to cons was thought, at the time, to be better than the alternative.
> 
> 
> Now -friends essentially proposes to adopt both approaches. 
> ISTM that is the worst of all possible worlds. Its double the 
> work for those who want to support both, and it presents 
> interop problems for those who don't support both. And its 
> just two solutions to the same problem - there is almost no 
> benefit to having both over having one.
> 
> 
> IMO there needs to be a *choice* among alternative 
> approaches. (They pay us the big bucks to make hard choices.) 
> Potentially we could make such a choice, if we had two 
> proposals of comparable completeness to choose among. For 
> that I think we would need another draft, that fleshes out 
> the "domain federation" approach. (Maybe -shaken or another 
> of Hadriel's early drafts on the subject could be a starting
> Some tricky things that have come up along the way with -gin 
> would also need to be dealt with in this alternative. Among 
> them is GRUU, especially temporary GRUUs. Something similar 
> to what Adam has proposed for -gin is probably needed to 
> address the same issues.
> 
> 
> Specifically, how does the registered contact that becomes a 
> Route header interact with
> There may also be issues with routing spirals when using 
> GRUUs. This was a knotty problem in IMS. (I wrote some text 
> regarding that which may or may not have made it into 
> 24.229.) (To be fair, this issue may also exist with -gin, so 
> it will need to be investigated/solved either
> way.)
> 
> 
> I liked Jonathan's original proposal to switch registration 
> routing to use Route headers. I could be happy with a Martini 
> approach that went in that direction if it deals with all the 
> loose ends.
> 
> 
> So to the authors of -friends (and their friends) I suggest 
> that if you want to see a martini solution that uses the 
> "domain federation"
> approach, please submit a draft that spells out all the 
> details needed to define that.
> 
> 	Thanks,
> 	Paul
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: <[email-masked]>
Date: Fri, 18 Jun 2010 16:54:52 +0200

These are not two COMPLETELY different "standards", just two modes of operation: basic (current gin) and federated (friends)bulk contact routing. The difference between the two modes is only on the contents of the Request-URI (i.e. whether it is rewritten or not by the SSP). A PBX is not required to support both. The value(s) of the bulk contact parameter will tell to the SSP which mode(s) it supports.

BC

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Laura Liess
> Envoyé : vendredi 18 juin 2010 14:13
> À : [email-masked]
> Objet : Re: [martini] draft-vanelburg-martini-friends-00
> 
> +1
>

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 18 Jun 2010 12:09:11 -0400

And the customers will ultimately decide which one to use.  For the X time
There are serious operational issues in the SMB markets that drove the
decisions on how gin was designed.  There is not one size fits all IMHO. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Friday, June 18, 2010 10:55 AM
To: [email-masked]; [email-masked]
Subject: Re: [martini] draft-vanelburg-martini-friends-00

These are not two COMPLETELY different "standards", just two modes of
operation: basic (current gin) and federated (friends)bulk contact routing.
The difference between the two modes is only on the contents of the
Request-URI (i.e. whether it is rewritten or not by the SSP). A PBX is not
required to support both. The value(s) of the bulk contact parameter will
tell to the SSP which mode(s) it supports.

BC