Subject: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP"

From: Bernard Aboba <[email-masked]>
Date: Tue, 6 Jul 2010 22:56:55 -0700

This is an announcement of MARTINI WG last call on "Registration for Multiple Phone Numbers in the SIP" prior to requesting that the IESG publish the document as a Proposed Standard. 

The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-05.txt

MARTINI WG last call will conclude on Thursday, July 22, 2010. 

Please respond to this WG last call, whether you 
have
comments 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 consideration by 
the IESG or
not. 

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

1. If you have an account on the IETF Tools server,
 or can
open one, please login and enter your issue(s) in the 

MARTINI Issue tracking database (TRAC), which is 
available
here:

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

Note that if you submit an issue in TRAC, it will
automatically also be posted to the MARTINI WG mailing list. 

2. If you don't have an account on the IETF Tools 
server,
please post your

Issue to the MARTINI WG mailing list (martini at 
ietf.org) in
the following format: 

To:  martini at ietf.org

Subject: Requirements-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>

---

From: Adam Roach <[email-masked]>
Date: Wed, 07 Jul 2010 09:13:08 -0500

On 7/7/10 00:56, Jul 7, Bernard Aboba wrote:
>
> If you have comments, please provide them to the WG in one of the 
> following ways...
>

As an addendum to this -- due to time constraints, I was not able to 
perform my normal proofreading step before submitting the document. 
There are likely to be typographical errors in the new text. I would 
request that any errors you find that do not impact the technical 
meaning of the document are sent directly to me for correction, rather 
than opening a tracker ticket on them.

Of course, any text that is ambiguous or incorrect from a *technical* 
viewpoint should have a ticket opened.

/a

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 7 Jul 2010 11:11:11 -0400

+1 for IESG submission. This is baked and ready.

 And thank you Adam for a excellent job ..

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bernard Aboba
Sent: Wednesday, July 07, 2010 1:57 AM
To: [email-masked]
Subject: [martini] Announcement of MARTINI WG last Call on "Registration for
Multiple Phone Numbers in the SIP"

This is an announcement of MARTINI WG last call on "Registration for
Multiple Phone Numbers in the SIP" prior to requesting that the IESG publish
the document as a Proposed Standard. 

Please respond to this WG last call, whether you have comments 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 consideration by the IESG or not. 

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

1. If you have an account on the IETF Tools server, or can open one, please
login and enter your issue(s) in the 

MARTINI Issue tracking database (TRAC), which is available here:

Note that if you submit an issue in TRAC, it will automatically also be
posted to the MARTINI WG mailing list. 

2. If you don't have an account on the IETF Tools server, please post your

Issue to the MARTINI WG mailing list (martini at ietf.org) in the following
format: 

To:  martini at ietf.org

Subject: Requirements-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>

---

From: "Jack Burton" <[email-masked]>
Date: Thu, 08 Jul 2010 11:19:12 -0400

+1  (Ready for Consideration)
Jack Burton
 
Jack Burton
Dir. Systems Engineering
Cablevision
[email-masked] 
516-803-9733 

>>> Bernard Aboba <[email-masked]> 7/7/2010 01:56 >>>

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 consideration by the IESG or not. 

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

1. If you have an account on the IETF Tools server, or can open one, please login and enter your issue(s) in the 
MARTINI Issue tracking database (TRAC), which is available here:
http://trac.tools.ietf.org/wg/martini/trac/newticket 

Note that if you submit an issue in TRAC, it will automatically also be posted to the MARTINI WG mailing list. 

2. If you don't have an account on the IETF Tools server, please post your
Issue to the MARTINI WG mailing list (martini at ietf.org) in the following format: 

To:  martini at ietf.org
Subject: Requirements-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 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: "Elwell, John" <[email-masked]>
Date: Mon, 12 Jul 2010 11:25:11 +0200

I have reviewed this document and it is ready to go, apart from the following minor issues and nits that should be corrected.

