Subject: [martini] Call for Adoption of "Registration for Multiple Phone Numbers in the SIP"

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 4 Mar 2010 14:02:20 -0800

This is a MARTINI WG Call for Adoption of "Registration for Multiple Phone
Numbers in the SIP" as a MARTINI WG work item, corresponding to the
"Multiple AoR Registration specification" Charter deliverable.  The document
is available for inspection here: 

http://tools.ietf.org/html/draft-roach-martini-gin-01.txt

The MARTINI WG Call for Adoption will last until Friday, March 19, 2010.

Please respond to this WG Call for Adoption, whether you are in favor of
adopting the document as a MARTINI WG work item or not.  If you have no
comments, please reply to this message and indicate in the body of your
message whether you think the document is ready for adoption as a MARTINI WG
work item or not.   Based on the response, the MARTINI WG chairs will
attempt to determine whether WG consensus exists to adopt the document or
not. 

If you have comments, please provide them to the WG in one of the following
ways: 

1.      The preferred choice is to open an issue in the MARTINI Issue
tracking database (TRAC), which is available here:
<http://trac.tools.ietf.org/wg/martini/trac/newticket>
http://trac.tools.ietf.org/wg/martini/trac/newticket  Information on how to
use TRAC is provided below.  Note that if you submit an issue in TRAC, it
will automatically also be posted to the MARTINI WG mailing list.  When
submitting issues in TRAC for this "call for adoption", please enter "gin"
for the Component: and "Candidate WG Document" for Severity.  

 2. If you can't figure out how to use TRAC, please post your Issue to the
MARTINI WG mailing list (martini at ietf.org) in the following format: 

To:  martini at ietf.org

Subject: GIN-Issue: <title of your issue>

Priority: blocker, critical, major, minor or trivial

<Explanation of your issue, including a proposal for specific text changes
to resolve the issue>

The MARTINI WG uses the TRAC database to keep track of issues relating to
work in progress, including working group work items and individual
submissions undergoing review.    This document provides some basic
information on how MARTINI WG participants can use TRAC to submit or edit
issues.  

Documentation relating to the TRAC Issue Tracking database is available
here:

http://trac.tools.ietf.org/wg/martini/trac/wiki

Since this documentation is somewhat lengthy (and mostly relevant to
Admins), here is a pithy synopsis. 