1. "A registrar that receives a Contact URI with both a "bnc" parameter
   and a user portion MUST either discard the user portion and process
   the request as if the parameter were not present or ..."
It doesn't make sense. If the parameter were not present, one would expect a user portion to be present. I think this should say :
"A registrar that receives a Contact URI with both a "bnc" parameter
   and a user portion MUST either discard the user portion and process
   the request as if the user portion were not present or ..."
                         ^^^^^^^^^^^^

2. "Currently, the descriptions are somewhat informal, and omit some
   details for the sake of brevity.  If the MARTINI working group
   expresses interest in furthering the mechanism described by this
   document, they will be fleshed out with more detail and formality."
This seems to be historic and should be deleted.

3. "   When a UA registers with the SIP-PBX using GRUU procedures for a
   Contact, the SIP-PBX adds an "sg" parameter to the GRUU parameter it
   received from the SSP.  This "sg" parameter contains a disambiguation
   token that the SIP-PBX can use to route the request to the proper
   user agent."
This isn't terribly clear. Rewording as follows might help:
"When a UA registers a contact with the SIP-PBX using GRUU procedures, the SIP-PBX provides to the UA a public GRUU formed by adding an "sg" parameter to the GRUU parameter it received from the SSP.  This "sg" parameter contains a disambiguation token that the SIP-PBX can use to route inbound requests to the proper UA."

4. "The SSP registrar then maps I_i to the "bnc" AOR template and
      instance ID using the database, a persistent hash-map or similar
      technology."
This is the first use of the expression "AOR template and instance ID". We could do with some clarification, but I don't have a proposal. We have something that could be described as a template, but I would have considered that to be a contact template rather than an AOR template.

5. "(1) The SIP-PBX registers with the SSP for a range of AORs.
       It includes the URI it expects to receive in the Request-URI
       in its "Contact" header field, and includes information that
       routes to the SIP-PBX in the "Path" header field."
I think "the URI" should be changed to "the domain". Only the domain part of the REGISTER request's Contact header field will appear in the Request-URI of the inbound request.

Nits:
N1. "in the same way that
   is would " 
Change "is" to "it".

N2. "then the resulting registration
   information documents SHOULD contain an 'aor' attribute in its
   <registration/> element"
Change "documents" to "document", or alternatively add "each" after "SHOULD".

N3. "for all the potentially
   effected users"
Change "effected" to "affected".

N4. "The ability to learn the identity and registration state of every use
   on the PBX "
Change "use" to "user".

N5. "These are being defined in
   the MARTINI requirements document [8]."
Delete "being".

N6.  "   Further, the term "SSP" is meant as an acronym for a "SIP Service
   Provider," while "
Move the comma outside the quotes.

N7. Perhaps it is a matter of taste (ignore if you wish), but there are several places where we talk about REGISTER message or just REGISTER when we perhaps mean REGISTER request.

N8. Again a mater of taste, but in several places the word "multitude" is used, which suggests the number is always very large. Perhaps "multiplicity" might be better.

N9. "   that User Agents services by the SIP-PBX can acquire and use GRUUs
   for their own use."
Change "services" to "serviced".

N10. "sent the following Contact header field
   in its register"
Change "register" to "REGISTER request".

N11. "When the
      SSP registrar creates the first temporary GRUU for a particular
      SIP-PBX and instance ID..."
This is the first time "instance ID" has been mentioned - should we have a reference to RFC 5627 at this point?

N12. "temp-gruu-cookie = base64enc(I_i || SA)"
We should add "where || denotes concatenation." (the same as in 7.1.2.2)

N13: "This allows the SSP to
   designate a domain on the incoming Request URI that does not
   necessarily resolve to the SIP-PBX from when the SSP applies RFC 3263
   procedures to it."
I think the word "from" should be deleted.