1.       To submit an issue in the MARTINI Issues database (known as TRAC),
you first need to login to the MARTINI WG site on the tools server
(http://tools.ietf.org/wg/martini/trac/login ) 

2.       If you don't already have a login ID, you can obtain one by
navigating to this site:   http://trac.tools.ietf.org/newlogin

3.       Once you have obtained an account, you can log in by clicking on
the "login" entry at the top of the page.  Once you have logged in, you can
file an issue by navigating to the  ticket entry form:
<http://trac.tools.ietf.org/wg/martini/trac/newticket>
http://trac.tools.ietf.org/wg/martini/trac/newticket

4     When opening an issue: 

a.       The Type: field should be set to "defect" for an issue with the
current document text, or "enhancement" for a proposed addition of
functionality (such as an additional requirement). 

b.      The Priority: field is set based on the severity of the Issue.   For
example, editorial issues are typically "minor" or "trivial". 

c.       The Milestone: field should be set to milestone1 (useless, I know).

d.      The Component: field should be set to the document you are filing
the issue on.  In responding to the GIN Call for Adoption, "gin" is the
appropriate choice.

e.      The Version: field should be set to "1.0". 

f.        The Severity: field should be set to based on the status of the
document (e.g. "Candidate WG Document" in this case)

g.        The Keywords: and CC: fields can be left blank unless inspiration
seizes you. 

h.      The Assign To: field is generally filled in with the email address
of the editor. 

5.       Typically it won't be necessary to enclose a file with the ticket,
but if you need to, select "I have files to attach to this ticket". 

6.       If you want to preview your Issue, click on the "Preview" button.
When you're ready to submit the issue, click on the "Create Ticket" button. 

That's it!  

If you have an problems in dealing with TRAC, send email to me and I'll try
to figure out what's going on. 

Happy TRACing,

Bernard

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 5 Mar 2010 00:13:00 +0100

While you may be wanting to keep to the MARTINI timescales - I for one am struggling to keep up with this.

You have the WGLC for requirements in the middle of a major 3GPP meeting (a draft I still need to review and comment on), and now you are doing the adoption for GIN in the run up to the Anaheim, when I know there are still issues to address here as well - as to whether this even bears commonality for where we need to get to.

So my view is NO, because it is too early. Doing this now ensures that MARTINI goes a different way to the rest of the world and you end up with yet another interdace to support.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Thursday, March 04, 2010 10:02 PM
To: 'MARTINI'
Subject: [martini] Call for Adoption of "Registration for Multiple Phone Numbers in the SIP"

This is a MARTINI WG Call for Adoption of “Registration for Multiple Phone Numbers in the SIP” as a MARTINI WG work item, corresponding to the “Multiple AoR Registration specification” Charter deliverable.  The document is available for inspection here:
http://tools.ietf.org/html/draft-roach-martini-gin-01.txt
The MARTINI WG Call for Adoption will last until Friday, March 19, 2010.
Please respond to this WG Call for Adoption, whether you are in favor of adopting the document as a MARTINI WG work item or not.  If you have no comments, please reply to this message and indicate in the body of your message whether you think the document is ready for adoption as a MARTINI WG work item or not.   Based on the response, the MARTINI WG chairs will attempt to determine whether WG consensus exists to adopt the document or not.
If you have comments, please provide them to the WG in one of the following ways:

1.      The preferred choice is to open an issue in the MARTINI Issue tracking database (TRAC), which is available here: http://trac.tools.ietf.org/wg/martini/trac/newticket  Information on how to use TRAC is provided below.  Note that if you submit an issue in TRAC, it will automatically also be posted to the MARTINI WG mailing list.  When submitting issues in TRAC for this “call for adoption”, please enter “gin” for the Component: and “Candidate WG Document” for Severity.
 2. If you can’t figure out how to use TRAC, please post your Issue to the MARTINI WG mailing list (martini at ietf.org) in the following format:
To:  martini at ietf.org
Subject: GIN-Issue: <title of your issue>
Priority: blocker, critical, major, minor or trivial
<Explanation of your issue, including a proposal for specific text changes to resolve the issue>
The MARTINI WG uses the TRAC database to keep track of issues relating to work in progress, including working group work items and individual submissions undergoing review.    This document provides some basic information on how MARTINI WG participants can use TRAC to submit or edit issues.
Documentation relating to the TRAC Issue Tracking database is available here:
http://trac.tools.ietf.org/wg/martini/trac/wiki
Since this documentation is somewhat lengthy (and mostly relevant to Admins), here is a pithy synopsis.

1.       To submit an issue in the MARTINI Issues database (known as TRAC), you first need to login to the MARTINI WG site on the tools server (http://tools.ietf.org/wg/martini/trac/login )

2.       If you don’t already have a login ID, you can obtain one by navigating to this site:   http://trac.tools.ietf.org/newlogin

3.       Once you have obtained an account, you can log in by clicking on the “login” entry at the top of the page.  Once you have logged in, you can file an issue by navigating to the  ticket entry form: http://trac.tools.ietf.org/wg/martini/trac/newticket

4     When opening an issue:

a.       The Type: field should be set to “defect” for an issue with the current document text, or “enhancement” for a proposed addition of functionality (such as an additional requirement).

b.      The Priority: field is set based on the severity of the Issue.   For example, editorial issues are typically “minor” or “trivial”.

d.      The Component: field should be set to the document you are filing the issue on.  In responding to the GIN Call for Adoption, “gin” is the appropriate choice.

e.      The Version: field should be set to “1.0”.

f.        The Severity: field should be set to based on the status of the document (e.g. “Candidate WG Document” in this case)

g.        The Keywords: and CC: fields can be left blank unless inspiration seizes you.

h.      The Assign To: field is generally filled in with the email address of the editor.

5.       Typically it won’t be necessary to enclose a file with the ticket, but if you need to, select “I have files to attach to this ticket”.

6.       If you want to preview your Issue, click on the “Preview” button.  When you’re ready to submit the issue, click on the “Create Ticket” button.
That’s it!
If you have an problems in dealing with TRAC, send email to me and I’ll try to figure out what’s going on.
Happy TRACing,
Bernard

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 5 Mar 2010 08:54:41 +0100

I'm in favour.

John

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: 04 March 2010 22:02
To: 'MARTINI'
Subject: [martini] Call for Adoption of "Registration for Multiple Phone Numbers in the SIP"

This is a MARTINI WG Call for Adoption of "Registration for Multiple Phone Numbers in the SIP" as a MARTINI WG work item, corresponding to the "Multiple AoR Registration specification" Charter deliverable.  The document is available for inspection here:

1.      The preferred choice is to open an issue in the MARTINI Issue tracking database (TRAC), which is available here: http://trac.tools.ietf.org/wg/martini/trac/newticket  Information on how to use TRAC is provided below.  Note that if you submit an issue in TRAC, it will automatically also be posted to the MARTINI WG mailing list.  When submitting issues in TRAC for this "call for adoption", please enter "gin" for the Component: and "Candidate WG Document" for Severity.
 2. If you can't figure out how to use TRAC, please post your Issue to the MARTINI WG mailing list (martini at ietf.org) in the following format:
To:  martini at ietf.org
Subject: GIN-Issue: <title of your issue>
Priority: blocker, critical, major, minor or trivial
<Explanation of your issue, including a proposal for specific text changes to resolve the issue>
The MARTINI WG uses the TRAC database to keep track of issues relating to work in progress, including working group work items and individual submissions undergoing review.    This document provides some basic information on how MARTINI WG participants can use TRAC to submit or edit issues.
Documentation relating to the TRAC Issue Tracking database is available here:
http://trac.tools.ietf.org/wg/martini/trac/wiki
Since this documentation is somewhat lengthy (and mostly relevant to Admins), here is a pithy synopsis.

2.       If you don't already have a login ID, you can obtain one by navigating to this site:   http://trac.tools.ietf.org/newlogin

3.       Once you have obtained an account, you can log in by clicking on the "login" entry at the top of the page.  Once you have logged in, you can file an issue by navigating to the  ticket entry form: http://trac.tools.ietf.org/wg/martini/trac/newticket

4     When opening an issue:

a.       The Type: field should be set to "defect" for an issue with the current document text, or "enhancement" for a proposed addition of functionality (such as an additional requirement).

b.      The Priority: field is set based on the severity of the Issue.   For example, editorial issues are typically "minor" or "trivial".

d.      The Component: field should be set to the document you are filing the issue on.  In responding to the GIN Call for Adoption, "gin" is the appropriate choice.

f.        The Severity: field should be set to based on the status of the document (e.g. "Candidate WG Document" in this case)

5.       Typically it won't be necessary to enclose a file with the ticket, but if you need to, select "I have files to attach to this ticket".

6.       If you want to preview your Issue, click on the "Preview" button.  When you're ready to submit the issue, click on the "Create Ticket" button.
That's it!
If you have an problems in dealing with TRAC, send email to me and I'll try to figure out what's going on.
Happy TRACing,
Bernard

---

From: Alan Johnston <[email-masked]>
Date: Fri, 05 Mar 2010 10:10:26 -0600

I would support this.

- Alan -

On 3/4/10 4:02 PM, Bernard Aboba wrote:
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 5 Mar 2010 11:11:15 -0500

I'm in favor of it - we need to move forward, and GIN is close enough to Shaken that I think we might was well just go forward with GIN and get this done.
-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Thursday, March 04, 2010 5:02 PM
To: 'MARTINI'
Subject: [martini] Call for Adoption of "Registration for Multiple Phone Numbers in the SIP"

4     When opening an issue:

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 5 Mar 2010 08:38:50 -0800

+1. 

From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, March 05, 2010 8:11 AM
To: Bernard Aboba; 'MARTINI'
Subject: RE: [martini] Call for Adoption of "Registration for Multiple Phone
Numbers in the SIP"

I'm in favor of it - we need to move forward, and GIN is close enough to
Shaken that I think we might was well just go forward with GIN and get this
done.

-hadriel

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bernard Aboba
Sent: Thursday, March 04, 2010 5:02 PM
To: 'MARTINI'
Subject: [martini] Call for Adoption of "Registration for Multiple Phone
Numbers in the SIP"

To:  martini at ietf.org

4     When opening an issue: 

That's it!  

Happy TRACing,

Bernard

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 5 Mar 2010 12:15:12 -0500

+1 as well.

 I totally concur. Hadriel ..I know you can work with Adam on incorporating
any issues you can have into Gin  and I certainly think you deserve
significant recognition for all of your hard work in shaken.

We all owe Hadriel a Bombay Sapphire Gin Martini in Anaheim.

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hadriel Kaplan
Sent: Friday, March 05, 2010 11:11 AM
To: Bernard Aboba; 'MARTINI'
Subject: Re: [martini] Call for Adoption of "Registration for Multiple Phone
Numbers in the SIP"

-hadriel

  _____  

To:  martini at ietf.org

4     When opening an issue: 

That's it!  

Happy TRACing,

Bernard

---

From: Victor Pascual Avila <[email-masked]>
Date: Fri, 5 Mar 2010 18:29:05 +0100

+1

On Fri, Mar 5, 2010 at 6:15 PM, Richard Shockey <[email-masked]> wrote:
> I’m in favor of it – we need to move forward, and GIN is close enough to
> This is a MARTINI WG Call for Adoption of “Registration for Multiple Phone
> Numbers in the SIP” as a MARTINI WG work item, corresponding to the
> “Multiple AoR Registration specification” Charter deliverable.  The document
> submitting issues in TRAC for this “call for adoption”, please enter “gin”
> for the Component: and “Candidate WG Document” for Severity.
>
>  2. If you can’t figure out how to use TRAC, please post your Issue to the
> 2.       If you don’t already have a login ID, you can obtain one by
> the “login” entry at the top of the page.  Once you have logged in, you can
> a.       The Type: field should be set to “defect” for an issue with the
> current document text, or “enhancement” for a proposed addition of
> example, editorial issues are typically “minor” or “trivial”.
>
> the issue on.  In responding to the GIN Call for Adoption, “gin” is the
> appropriate choice.
>
> document (e.g. “Candidate WG Document” in this case)
>
> 5.       Typically it won’t be necessary to enclose a file with the ticket,
> but if you need to, select “I have files to attach to this ticket”.
>
> 6.       If you want to preview your Issue, click on the “Preview” button.
> When you’re ready to submit the issue, click on the “Create Ticket” button.
>
> That’s it!
>

-- 
Victor Pascual Ávila

---

From: Dean Willis <[email-masked]>
Date: Fri, 5 Mar 2010 12:11:32 -0600

On Mar 4, 2010, at 5:13 PM, DRAGE, Keith (Keith) wrote:

> You have the WGLC for requirements in the middle of a major 3GPP  
> meeting (a draft I still need to review and comment on), and now you  
> are doing the adoption for GIN in the run up to the Anaheim, when I  
> know there are still issues to address here as well - as to whether  
> this even bears commonality for where we need to get to.
>
> So my view is NO, because it is too early. Doing this now ensures  
> that MARTINI goes a different way to the rest of the world and you  
> end up with yet another interdace to support.

It's true that we've been moving very quickly on this work. I'm  
astounded at the level of energy and enthusiasm expressed. This is  
exactly the sort of response I was hoping for when I pushed for  
smaller, task-focused, and short-lived working groups as opposed to  
the eternal lumbering behemoths of SIP and SIPPING.

Working on "Internet time" is at odds with the longer review/work  
cycle of other SDOs like 3GPP. This can make for some painful  
adjustments and rethinking of the way we do things. I'm sorry that  
this is making it hard for some of our folks who are concurrently  
working in multiple organizational temporalities. But I think it is  
absolutely critical that we keep our momentum going and not slip back  
into a trimester hibernation cycle. Hibernation might be great for  
ground hogs, but it doesn't lead to particularly good weather  
forecasting or the rapid development of community consensus.

I'd also like to point out that adoption of a draft is not conclusion  
of the work; we still expect to see a large amount of review, and may  
see some substantive changes,  That is, after all, the IETF's work  
process.

On the comment of "yet another interface to support": The goal of  
doing MARTINI registration as I understand it has been merely to clean  
up and standardize an existing broadly (but diversely) deployed  
interface. It's not the final answer to the problem, and I think it's  
OK that IMS has a slightly different answer to a slightly different  
problem. I fully expect to go on from here towards solving the more  
general dynamic route-binding problem (another fact of which we are  
currently seeing in DISPATCH).

So at this time, I'd like to endorse the adoption of "gin" as a  
standardized component of the proper MARTINI. I'll leave it to Hadriel  
and Adam to lead the conversation as to whether we want our gin  
shaken, stirred, or possibly blended into the final confection. And  
hopefully Keith can look up from his 3GPP work long enough to partake  
of a few SIPs along the way.

--
Dean

---

From: "Jack Burton" <[email-masked]>
Date: Sat, 06 Mar 2010 16:14:23 -0500

In Favor.
 
-Jack

Jack Burton
Dir. Systems Engineering
Cablevision
[email-masked] 
516-803-9733 

>>> "Bernard Aboba" <[email-masked]> 3/4/2010 17:02 >>>

This is a MARTINI WG Call for Adoption of *Registration for Multiple
Phone Numbers in the SIP* as a MARTINI WG work item, corresponding to
the *Multiple AoR Registration specification* Charter deliverable.  The
document is available for inspection here: 
http://tools.ietf.org/html/draft-roach-martini-gin-01.txt 
The MARTINI WG Call for Adoption will last until Friday, March 19,
2010.
Please respond to this WG Call for Adoption, whether you are in favor
of adopting the document as a MARTINI WG work item or not.  If you have
no comments, please reply to this message and indicate in the body of
your message whether you think the document is ready for adoption as a
MARTINI WG work item or not.   Based on the response, the MARTINI WG
chairs will attempt to determine whether WG consensus exists to adopt
the document or not. 
If you have comments, please provide them to the WG in one of the
following ways: 
1.      The preferred choice is to open an issue in the MARTINI Issue
tracking database (TRAC), which is available here:
http://trac.tools.ietf.org/wg/martini/trac/newticket  Information on
how to use TRAC is provided below.  Note that if you submit an issue in
TRAC, it will automatically also be posted to the MARTINI WG mailing
list.  When submitting issues in TRAC for this *call for adoption*,
please enter *gin* for the Component: and *Candidate WG Document* for
Severity.  
 2. If you can*t figure out how to use TRAC, please post your Issue to
the MARTINI WG mailing list (martini at ietf.org) in the following
format: 
To:  martini at ietf.org
Subject: GIN-Issue: <title of your issue>
Priority: blocker, critical, major, minor or trivial
<Explanation of your issue, including a proposal for specific text
changes to resolve the issue>
The MARTINI WG uses the TRAC database to keep track of issues relating
to work in progress, including working group work items and individual
submissions undergoing review.    This document provides some basic
information on how MARTINI WG participants can use TRAC to submit or
edit issues.  
Documentation relating to the TRAC Issue Tracking database is available
here:
http://trac.tools.ietf.org/wg/martini/trac/wiki 
Since this documentation is somewhat lengthy (and mostly relevant to
Admins), here is a pithy synopsis. 
1.       To submit an issue in the MARTINI Issues database (known as
TRAC), you first need to login to the MARTINI WG site on the tools
server (http://tools.ietf.org/wg/martini/trac/login ) 
2.       If you don*t already have a login ID, you can obtain one by
navigating to this site:   http://trac.tools.ietf.org/newlogin 
3.       Once you have obtained an account, you can log in by clicking
on the *login* entry at the top of the page.  Once you have logged in,
you can file an issue by navigating to the  ticket entry form:
http://trac.tools.ietf.org/wg/martini/trac/newticket
4     When opening an issue: 
a.       The Type: field should be set to *defect* for an issue with
the current document text, or *enhancement* for a proposed addition of
functionality (such as an additional requirement). 
b.      The Priority: field is set based on the severity of the Issue. 
 For example, editorial issues are typically *minor* or *trivial*. 
c.       The Milestone: field should be set to milestone1 (useless, I
know). 
d.      The Component: field should be set to the document you are
filing the issue on.  In responding to the GIN Call for Adoption, *gin*
is the appropriate choice.
e.      The Version: field should be set to *1.0*. 
f.        The Severity: field should be set to based on the status of
the document (e.g. *Candidate WG Document* in this case)
g.        The Keywords: and CC: fields can be left blank unless
inspiration seizes you. 
h.      The Assign To: field is generally filled in with the email
address of the editor. 
5.       Typically it won*t be necessary to enclose a file with the
ticket, but if you need to, select *I have files to attach to this
ticket*. 
6.       If you want to preview your Issue, click on the *Preview*
button.  When you*re ready to submit the issue, click on the *Create
Ticket* button. 
That*s it!  
If you have an problems in dealing with TRAC, send email to me and I*ll
try to figure out what*s going on. 
Happy TRACing,
Bernard

-------------------------------------------------------- 
The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain information concerning Cablevision and/or its affiliates and subsidiaries that is proprietary, privileged, confidential and/or subject to copyright.   Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited and may be unlawful.  If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you have received and all copies thereof.
--------------------------------------------------------

---

From: <[email-masked]>
Date: Tue, 9 Mar 2010 10:08:46 +0100

De : [email-masked] [mailto:[email-masked]] De la part de Dean Willis
	Envoyé : vendredi 5 mars 2010 19:12
	À : DRAGE, Keith (Keith)
	Cc : Bernard Aboba; 'MARTINI'
	Objet : Re: [martini] Call for Adoption of "Registration for MultiplePhone Numbers in the SIP"

		

	It's true that we've been moving very quickly on this work. I'm astounded at the level of energy and enthusiasm expressed. This is exactly the sort of response I was hoping for when I pushed for smaller, task-focused, and short-lived working groups as opposed to the eternal lumbering behemoths of SIP and SIPPING.

	Working on "Internet time" is at odds with the longer review/work cycle of other SDOs like 3GPP. This can make for some painful adjustments and rethinking of the way we do things. I'm sorry that this is making it hard for some of our folks who are concurrently working in multiple organizational temporalities. But I think it is absolutely critical that we keep our momentum going and not slip back into a trimester hibernation cycle. Hibernation might be great for ground hogs, but it doesn't lead to particularly good weather forecasting or the rapid development of community consensus.

	I'd also like to point out that adoption of a draft is not conclusion of the work; we still expect to see a large amount of review, and may see some substantive changes,  That is, after all, the IETF's work process.

	On the comment of "yet another interface to support": The goal of doing MARTINI registration as I understand it has been merely to clean up and standardize an existing broadly (but diversely) deployed interface. It's not the final answer to the problem, and I think it's OK that IMS has a slightly different answer to a slightly different problem. I fully expect to go on from here towards solving the more general dynamic route-binding problem (another fact of which we are currently seeing in DISPATCH).
	
	[==>BC:] I think the situation is even worse than what Keith has described. As It's not only "yet another interface to support" but probably TWO other interfaces as it seems that a different solution will be required at a later stage for supporting other forms of URIs. I also think it's too early to go for WGLC.

	So at this time, I'd like to endorse the adoption of "gin" as a standardized component of the proper MARTINI. I'll leave it to Hadriel and Adam to lead the conversation as to whether we want our gin shaken, stirred, or possibly blended into the final confection. And hopefully Keith can look up from his 3GPP work long enough to partake of a few SIPs along the way.

	--
	Dean

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Dean Willis <[email-masked]>
Date: Tue, 9 Mar 2010 11:56:25 -0600

On Mar 9, 2010, at 3:08 AM, <[email-masked]> <[email-masked] 
 > wrote:

> I think the situation is even worse than what Keith has described.  
> As It's not only "yet another interface to support" but probably TWO  
> other interfaces as it seems that a different solution will be  
> required at a later stage for supporting other forms of URIs. I also  
> think it's too early to go for WGLC.

I prefer to think of what GIN is currently doing as simply clarifying  
and standardizing what can be done with RFC 3261's REGISTER method for  
single-request registration of multiple phone numbers. This is a  
matter of converging multiple common implementations into a single  
standardized approach. It's not a "new" interface, but a cleanup of an  
underspecified one that already exists.

It's true that we aren't proposing (in this document) to standardize  
registration of multiple domain-style AORs with a single request.  
We're not agreed that REGISTER is even a reasonable general solution  
to that problem, nor are we likely to so agree at any time in the near  
future. Nor are we proposing to solve at this time the fundamental  
intra-domain or inter-domain routing problems (see current thread in  
DISPATCH).

A second "interface", as you and Keith describe it, is probably  
required because REGISTER itself is fundamentally unsuited to solving  
the general routing problem. All we're doing in this document (gin) is  
the part of the problem that REGISTER can reasonably solve when the  
target identities are expressed as phone numbers.

I'd argue that REGISTER could also be reasonably used for handling  
registration of multiple domain-style URIs (AORs) when those AOR-URIs  
are all scoped to the same authentication domain AND the right-hand- 
side of the contact-URI is identical across all contact-URI's being  
registered within a single request AND there is a one-to-one mapping  
between AOR-URI and contact-URI produced in the registrar as a result  
of the request. This might well be within the scope of MARTINI, and is  
a completely separable problem. It could be documented in the same  
RFC, or documented in a second RFC, should we choose to pursue that  
line of work. I would argue that such an approach would not constitute  
a separate interface in either case (same or different documents).  
Each would be a documentation of the REGISTER interface for  
registering multiple contacts within a single request -- one for  
multiple domain-style URIs, one for multiple phone numbers within a  
domain.

So, are you saying that:

1) You don't like the GIN mechanism and we shouldn't work from it for  
solving the multiple phone-number-registration problem.

2) You like the GIN mechanism but don't want to settle on it until we  
also have a proposal for dealing with the subset of the "registering  
multiple domain-style URIs in a single request" problem that can be  
dealt with using REGISTER.

2a) As 2, and you want the proposal for dealing with the subset of the  
"registering multiple domain-style URIs in a single request" problem  
that can be dealt with using REGISTER to be incorporated into the same  
document as the current gin solution before it is adopted as baseline  
text by the WG.