N14: "This document registers a new SIP option tag to indicate support for
   the mechanism it defines, plus two new SIP URI parameters."
We should also mention the new header field parameter defined in 9.3.

N15: "more than on AOR"
Chance "on" to "one".

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: 07 July 2010 06:57
> To: [email-masked]
> Subject: [martini] Announcement of MARTINI WG last Call on 
> "Registration for Multiple Phone Numbers in the SIP"
> 
> This is an announcement of MARTINI WG last call on 
> "Registration for Multiple Phone Numbers in the SIP" prior to 
> requesting that the IESG publish the document as a Proposed Standard. 
> 
> If you have no comments, please reply to this message and 
> 1. If you have an account on the IETF Tools server, or can

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Jul 2010 11:37:07 -0400

Howdy,
I've reviewed the latest gin draft and think it is ready for consideration by the IESG, if the following changes/comments are made/addressed (these will also be added in the tools database):

1) Section 5.2 says:
   A registrar that receives a Contact URI with both a "bnc" parameter
   and a user portion MUST either discard the user portion and process
   the request as if the parameter were not present or return a 400 (Bad
   Request) error in response (unless some other error code is more
   appropriate).

   Section 5.3 says:
   When a SIP-PBX registers with an SSP using a "bnc" contact, that
   contact MUST NOT include a "user" parameter.  An SSP registrar that
   receives a Contact URI with both a "bnc" parameter and a "user"
   parameter MUST either discard the "user" parameter and process the
   request as if the parameter were not present or return a 400 (Bad
   Request) error in response (unless some other error code is more
   appropriate).

I think we need to pick one and only one behavior - having some Registrars accept these and others not leads to inconsistent interoperability among vendor equipment.  Since at some future time we may find a need for the user portion, but will probably want backwards-compatibility without failure at that time, I recommend for 5.2 we stipulate a Registrar compliant to this draft MUST discard and ignore the user portion and process the request as if the user portion were not present; and for 5.3 the same for a "user" param.  This would also follow the mantra of strict on send, liberal on receipt.

2) Section 7 says:
   Currently, the descriptions are somewhat informal, and omit some
   details for the sake of brevity.  If the MARTINI working group
   expresses interest in furthering the mechanism described by this
   document, they will be fleshed out with more detail and formality.

Since this document is being sent to IESG, presumably this paragraph no longer applies and should be removed.

3) Section 7.1 says:
   ... with the mechanism defined by this document -- that is,
   that User Agents services by the SIP-PBX can acquire and use GRUUs
   for their own use.

It should be "-- that is, that User Agents serviced ..."

4) Section 7.1.1 says:
   When an incoming request arrives at the SSP for a GRUU corresponding
   to a bulk number contact ("bnc"), the SSP performs slightly different
   processing for the GRUU than a Proxy/Registrar would.

The end of that sentence should be "... for that GRUU than it would for non-bnc GRUUs."  (or at least not say "than a Proxy/Registrar would")

5) Section 7.2.1 says:
   In particular, the "bnc" parameter is forbidden from appearing in the
   body of a reg-event notify.

Something about that statement rings warning bells in my head.  I don't know what that something is, but it seems wrong to me. :)  Are we absolutely sure this is a normative statement we want, forever?

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 16 Jul 2010 19:28:12 +0200

> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 16 July 2010 16:37
> To: Bernard Aboba; [email-masked]
> Subject: Re: [martini] Announcement of MARTINI WG last Call 
> on "Registration for Multiple Phone Numbers in the SIP"
> 
> 
> Howdy,
> I've reviewed the latest gin draft and think it is ready for 
> consideration by the IESG, if the following changes/comments 
> are made/addressed (these will also be added in the tools database):
> 
> 1) Section 5.2 says:
> I think we need to pick one and only one behavior - having 
> some Registrars accept these and others not leads to 
> inconsistent interoperability among vendor equipment.  Since 
> at some future time we may find a need for the user portion, 
> but will probably want backwards-compatibility without 
> failure at that time, I recommend for 5.2 we stipulate a 
> Registrar compliant to this draft MUST discard and ignore the 
> user portion and process the request as if the user portion 
> were not present; and for 5.3 the same for a "user" param.  
> This would also follow the mantra of strict on send, liberal 
> on receipt.
[JRE] Sounds reasonable to me.