2b) As 2, and you want the proposal for dealing with the subset of the  
"registering multiple domain-style URIs in a single request" problem  
that can be dealt with using REGISTER to be presented in a separate  
document so that we can adopt them both concurrently.

3) You believe that REGISTER is the "universal hammer" for all SIP  
routing exchange problems, and are going to  block any partial  
solution until we all accept that approach and have a written proposal  
for solving all route-exchange problems using REGISTER.

4) Something entirely different (please specify).

And who said anything about WGLC of the solution? We're talking WGLC  
of the requirements draft, and adoption of the -gin- draft as a  
baseline text that we will then hammer on until we're ready for WGLC.

--
Dean

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 9 Mar 2010 10:41:00 -0800

[==>BC:] I think the situation is even worse than what Keith has described.
As It's not only "yet another interface to support" but probably TWO other
interfaces as it seems that a different solution will be required at a later
stage for supporting other forms of URIs. I also think it's too early to go
for WGLC.

[BA] To clarify -- this isn't a MARTINI WG last call, since GIN isn't a
MARTINI WG work item yet.  It's a "Call for Adoption" of GIN as a MARTINI WG
work item.

---

From: <[email-masked]>
Date: Tue, 9 Mar 2010 20:01:37 +0100

Strictly speaking it's not a new interface but in practice it means that a PBX will find different things in the Request URI of inbound requests depending on whether it is connected  to an IMS or a GIN-based network. In the first case, the R-URI will contain the original target identity while in the second case it will contain this special contact address built as described in the GIN draft. 