John

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 18 Jul 2010 10:02:23 -0700

Looks like a fully formed sausage - I like it. Two issues when I skimmed it. 

The support for temp gruus seems to be optional. I think it should be mandatory to implement. The exact deployment models where we want to use this are the places where many people believe there is a legal requirement to support anonymous calls and implementing this put us into the situation where there are pretty much no alternatives way to do it. 

Please change "must" to "MUST" in section 5.1 
   First, it must contain an option tag of "gin" in
   both a "Require" header field and a "Proxy-Require" header field.
You might want to consider "must" in the next sentence too. 

Cullen

PS - Thank you to Richard for pointing out this to me - I had missed it because I filter on WGLC on the subject lines.

---

From: Brian Lindsay <[email-masked]>
Date: Mon, 19 Jul 2010 13:26:40 +0000

Hi,

   I'd disagree with making temp gruu's mandatory to implement in this draft. Some SSP's may have architectures/privacy functions that would not require this to support anonimity (e.g. using B2BUA's). I'd prefer to keep the text as is for temp-gruu's.

Thanks,
Brian

-------------
Brian Lindsay
Sr. Architect, System Architecture
GENBAND
Office: +1.613.763.3459	
www.genband.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen Jennings
Sent: Sunday, July 18, 2010 1:02 PM
To: [email-masked]
Subject: [martini] WGLC comments on draft-ietf-martini-gin

Cullen

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Jul 2010 10:57:01 -0400

IMO the optionality of GRUUs, and of temp gruus, was always a dicy thing.

The question is what the client is to do if it has functionality that 
requires GRUU but GRUU isn't supported by the registrar?

In the current context, I think this might come down to confidentiality 
features in the PBX. It (or the phones it serves) is likely to be 
designed to use temp-gruu to implement those features, since for it 
there aren't a lot of alternatives. So if in a particular deployment the 
SSP registrar doesn't support temp-gruus, what is the pbx/phone to do 
about those features? I think about all it can do is disable them - 
eliminating possibility of anonymous calls.

Now it may be that the SSP has some alternative mechanism for anonymity. 
But how will the PBX know to use that? Also, such a mechanism wouldn't 
support anonymity on calls within the PBX.

Maybe that is as it must be. But I think we must consider this carefully 
before deciding.

	Thanks,
	Paul

---

From: Brian Lindsay <[email-masked]>
Date: Mon, 19 Jul 2010 17:00:52 +0000

Hi Paul,

   Perhaps to add to your first point, I think temporary GRUUs aren't even mandatory to implement in RFC 5627?

   I think the draft currently has the right balance: it defines how GRUUs/Temp-GRUUs work with the "gin" registration mechanism (and defines the necessary extensions for this), but doesn't mandate them. Mandating/coupling argueably goes beyond the scope of the MARTINI requirements. Temp-GRUUs by themselves also aren't necessarily sufficient for full anonymity (e.g. SDP info could be used for correlation) and it hasn't been in the scope of the work to mandate a full solution for anonymity. 

   In the absence of availability a temp-gruu - presumeably the PBX would have to anonymize the request to the extent possible and the network may provide additional privacy capabilities of course (e.g. RFC3323/3325).

Thanks,
Brian

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, July 19, 2010 10:57 AM
To: Brian Lindsay
Cc: Cullen Jennings; [email-masked]
Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin

The question is what the client is to do if it has functionality that requires GRUU but GRUU isn't supported by the registrar?