For the rest of my message, there was a typo in it! I intended to write that it was too early to accept this document as a WG Work Item but wrote WGLC... 

If I try to map what I meant to your 4 options, I believe I meant Option 1: I don't like the GIN mechanism in its present form as it does not preserve the original target identity in the R-URI and is restricted to E.164 numbers. However, what you have described as Option 2a is worth discussing. The definition of the <subset of the "registering multiple domain-style URIs in a single request" problem that can be dealt with using REGISTER> would also deserve further discussions. If it turns out that the gin draft can be extended to support a reasonable subset of the problem then it might become a better candidate for a WG Work Item. This does not solve the R-URI issue however.

/BC

> -----Message d'origine-----
> De : Dean Willis [mailto:[email-masked]] 
> Envoyé : mardi 9 mars 2010 18:56
> À : CHATRAS Bruno RD-CORE-ISS
> Cc : Keith Drage; MARTINI
> On Mar 9, 2010, at 3:08 AM, 
> <[email-masked]> 
> <[email-masked]  > wrote:
> 
> I prefer to think of what GIN is currently doing as simply 
> clarifying and standardizing what can be done with RFC 3261's 
> REGISTER method for single-request registration of multiple 
> phone numbers. This is a matter of converging multiple common 
> implementations into a single standardized approach. It's not 
> a "new" interface, but a cleanup of an underspecified one 
> that already exists.
> 
> It's true that we aren't proposing (in this document) to 
> standardize registration of multiple domain-style AORs with a 
> single request.  
> We're not agreed that REGISTER is even a reasonable general 
> solution to that problem, nor are we likely to so agree at 
> any time in the near future. Nor are we proposing to solve at 
> this time the fundamental intra-domain or inter-domain 
> routing problems (see current thread in DISPATCH).
> 
> A second "interface", as you and Keith describe it, is 
> probably required because REGISTER itself is fundamentally 
> unsuited to solving the general routing problem. All we're 
> doing in this document (gin) is the part of the problem that 
> REGISTER can reasonably solve when the target identities are 
> expressed as phone numbers.
> 
> I'd argue that REGISTER could also be reasonably used for 
> handling registration of multiple domain-style URIs (AORs) 
> when those AOR-URIs are all scoped to the same authentication 
> domain AND the right-hand- side of the contact-URI is 
> identical across all contact-URI's being registered within a 
> single request AND there is a one-to-one mapping between 
> AOR-URI and contact-URI produced in the registrar as a result 
> of the request. This might well be within the scope of 
> MARTINI, and is a completely separable problem. It could be 
> documented in the same RFC, or documented in a second RFC, 
> should we choose to pursue that line of work. I would argue 
> that such an approach would not constitute a separate 
> interface in either case (same or different documents).  
> registering multiple contacts within a single request -- one 
> for multiple domain-style URIs, one for multiple phone 
> numbers within a domain.
> 
> 
> So, are you saying that:
> 
> 1) You don't like the GIN mechanism and we shouldn't work 
> from it for solving the multiple phone-number-registration problem.
> 
> 2) You like the GIN mechanism but don't want to settle on it 
> until we also have a proposal for dealing with the subset of 
> the "registering multiple domain-style URIs in a single 
> request" problem that can be dealt with using REGISTER.
> 
> 2a) As 2, and you want the proposal for dealing with the 
> subset of the "registering multiple domain-style URIs in a 
> single request" problem that can be dealt with using REGISTER 
> to be incorporated into the same document as the current gin 
> solution before it is adopted as baseline text by the WG.
> 
> 2b) As 2, and you want the proposal for dealing with the 
> subset of the "registering multiple domain-style URIs in a 
> single request" problem that can be dealt with using REGISTER 
> to be presented in a separate document so that we can adopt 
> them both concurrently.
> 
> 3) You believe that REGISTER is the "universal hammer" for 
> all SIP routing exchange problems, and are going to  block 
> any partial solution until we all accept that approach and 
> have a written proposal for solving all route-exchange 
> problems using REGISTER.
> 
> And who said anything about WGLC of the solution? We're 
> talking WGLC of the requirements draft, and adoption of the 
> -gin- draft as a baseline text that we will then hammer on 
> until we're ready for WGLC.
> 
> --
> Dean
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 9 Mar 2010 22:06:17 -0600