In the current context, I think this might come down to confidentiality features in the PBX. It (or the phones it serves) is likely to be designed to use temp-gruu to implement those features, since for it there aren't a lot of alternatives. So if in a particular deployment the SSP registrar doesn't support temp-gruus, what is the pbx/phone to do about those features? I think about all it can do is disable them - eliminating possibility of anonymous calls.

Now it may be that the SSP has some alternative mechanism for anonymity. 
But how will the PBX know to use that? Also, such a mechanism wouldn't support anonymity on calls within the PBX.

Maybe that is as it must be. But I think we must consider this carefully before deciding.

	Thanks,
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 19 Jul 2010 11:30:21 -0700

Well - the first question is if we agree that non temp GRUUs are mandatory to implement on the SSP side?  If we don't agree on this we are not going to get far on the temp conversation. 

> >    I'd disagree with making temp gruu's mandatory to implement in this draft. Some SSP's may have architectures/privacy functions that would not require this to support anonimity (e.g. using B2BU…

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Adam Roach <[email-masked]>
Date: Mon, 19 Jul 2010 15:04:35 -0500

In general, I agree that all these nits are in need of fixing, save one:

> Move the comma outside the quotes.

This is a matter of U.S. versus U.K. English. In the U.S., punctuation 
always goes inside quotes according to most style guides (cf. Chicago 
Manual of Style, section 6.8). The lore around this dates back to 
typographical convention: apparently, the tiny dies that held commas and 
periods tended to be knocked out of position easily -- a problem that 
could be solved by wedging them between a letter and a quotation mark.

For more detail, see 
http://en.wikipedia.org/wiki/Quotation_mark#Typographical_considerations

/a

---

From: Brian Lindsay <[email-masked]>
Date: Mon, 19 Jul 2010 20:10:00 +0000

Hi,

  My preferance is to keep the text in the draft "as is" for GRUUs in general: describe how the GRUU mechanism works with gin, but don't couple/require that a gin registration implementation must implement the GRUU mechanism.

  Regards
     Brian

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Monday, July 19, 2010 2:30 PM
To: Brian Lindsay
Cc: Paul Kyzivat (pkyzivat); [email-masked]
Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin

Cullen Jennings

---

From: Adam Roach <[email-masked]>
Date: Mon, 19 Jul 2010 15:24:50 -0500

>     the request as if the user portion were not present or ..."

Agreed.

> This seems to be historic and should be deleted.

Agreed.

> "When a UA registers a contact with the SIP-PBX using GRUU procedures, the SIP-PBX provides to the UA a public GRUU formed by adding an "sg" parameter to the GRUU parameter it received from the SSP…

I like the rewording.

> This is the first use of the expression "AOR template and instance ID". We could do with some clarification, but I don't have a proposal. We have something that could be described as a template, bu…

I propose "...maps I_i to the contact and instance ID using the 
database...."

> I think "the URI" should be changed to "the domain". Only the domain part of the REGISTER request's Contact header field will appear in the Request-URI of the inbound request.

But it's not really just the domain -- it can have parameters. Perhaps 
'It indicates the form of the URI it expects to receive in the 
Request-URI in its "Contact" header field....'

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Jul 2010 18:22:52 -0400

>    Perhaps to add to your first point, I think temporary GRUUs aren't even mandatory to implement in RFC 5627?

Neither kind is mandatory to implement.

>    In the absence of availability a temp-gruu - presumeably the PBX would have to anonymize the request to the extent possible and the network may provide additional privacy capabilities of course…

If the PBX can provide an acceptable anonymity service without temp 
gruu, then it won't ever need it. (It seems dubious that it would offer 
the same service at two levels of anonymity.)

This is the same problem that a plain sip phone has depending on whether 
the registrar supports gruu. But PBXs are typically expected to offer a 
higher level of service.

Still, I'm ambivalent about this.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 19 Jul 2010 18:22:57 -0500

> Something about that statement rings warning bells in my head.  I don't know what that something is, but it seems wrong to me. :)  Are we absolutely sure this is a normative statement we want, fore…

The logic here is that subscribers to the event package won't 
necessarily know about the GIN extension. If you send them a "bnc" URI, 
they're going to have no clue that it's not just a normal URI.

Now, I don't think this prohibition is a "forever" thing. There's 
certainly nothing that says that another extension (say, VERMOUTH) is 
prohibited from overriding this prohibition with another behavior -- so 
long as the subscriber indicates that it would know what to do with a 
"bnc" URI.

Would the following change address your concern?

    In particular, the "bnc" parameter is forbidden from appearing in the
    body of a reg-event notify unless the subscriber has indicated
    knowledge of the semantics of the "bnc" parameter. The means
    for indicating this support are out of scope of this document.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 20 Jul 2010 08:27:52 +0200

> > This is the first use of the expression "AOR template and 
> instance ID". We could do with some clarification, but I 
> don't have a proposal. We have something that could be 
> described as a template, but I would have considered that to 
> be a contact template rather than an AOR template.
> >
> 
[JRE] OK. Don't forget there are two more instances of "AOR template" that need fixing.

> > I think "the URI" should be changed to "the domain". Only 
> the domain part of the REGISTER request's Contact header 
> field will appear in the Request-URI of the inbound request.
> 
[JRE] That would be better.

John

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Jul 2010 14:49:53 -0400

Hi Adam,
Yes the changed text sounds good - thanks!
-hadriel

> From: Adam Roach [mailto:[email-masked]]
> Sent: Monday, July 19, 2010 7:23 PM
> To: Hadriel Kaplan
> Cc: Bernard Aboba; [email-masked]
> Subject: Re: [martini] Announcement of MARTINI WG last Call on
> > Something about that statement rings warning bells in my head.  I don't
> know what that something is, but it seems wrong to me. :)  Are we
> absolutely sure this is a normative statement we want, forever?
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 20 Jul 2010 01:27:52 -0500

WARNING: contains banned part

Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP"
From: "Elwell, John" <[email-masked]>
To: "Adam Roach" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Date: Tue, 20 Jul 2010 01:27:52 -0500

John

---

From: David Hancock <[email-masked]>
Date: Wed, 21 Jul 2010 17:51:04 -0600

I've reviewed the document and think it is ready for consideration, pending resolution of the issues described below.

These issues all have to do with subscribing to reg-event.

--------------------------------------------------------------
Issue-1:
Section 7.7.2 says...
   If the SSP receives a SUBSCRIBE request for the registration event
   package with a Request-URI that indicates a contact registered via
   the "Bulk Number Contact" mechanism defined in this document, then
   the SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the same way that
   is would proxy an INVITE bound for that AOR, unless the SSP has and
   can maintain a copy of complete, accurate, and up-to-date information
   from the SIP-PBX (e.g., through an active back-end subscription).

How does the SSP handle the SUBSCRIBE to reg-event for an enterprise user when the SIP-PBX isn't registered? My understanding of RFC3680 is that if the target user of a reg-event SUBSCRIBE isn't registered, then the reg-event subscriber receives a NOTIFY indicating "user not registered". The subscribe dialog remains active, and if/when the target user subsequently registers, the reg-event subscriber receives another NOTIFY containing the registration data. Would this same process be followed when the reg-event subscription is to an AOR owned by the SIP-PBX, and if yes, how does the SSP make that happen?

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

Issue-2: How does a SIP-PBX that doesn't have SIP endpoints respond to a SUBSCRIBE to reg-event (say, SIP-PBX supports only analog or H.323 lines)? I assume it should create fake registration data is if the target AOR were registered to a SIP endpoint. Does that need to be stated?

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