On Mar 9, 2010, at 1:01 PM, <[email-masked]> <[email-masked] 
 > wrote:
>
> If I try to map what I meant to your 4 options, I believe I meant  
> Option 1: I don't like the GIN mechanism in its present form as it  
> does not preserve the original target identity in the R-URI

REGISTER under RFC 3261 does not preserve the target identity in the R- 
URI. Rather, it places the identity being registered in the To: header  
field.

Or are you saying you don't like contact-routing as described in RFC  
3261, because contact routing doesn't preserve the R-URI as seen by  
the home proxy; rather, the R-URI is replaced by the registered Contact.

If do, I don't like it either. But we can't do much about it without  
rather fundamental changes to RFC 3261, and I don't think that MARTINI  
is chartered to completely re-write the registration and contact- 
routing of RFC 3261, despite the fact that it desperately needs doing.

> and is restricted to E.164 numbers. However, what you have described  
> as Option 2a is worth discussing. The definition of the <subset of  
> the "registering multiple domain-style URIs in a single request"  
> problem that can be dealt with using REGISTER> would also deserve  
> further discussions. If it turns out that the gin draft can be  
> extended to support a reasonable subset of the problem then it might  
> become a better candidate for a WG Work Item.

Ok, let's start a separate thread for that topic.

> This does not solve the R-URI issue however.