Issue-3:
Section 5.2 says...
   A further implication of this property is that an individual extension
   that is implicitly registered may also be explicitly registered using
   a normal, non-bulk registration (subject to SSP policy).  If such a
   registration exists, it is refreshed independently of the bulk
   registration, and is not removed when the bulk registration is
   removed.

I assume this means that an enterprise user AOR can be bound to two (multiple) contact addresses; one bulk-registered by the PBX, and a second explicitly registered by a SIP endpoint directly hosted by the SSP network. 

Section 6 of the draft goes on to say that SUBSCRIBE requests to reg-event are handled just like INVITE requests, which means that if the target AOR has multiple contacts, the SUBSCRIBE request is forked. This seems like a problem, since RFC3680 disallows forking (RFC3680 section 4.9).

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

I didn't see these particular issues discussed in the MARTINI archive. I apologize if they have in fact been discussed & resolved.

Thanks
David 

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Tuesday, July 06, 2010 11:57 PM
To: [email-masked]
Subject: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP"

 

 

 
To:  martini at ietf.org

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 22 Jul 2010 09:27:10 +0200

> [mailto:[email-masked]] On Behalf Of David Hancock
> Sent: 22 July 2010 00:51
> I've reviewed the document and think it is ready for 
> consideration, pending resolution of the issues described below.
> 
> How does the SSP handle the SUBSCRIBE to reg-event for an 
> enterprise user when the SIP-PBX isn't registered? My 
> understanding of RFC3680 is that if the target user of a 
> reg-event SUBSCRIBE isn't registered, then the reg-event 
> subscriber receives a NOTIFY indicating "user not 
> registered". The subscribe dialog remains active, and if/when 
> the target user subsequently registers, the reg-event 
> subscriber receives another NOTIFY containing the 
> registration data. Would this same process be followed when 
> the reg-event subscription is to an AOR owned by the SIP-PBX, 
> and if yes, how does the SSP make that happen?
[JRE] Wouldn't the SSP return a 480 response to the SUBSCRIBE request if it can't deliver it?

John

---

From: Doug Sauder <[email-masked]>
Date: Thu, 22 Jul 2010 08:33:09 -0500

I read the document and I want to voice my opinion that the document 
should be submitted to the IESG.

--
Doug Sauder

Bernard Aboba wrote:
> Multiple Phone Numbers in the SIP" prior to requesting that the IESG 
> publish the document as a Proposed Standard.
>
> following ways:
> 1. If you have an account on the IETF Tools server, or can open one, 
> please login and enter your issue(s) in the
>
> Note that if you submit an issue in TRAC, it will automatically also 
> be posted to the MARTINI WG mailing list.
>
>  
>
> ------------------------------------------------------------------------
>

---

From: David Hancock <[email-masked]>
Date: Thu, 22 Jul 2010 08:02:33 -0600

________________________________________
From: Elwell, John [[email-masked]]
Sent: Thursday, July 22, 2010 1:27 AM
To: David Hancock; Bernard Aboba; [email-masked]
Subject: RE: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP"

[dch] Yes, that would be one way to handle it, although not so friendly to the reg-event subscriber. Since for "normal" registrations the SSP registrar/proxy doesn't send a 480 response when the target user isn't registered, it might be useful if the draft covered this case. 

If we take this approach where the SSP treats these SUBSCRIBEs like any request to be delivered to the SIP-PBX, then what happens to reg-event subscriptions to the SIP-PBX when the PBX transitions from registered to not-registered? Would they simply expire?

Thanks
David

John

---

From: "Horvath, Ernst" <[email-masked]>
Date: Thu, 22 Jul 2010 17:35:27 +0200

Adam,

I don't understand the public GRUU example in 7.1.1. The GRUU returned to a UA by the SIP-PBX looks like this:

   <allOneLine>
   Contact: <sip:[email-masked]>;
   pub-gruu="sip:[email-masked];bnc;gr=urn:
   uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=00:05:03:5e:70:a6";
   +sip.instance="<urn:uuid:d0e2f290-104b-11df-8a39-0800200c9a66>"
   ;expires=3600
   </allOneLine>

And may result in e.g. an INVITE request arriving at the SSP with the following Request-URI:

<allOneLine>
   INVITE sip:[email-masked];bnc;gr=urn:
   uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=00:05:03:5e:70:a6 SIP/2.0
</allOneLine>

I always thought a bnc parameter will only appear in REGISTER messages? Besides that, this would be the only case where both a user part and a bnc parameter appear together.

Thanks,
Ernst

---

From: Adam Roach <[email-masked]>
Date: Thu, 22 Jul 2010 15:56:48 -0500

> [dch] Yes, that would be one way to handle it, although not so friendly to the reg-event subscriber. Since for "normal" registrations the SSP registrar/proxy doesn't send a 480 response when the ta…

Well, we don't mandate reg event at the moment (although John has opened 
a ticket on this subject), so mandating that the SSP support it would be 
something quite new. Now, it probably has value to say that the SSP can 
answer the subscription as long as the PBX isn't registered. But I don't 
think we need to mandate any particular behavior.

Remember, we're defining protocols here, not architectures. We want to 
enable certain behaviors without limiting them or mandating them -- 
unless doing so is require for interoperability.

> If we take this approach where the SSP treats these SUBSCRIBEs like any request to be delivered to the SIP-PBX, then what happens to reg-event subscriptions to the SIP-PBX when the PBX transitions…

See RFC 3265, section 3.3.5 (or, for more clarity, rfc3265bis, section 
4.4.2).

/a

---

From: David Hancock <[email-masked]>
Date: Fri, 23 Jul 2010 14:56:23 -0600

Comments at the end...

> Sent: Thursday, July 22, 2010 2:57 PM
> To: David Hancock
> Cc: Elwell, John; Bernard Aboba; [email-masked]
> > Subject: RE: [martini] Announcement of MARTINI WG last Call on
> > [dch] Yes, that would be one way to handle it, although not so friendly
> to the reg-event subscriber. Since for "normal" registrations the SSP
> registrar/proxy doesn't send a 480 response when the target user isn't
> registered, it might be useful if the draft covered this case.
> 
> > If we take this approach where the SSP treats these SUBSCRIBEs like any
> request to be delivered to the SIP-PBX, then what happens to reg-event
> subscriptions to the SIP-PBX when the PBX transitions from registered to
> not-registered? Would they simply expire?
> 

[dch] Interesting.  Your idea being (I assume) that that this mechanism could be used to pass the reg-event subscription back and forth between the SSP network and the SIP-PBX, based on whether the PBX itself is registered or not.  I'm sensitive to your concern about not over-mandating what can be left to implementation. But I think an informative sentence or two on this would be very useful. 

Thanks
David

---

From: Adam Roach <[email-masked]>
Date: Sat, 24 Jul 2010 11:56:10 +0200

You've described pretty much the correct behavior. I'm not certain we 
need to have a lot of discussion about this, although a one-sentence 
summary (similar to what you've put above) probably has some value.

Yeah, I've always considered event packages that forbid multiple 
subscriptions in the case of a forked SUBSCRIBE to indicate a lack of 
imagination on behalf of the event package designer. :)

Basically, the only way to make this work properly would be to require 
the SSP to maintain back-end subscriptions to the PBX(es), and to 
compose all the relevant data into a single record. This isn't a 
difficult problem, but it requires significant new code in the SSP. The 
only way we could guarantee this working would be to mandate such 
behavior. I don't think that'll make people particularly happy.

I'll add a slide to the deck for discussion at the face-to-face meeting 
to see what people want to do here.

/a

---

From: Adam Roach <[email-masked]>
Date: Sat, 24 Jul 2010 11:58:11 +0200

On 7/23/10 10:56 PM, David Hancock wrote:
>> ...

That seems reasonable.

/a