Nor does it solve world peace, global climate change, or the  
inadequacy of socialized medicine to meet the very real demands of an  
aging population of baby boomers who are starting to get Even Sicker.  
We have about the same likely hood of solving those in MARTINI as we  
have of solving the "preservation of request-URI across contact  
routing" problem.

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 10 Mar 2010 09:45:35 +0100

Bruno,

I recall from the TISPAN business trunking discussions a couple of years ago that we tried to preserve the contents of the Request-URI, based on principles proposed in the Rosenberg loose route draft, which was under consideration at the IETF at the time and which we thought had a strong possibility of being adopted. Unfortunately (I can't recall the precise reasons, but backwards compatibility played a large part), the IETF decided not to go in that direction. Therefore it would be an uphill struggle to get the IETF to agree to adopt a similar principle now, in the context of the MARTINI work.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: 10 March 2010 04:06
> To: <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [martini] Call for Adoption of "Registration for 
> MultiplePhone Numbers in the SIP"
> 
> 
> On Mar 9, 2010, at 1:01 PM, 
> <[email-masked]> wrote:
> 
> 	
> 	If I try to map what I meant to your 4 options, I 
> believe I meant Option 1: I don't like the GIN mechanism in 
> its present form as it does not preserve the original target 
> identity in the R-URI 
> 
> 
> REGISTER under RFC 3261 does not preserve the target identity 
> in the R-URI. Rather, it places the identity being registered 
> in the To: header field.
> 
> Or are you saying you don't like contact-routing as described 
> in RFC 3261, because contact routing doesn't preserve the 
> R-URI as seen by the home proxy; rather, the R-URI is 
> replaced by the registered Contact.
> 
> If do, I don't like it either. But we can't do much about it 
> without rather fundamental changes to RFC 3261, and I don't 
> think that MARTINI is chartered to completely re-write the 
> registration and contact-routing of RFC 3261, despite the 
> fact that it desperately needs doing.
> 
> 
> 
> 	and is restricted to E.164 numbers. However, what you 
> have described as Option 2a is worth discussing. The 
> definition of the <subset of the "registering multiple 
> domain-style URIs in a single request" problem that can be 
> dealt with using REGISTER> would also deserve further 
> discussions. If it turns out that the gin draft can be 
> extended to support a reasonable subset of the problem then 
> it might become a better candidate for a WG Work Item. 
> 
> 
> inadequacy of socialized medicine to meet the very real 
> demands of an aging population of baby boomers who are 
> starting to get Even Sicker. We have about the same likely 
> hood of solving those in MARTINI as we have of solving the 
> "preservation of request-URI across contact routing" problem. 
> 
> --
> Dean
> 
> 
> 
> 
> 
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 10 Mar 2010 09:51:57 +0100

John,

While the solution has some optical similarities we did NOT adopt the UA
loose route draft solution in TISPAN. We used the loose route mechanism as
provided by RFC3261. For trunking subscriptions the home proxy would just
execute a slightly different routing policy then for normal UE's.

Best Regards,
/Hans Erik van Elburg

On Wed, Mar 10, 2010 at 9:45 AM, Elwell, John <
[email-masked]> wrote:

> Bruno,
>
> I recall from the TISPAN business trunking discussions a couple of years
> ago that we tried to preserve the contents of the Request-URI, based on
> principles proposed in the Rosenberg loose route draft, which was under
> consideration at the IETF at the time and which we thought had a strong
> possibility of being adopted. Unfortunately (I can't recall the precise
> reasons, but backwards compatibility played a large part), the IETF decided
> not to go in that direction. Therefore it would be an uphill struggle to get
> the IETF to agree to adopt a similar principle now, in the context of the
> MARTINI work.
>
> John
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 10 Mar 2010 10:21:27 +0100

Given the ambitionlevel to only provide a solution for the specific E.164
cases,  why is this drafts intended status "Standards Track"?

Being first made aware of this work group yesterday, surprised to see that a
new solution is developed, whereas there exists a standardised solution for
over a year now supporting any target SIP URI (not limited to E.164) alone
and that can easily be modified/adapted/rephrased to work in a more
generalised internet setting.

BR,
/Hans Erik van Elburg

On Tue, Mar 9, 2010 at 8:01 PM, <[email-masked]> wrote:

> Strictly speaking it's not a new interface but in practice it means that a
> PBX will find different things in the Request URI of inbound requests
> depending on whether it is connected  to an IMS or a GIN-based network. In
> the first case, the R-URI will contain the original target identity while in
> the second case it will contain this special contact address built as
> described in the GIN draft.
>
> For the rest of my message, there was a typo in it! I intended to write
> that it was too early to accept this document as a WG Work Item but wrote
> WGLC...
>
> If I try to map what I meant to your 4 options, I believe I meant Option 1:
> I don't like the GIN mechanism in its present form as it does not preserve
> the original target identity in the R-URI and is restricted to E.164
> numbers. However, what you have described as Option 2a is worth discussing.
> The definition of the <subset of the "registering multiple domain-style URIs
> in a single request" problem that can be dealt with using REGISTER> would
> also deserve further discussions. If it turns out that the gin draft can be
> extended to support a reasonable subset of the problem then it might become
> a better candidate for a WG Work Item. This does not solve the R-URI issue
> however.
>
> /BC
>
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Mar 2010 11:10:57 -0600

On 3/10/10 3:21 AM, Hans Erik van Elburg wrote:
> Being first made aware of this work group yesterday, surprised to see 
> that a new solution is developed, whereas there exists a standardised 
> solution for over a year now supporting any target SIP URI (not 
> limited to E.164) alone and that can easily be 
> modified/adapted/rephrased to work in a more generalised internet setting.

There has been quite a bit of discussion on the MARTINI mailing list 
since the beginning of the year. Most of it focused on what many of us 
believe are fundamental flaws in the existing approaches. If you really 
want to understand how we got where we are, I suggest you familiarize 
yourself with the discussion to date:

http://www.ietf.org/mail-archive/web/martini/current/mail2.html

The minutes of the three interim meetings we've had this year are also 
good background for the state of things:

http://aboba.drizzlehosting.com/MARTINI/

I don't think any of us are particularly eager to go back to arguing 
over the problems inherent in the currently deployed solutions: many 
participants would like to have something in front of the IESG in the 
first half of 2010, not sometime in late 2013.

/a

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 11 Mar 2010 10:10:35 -0600

Bernard Aboba wrote:

> message whether you think the document is ready for adoption as a

I am in favor of this document being adopted as a WG item as-is.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: "Brian Lindsay" <[email-masked]>
Date: Wed, 17 Mar 2010 09:51:19 -0400

Hi Bernard,
 
   I think the gin draft could form the basis of a solution, but at as
couple of other folks have noted there already is a solution
standardized by TIPAN/3GPP which uses a different approach for request
routing for SIP PBXs. It would be ideal if we had one common approach in
the industry, otherwise we are going to see some carriers require one
solution and other carriers the other solution and vendors on both the
enterprise and carrier side will need to implement and support both.
 
   The shaken draft is closer to the TISPAN/3GPP approach and is
essentially adding some incremental improvements. I'd be more inclined
to go with the shaken appoach at this time given it's alignment with the
existing standardized TISPAN/3GPP solution.
 
   I haven't heard too many other responses on the call for adoption
from SSP vendors so I'm curious on that front what others are thinking.
 
   Thanks
       Brian

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bernard Aboba
Sent: Thursday, March 04, 2010 5:02 PM
To: 'MARTINI'
Subject: [martini] Call for Adoption of "Registration for Multiple
PhoneNumbers in the SIP"

This is a MARTINI WG Call for Adoption of "Registration for Multiple
Phone Numbers in the SIP" as a MARTINI WG work item, corresponding to
the "Multiple AoR Registration specification" Charter deliverable.  The
document is available for inspection here: 

1.      The preferred choice is to open an issue in the MARTINI Issue
tracking database (TRAC), which is available here:
http://trac.tools.ietf.org/wg/martini/trac/newticket
<http://trac.tools.ietf.org/wg/martini/trac/newticket>   Information on
how to use TRAC is provided below.  Note that if you submit an issue in
TRAC, it will automatically also be posted to the MARTINI WG mailing
list.  When submitting issues in TRAC for this "call for adoption",
please enter "gin" for the Component: and "Candidate WG Document" for
Severity.  

 2. If you can't figure out how to use TRAC, please post your Issue to
the MARTINI WG mailing list (martini at ietf.org) in the following
format: 

To:  martini at ietf.org

on the "login" entry at the top of the page.  Once you have logged in,

4     When opening an issue: 

b.      The Priority: field is set based on the severity of the Issue.
For example, editorial issues are typically "minor" or "trivial". 

d.      The Component: field should be set to the document you are
filing the issue on.  In responding to the GIN Call for Adoption, "gin"
is the appropriate choice.

f.        The Severity: field should be set to based on the status of
the document (e.g. "Candidate WG Document" in this case)

5.       Typically it won't be necessary to enclose a file with the
ticket, but if you need to, select "I have files to attach to this
ticket". 

6.       If you want to preview your Issue, click on the "Preview"
button.  When you're ready to submit the issue, click on the "Create
Ticket" button. 

That's it!  

If you have an problems in dealing with TRAC, send email to me and I'll
try to figure out what's going on. 

Happy TRACing,

Bernard

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 Mar 2010 17:02:01 -0500

> The MARTINI WG Call for Adoption will last until Friday, March 19, 2010.

I'm in favor of adoption.

---

From: <[email-masked]>
Date: Thu, 18 Mar 2010 09:06:20 +0100

Hi,

As service provider I completely agree with the statement that a common approach is beneficial for the industry. Therefore I would prefer that alignment with existing specifications of 3GPP/ETSI is sought as much as possible.

Kind regards

Jan Van Geel
IT and Network Development Specialist
Belgacom SDE/SDV/PSE/NST/NCP
Tel: +32 2 202 1035
Tel: +32 2 207 4442
Tel: +32 2 207 9032
Email : [email-masked]
www.cyberwezz.tk

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Lindsay
Sent: 17 March 2010 14:51
To: Bernard Aboba; MARTINI
Subject: Re: [martini] Call for Adoption of "Registration for Multiple PhoneNumbers in the SIP"

Hi Bernard,

   I think the gin draft could form the basis of a solution, but at as couple of other folks have noted there already is a solution standardized by TIPAN/3GPP which uses a different approach for request routing for SIP PBXs. It would be ideal if we had one common approach in the industry, otherwise we are going to see some carriers require one solution and other carriers the other solution and vendors on both the enterprise and carrier side will need to implement and support both.

   The shaken draft is closer to the TISPAN/3GPP approach and is essentially adding some incremental improvements. I'd be more inclined to go with the shaken appoach at this time given it's alignment with the existing standardized TISPAN/3GPP solution.

   I haven't heard too many other responses on the call for adoption from SSP vendors so I'm curious on that front what others are thinking.

   Thanks
       Brian

Subject: [martini] Call for Adoption of "Registration for Multiple PhoneNumbers in the SIP"

4     When opening an issue:

**** DISCLAIMER ****
http://www.belgacom.be/maildisclaimer

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 18 Mar 2010 18:42:21 +0100

+1

Allowing both UC-3 and UC-6/9 scenarios could be a way forward, use cases or
scenarios as depicted in:
http://aboba.drizzlehosting.com/MARTINI/Jan-Interim-III/IETF77_MARTINI_Feb9Interim_Use_models.pdf

PBX configurations that are fine with the limitations or limited themselves
can register and indicate they are expecting UC-3 style.
PBX configurations that need more advanced setups can register and indicate
they are expecting UC-6/9 style.

BR,
/Hans Erik van Elburg

On Thu, Mar 18, 2010 at 9:06 AM, <[email-masked]> wrote:

>  Hi,
>
>
>
> As service provider I completely agree with the statement that a common
> approach is beneficial for the industry. Therefore I would prefer that
> alignment with existing specifications of 3GPP/ETSI is sought as much as
> possible.
>
>
>
> Kind regards
>
>
>
>
>
> *Jan Van Geel*
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Brian Lindsay
> *Sent:* 17 March 2010 14:51
> *To:* Bernard Aboba; MARTINI
> *Subject:* Re: [martini] Call for Adoption of "Registration for Multiple
> PhoneNumbers in the SIP"
>
>
>
> Hi Bernard,
>
>
>
> couple of other folks have noted there already is a solution standardized by
> TIPAN/3GPP which uses a different approach for request routing for SIP PBXs.
> It would be ideal if we had one common approach in the industry, otherwise
> we are going to see some carriers require one solution and other carriers
> the other solution and vendors on both the enterprise and carrier side will
> need to implement and support both.
>
>
>
> essentially adding some incremental improvements. I'd be more inclined to go
> with the shaken appoach at this time given it's alignment with the existing
> standardized TISPAN/3GPP solution.
>
>
>
>    I haven't heard too many other responses on the call for adoption from
> SSP vendors so I'm curious on that front what others are thinking.
>
>
>
>    Thanks
>
>        Brian
>
>
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Bernard Aboba
> *Sent:* Thursday, March 04, 2010 5:02 PM
> *To:* 'MARTINI'
> *Subject:* [martini] Call for Adoption of "Registration for Multiple
> PhoneNumbers in the SIP"
>
> http://trac.tools.ietf.org/wg/martini/trac/newticket  Information on how
> to use TRAC is provided below.  Note that if you submit an issue in TRAC, it
> you first need to login to the MARTINI WG site on the tools server (
> http://tools.ietf.org/wg/martini/trac/login )
>
> For example, editorial issues are typically “minor” or “trivial”.
>
> **** DISCLAIMER ****http://www.belgacom.be/maildisclaimer
>
>

---

From: <[email-masked]>
Date: Fri, 19 Mar 2010 08:35:56 +0100

Hans Erik, all,

Maybe I misunderstand (some of) the use cases, but to me UC3 looks like a PBX using a group REGISTER, as described in 3GPP/ETSI documents. The Conclusion of this discussion document seems to indicate that this is the solution with the lesser drawbacks, right ?

Kind regards

Jan Van Geel

From: Hans Erik van Elburg [mailto:[email-masked]]
Sent: 18 March 2010 18:42
To: VAN GEEL Jan (ITN/NIS)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [martini] Call for Adoption of "Registration for Multiple PhoneNumbers in the SIP"

+1

Allowing both UC-3 and UC-6/9 scenarios could be a way forward, use cases or scenarios as depicted in:
http://aboba.drizzlehosting.com/MARTINI/Jan-Interim-III/IETF77_MARTINI_Feb9Interim_Use_models.pdf

PBX configurations that are fine with the limitations or limited themselves can register and indicate they are expecting UC-3 style.
PBX configurations that need more advanced setups can register and indicate they are expecting UC-6/9 style.

BR,
/Hans Erik van Elburg
On Thu, Mar 18, 2010 at 9:06 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Kind regards

Jan Van Geel
IT and Network Development Specialist
Belgacom SDE/SDV/PSE/NST/NCP
Tel: +32 2 202 1035
Tel: +32 2 207 4442
Tel: +32 2 207 9032
Email : [email-masked]<mailto:[email-masked]>
www.cyberwezz.tk<http://www.cyberwezz.tk>

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian Lindsay
Sent: 17 March 2010 14:51
To: Bernard Aboba; MARTINI
Subject: Re: [martini] Call for Adoption of "Registration for Multiple PhoneNumbers in the SIP"

Hi Bernard,

   Thanks
       Brian

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bernard Aboba

 2. If you can't figure out how to use TRAC, please post your Issue to the MARTINI WG mailing list (martini at ietf.org<http://ietf.org>) in the following format:
To:  martini at ietf.org<http://ietf.org>

4     When opening an issue:

**** DISCLAIMER ****

_______________________________________________
martini mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/martini

**** DISCLAIMER ****

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 19 Mar 2010 09:39:46 +0100

Yes these scenarios are based on implicit registration.

BR,
/Hans Erik van Elburg

On Fri, Mar 19, 2010 at 8:35 AM, <[email-masked]> wrote:

>  Hans Erik, all,
>
>
>
> Maybe I misunderstand (some of) the use cases, but to me UC3 looks like a
> PBX using a group REGISTER, as described in 3GPP/ETSI documents. The
> Conclusion of this discussion document seems to indicate that this is the
> solution with the lesser drawbacks, right ?
>
>
>
> Kind regards
>
>
>
>
>
> *Jan Van Geel*
> *From:* Hans Erik van Elburg [mailto:[email-masked]]
> *Sent:* 18 March 2010 18:42
> *To:* VAN GEEL Jan (ITN/NIS)
> *Cc:* [email-masked]; [email-masked]; [email-masked]
>