Subject: [martini] Use Cases: what's important, what's not

From: Adam Roach <[email-masked]>
Date: Mon, 01 Feb 2010 17:45:40 -0600

The more we talk about this, the further apart opinions seem to get.
There appears to be a lot of ocean boiling going on right now, such
that even when we can decide on a fairly narrow scope ("phone numbers
only"), the system behavior that people expect appears to vary
literally from person to person.

I'm going to try to do something like I did before with the diagrams,
this time focusing on just what happens for E.164 numbers. I'll
continue with using the same dead companies as before (CentricVoice as
the SSP, and Pan-Am as the PBX).

In particular, I'm assuming that the tentative (albeit far from
unanimous) agreement to do an initial batch of work towards E.164
numbers means that these kinds of use cases are not under discussion at
the moment:

<Out Of Scope>

Internet                         CentricVoice
Pan-Am

|INVITE
|                                  |

|sip:[email-masked]
|                                  |

|--------------------------------->|
|

|
|INVITE                            |

|
|sip:[email-masked]
|

|
|--------------------------------->|

Internet                         CentricVoice
Pan-Am

|INVITE
|                                  |

|sip:[email-masked]
|
|

|--------------------------------->|
|

|
|INVITE                            |

|
|sip:[email-masked]
|

|
|--------------------------------->|

</Out Of Scope>

So, ignoring those, we seem to still have a huge disconnect on what the
SSP needs to be able to do as a result of the MARTINI operations. Now,
one of the nice things we get from E.164 numbers is that usernames now
become unique. We can specify transformations such that the username
that arrives at the SSP stays the same as it passes through the SSP.
Unlike my earlier examples, I'm going to assume that limiting to E.164
enables this kind of trivial transformation. Not in the *general* case,
of course -- only for MARTINI-routed E.164 numbers.

As you read through these, try to place each use case in one of the
following categories:

This use case by itself is sufficient for the architecture {I
am/my customers are} trying to deploy

This use case is necessary for the architecture {I am/my
customers are} trying to deploy, but requires other use cases also.

This use case is neither necessary nor sufficient for the
architecture {I am/my customers are} trying to deploy.

Frankly, I would expect almost everyone will be able to place each use
case in category #1. All of these solutions certainly allow the PBX to
figure out who the call is supposed to be sent to, and that appears to
be the key criteria for the inbound messages.

================

Use Case 1

================

RFC3263 for "centricvoice.com" resolves to the CentricVoice servers.

RFC3263 for "pan-am.com" is not relevant.

Internet
CentricVoice                          Pan-Am

|INVITE
|                                  |

|sip:[email-masked]
|                                  |

|--------------------------------->|
|

|
|INVITE                            |

|
|sip:[email-masked]
|

|
|--------------------------------->|

In this use case, the SSP receives a URI indicating its own domain. The
SSP is provisioned to know that +12145550105 belongs to Pan-Am. Having
received information from Pan-Am about its PBX's IP address, it changes
the domain to "pan-am.com," keeps the user ID, ignores RFC 3263
procedures, and sends the request to the MARTINI-registered IP address
it has for Pan-Am.

The key drawback for this use case is the disregard for RFC3263
procedures.

================

Use Case 2

================

RFC3263 for "pan-am.com" resolves to the CentricVoice servers.

Internet
CentricVoice                          Pan-Am

|INVITE
|                                  |

|sip:[email-masked]
|
|

|--------------------------------->|
|

|
|INVITE                            |

|
|sip:[email-masked]
|

|
|--------------------------------->|

In this use case, the SSP receives a URI indicating the domain for
pan-am.com. Having received information from Pan-Am about its PBX's IP
address, it leaves the Request-URI alone, ignores RFC 3263
procedures, and sends the request to the MARTINI-registered IP address
it has for Pan-Am.

Note that this use case is predicated on an external entity --
something on the other side of the "Internet" cloud -- being able to
take the E.164 number "+12145550105" and figure out that it needs to go
to the domain "pan-am.com". I emphasize this because I know some people
are interested in models in which is tenable to track "phone number to
SSP" mapping, while the relatively larger number of "phone number to
end customer" mappings might be unpalatable.

The key drawbacks for this use case are:

The disregard for RFC3263 procedures

Ambiguity around which SIP nodes are "responsible for" pan-am.com
(in the RFC 3261 sense of that word). Cullen had a litmus test for
this: is CentricVoice allowed to redirect calls for pan-am.com to a
voicemail server or answering service?

Given that 3261 lacks a formal description of "responsible for," we can
potentially define the problem of "responsible for" away (as Keith has
proposed) -- but I'm pretty certain it's not within MARTINI's scope to
clarify the terms appearing in RFC 3261. I think that would need to go
back to DISPATCH, and I doubt we want to wait for such an effort to
complete.

================

Use Case 3

================

RFC3263 for "centricvoice.com" resolves to the CentricVoice servers.

Internet
CentricVoice                          Pan-Am

|INVITE
|                                  |

|sip:[email-masked]
|                                  |

|--------------------------------->|
|

|
|INVITE                            |

|
|sip:[email-masked]
|

|
|--------------------------------->|

In this use case, the SSP receives a request for its own domain. The
SSP is provisioned to know that +12145550105 belongs to Pan-Am. Having
received information from Pan-Am about its PBX's IP address, it
changes the domain to that registered IP address (192.168.17.25), keeps
the user ID, correctly invokes RFC 3263
procedures, and sends the request to the resulting host (192.168.17.25).

This use case does not suffer from any of the drawbacks discussed to
date, other than differing from the model that is currently deployed
for bulk registrations (even though it is functionally identical to the
model deployed for single registrations).

================

Use Case 4

================

RFC3263 for "pan-am.com" resolves to the CentricVoice servers.

Internet
CentricVoice                          Pan-Am

|INVITE
|                                  |

|sip:[email-masked]
|
|

|--------------------------------->|
|

|
|INVITE                            |

|
|sip:[email-masked]
|

|
|--------------------------------->|

In this use case, the SSP receives a URI indicating the domain for
pan-am.com. Having received information from Pan-Am about its PBX's IP
address, it
changes the domain to that registered IP address (192.168.17.25), keeps
the user ID, correctly invokes RFC 3263
procedures, and sends the request to the resulting host (192.168.17.25).

Like use case 3, this use case does not suffer from any of the
drawbacks discussed to
date, other than differing from the model that is currently deployed
for bulk registrations (even though it is functionally identical to the
model deployed for single registrations). However, it is predicated on
an external entity -- something on the
other side of the "Internet" cloud -- being able to take the E.164
number "+12145550105" and figure out that it needs to go to the domain
"pan-am.com".

================

Use Case 5

================

RFC3263 for "centricvoice.com" resolves to the CentricVoice servers.

Internet
CentricVoice                          Pan-Am

|INVITE
|                                  |

|sip:[email-masked]
|                                  |

|--------------------------------->|
|

|
|INVITE                            |

|
|tel:+12145550105                  |

|
|--------------------------------->|

In this use case, the SSP receives a URI indicating its own domain. The
SSP is provisioned to know that +12145550105 belongs to Pan-Am. It
changes the R-URI to a tel: URI containing only the E.164 number in
question. Having received information from Pan-Am about its PBX's IP
address, it sends the request to the resulting host (192.168.17.25).
Since the URI in question is a TEL URI, RFC3263 issues are avoided
altogether, eliminating any alt-root considerations.

The major drawback to this use case is that it (likely) requires the
ability to register TEL URIs, which is currently normatively forbidden
by RFC 3261. While this is tractable, it would require companion work
in SIPCORE to relax this normative requirement. It also would likely
require more mechanism than other approaches, since we're effectively
adding on a new URI-to-host address resolution procedure.

================

Use Case 5a

================

A variation on Use Case 5, this use case ends up with a R-URI of the
PBX's lead number, with an extension parameter that indicates the
desired extension on the PBX:

Internet
CentricVoice                          Pan-Am

|INVITE
|                                  |

|sip:[email-masked]
|                                  |

|--------------------------------->|
|

|
|INVITE                            |

|
|tel:+12145550100;extension=1214555|

|                                  |
0105|

|
|--------------------------------->|

This is effectively the exact same procedure as Use Case 5; however, it
may make contact registration somewhat easier (depending on the exact
mechanism used to communicate domain IP addresses).

================

Use Case 6

================

RFC3263 for "centricvoice.com" resolves to the CentricVoice servers.

Internet
CentricVoice                          Pan-Am

|INVITE
|                                  |

|sip:[email-masked]
|                                  |

|--------------------------------->|INVITE
|

|
|sip:[email-masked]
|

|                                  |Route:
<sip:[email-masked]>
|

|
|--------------------------------->|

In this example, In this use case, the SSP receives a URI indicating
its own domain. The
SSP is provisioned to know that +12145550105 belongs to Pan-Am. It
pushes the MARTINI-registered contact into the route set, leaves the
Request-URI unmodified, invokes RFC 3263 procedures (on the Route) and
sends the request to the resulting host.

A key drawback to this use case is that it cannot be effected using
REGISTER without radically changing the semantics of REGISTER (i.e.,
registering a path towards an AOR instead of a contact for an AOR).
These changes necessarily require intermediaries who are a party to the
REGISTER transaction (e.g., using Path and/or Service-Route) to
understand these changed semantics, and would require the use of a
Proxy-Require to avoid the ensuing problems. Using a method other than
REGISTER eliminates this class of problems.

A second major drawback to this approach pertains to domain
responsibility: unless the Pan-Am PBX is "responsible for"
centricvoice.com, it is in violation of SIP routing procedures if it
fails to route it back to CentricVoice: "If the domain of the
Request-URI indicates a domain this element is not responsible for, the
Request-URI MUST be placed into the target set as the only target, and
the element MUST proceed to the task of Request Forwarding."  In
practice, I imagine it wants to route it to one of its internal
extensions.

================

Use Case 7

================

RFC3263 for "centricvoice.com" resolves to the CentricVoice servers.

Internet
CentricVoice                          Pan-Am

|INVITE
|                                  |

|sip:[email-masked]
|                                  |

|--------------------------------->|INVITE sip:[email-masked]
|

|                                  |History-Info:
sip:+12145550105@cen|

|                                  |                     tricvoice.com|

|
|--------------------------------->|

Similar to use case 6, except the SSP swaps out the registered Contact
URI for the Request-URI, and squirrels the incoming R-URI (containing
the phone number) away in a History-Info header field.

On the plus side, this looks a lot like normal proxy/registrar
behavior. Drawbacks include defining concrete procedures around which
History-Info entry to use (which is a problem the 4244bis draft is
currently struggling with), especially in the case that there are
intermediaries between the SSP and the PBX. We would also be creating a
normative dependency on the 4244bis document, which may delay a final
delivery of MARTINI work substantially.

======================================================================

Now, I've heard and read things that imply that each these use cases
are under consideration by at least one person. I think we need to
focus. Clearly just saying "phone numbers" is not sufficient. Look back
over how you rated each of the use cases relative to the "sufficient,"
"necessary but not sufficient," and "neither necessary nor sufficient"
criteria. I think you'll find that, if you were honest with yourself,
all or most of these use cases fall into the first category. I'm not
saying you *like* them all -- merely that they will get the job done,
if push were to come to shove.

So, I think we need to pick one and work on the mechanism required to
enable it. And I think we need to be vigilant against scope creep. As
we get into mechanism, it will be overwhelmingly tempting to say, "oh,
but we can add on Use Case X if we just do *this* small thing!" But
those small things can spiral out of control.

All other things being equal, I have a strong preference for Use Case
3, as its only real drawback is that it varies from the demonstrably
flawed [1] mechanism that showed up on the IETF's doorstep.
Any other
approach is going to require interested parties coming to consensus on
the issues associated with the other use cases, and I think we've seen
that won't be a very fast process.

/a

[1] Lest this offend anyone as being too general a criticism, I refer
to the set of shortcomings enumerated here:
http://www.ietf.org/mail-archive/web/martini/current/msg00412.html

---

From: Dean Willis <[email-masked]>
Date: Mon, 1 Feb 2010 19:43:02 -0600

On Feb 1, 2010, at 5:45 PM, Adam Roach wrote:

I don't understand the difference between Cases 1 and 3. case 1 is a  
result of a registration using a contact with a domain name (which  
MUST resolve using RFC 3263 procedures) and case 3 is a result of  
registration of  a contact with an IP address.

"Having received information from Pan Am about its PBX's IP address"  
implies to me "registering with a To: @pan-am.com and a Contact: @ip- 
address". This implies that the DNS SIP SRV record for "@pan-am.com"  
points to CentricVoice's servers.

The only thing that is "provisioned" is a translation mapping from "sip:[email-masked] 
" to "@sip:[email-masked]",  followed by a contact-routing  
operation from "number@pan-am" to "number@contact-ip-address".

So where is RFC 3263 being disregarded?

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Mon, 01 Feb 2010 23:51:50 -0600

> registration of  a contact with an IP address.

I think there's some confusion here, and it may well by my fault. When I 
asserted "RFC3263 for 'pan-am.com' is not relevant," I should have 
followed up by indicating that RFC3263 resolution procedures for 
"pan-am.com" cannot be assumed to result in an IP address belonging to 
Pan-Am's PBX. So the second INVITE (the one from CentricVoice to Pan-Am) 
cannot be routed according to RFC 3263 resolution rules.

Make sense?

/a

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 2 Feb 2010 09:32:08 +0100

Adam,

That's great that you have taken the trouble to enumerate these different cases. Talking from a PBX perspective, I think you are correct in saying that all would get the job done. Inevitably there are some I dislike.

I dislike 5/5a because of the implications of making REGISTER work with tel URIs (and also tel URIs tend not to be used so much today on PBXs, in my opinion).

I dislike 6, because the PBX can't do anything with the received Request-URI - strictly speaking it would have to route it back to the SP.

I dislike 7, for the same reason, plus the known difficulties with extracting information from History-Info (I have my doubts whether the present effort to revise History-Info will really solve its problems).

I suppose you could have a use case 8, which is a kind of combination of 2 and 6. So you start of with sip:[email-masked] and deliver the same Request-URI, together with Route: sip:[email-masked]. This was what I had in mind pre-MARTINI. It solves the problem of 6, but still has the issues of 2.

Ignoring use case 8, this leaves use cases 1 to 4. From a PBX point of view, cases 1 and 2 are the same. The difference is how the request reaches the SP. Is this an issue for MARTINI? Or put it another way, if we provide a solution for case 1, does this stop people implementing case 2? Similarly for cases 3 and 4: if we provide a solution for case 3, does this stop people implementing case 4?

So this narrows it down to cases 1 and 3. The recent "Implications" thread seemed to be homing in on a solution that would give both 1 and 3, which sounds reasonable to me. I am not convinced that there is a problem with case 1's by-passing RFC 3263 procedures.

John

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 01 February 2010 23:46
To: [email-masked]
Subject: [martini] Use Cases: what's important, what's not

The more we talk about this, the further apart opinions seem to get. There appears to be a lot of ocean boiling going on right now, such that even when we can decide on a fairly narrow scope ("phone numbers only"), the system behavior that people expect appears to vary literally from person to person.

I'm going to try to do something like I did before with the diagrams, this time focusing on just what happens for E.164 numbers. I'll continue with using the same dead companies as before (CentricVoice as the SSP, and Pan-Am as the PBX).

In particular, I'm assuming that the tentative (albeit far from unanimous) agreement to do an initial batch of work towards E.164 numbers means that these kinds of use cases are not under discussion at the moment:

<Out Of Scope>

Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:[email-masked] |                                  |
    |--------------------------------->|                                  |
    |                                  |INVITE                            |
    |                                  |sip:[email-masked]  |
    |                                  |--------------------------------->|

Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:[email-masked]       |                                  |
    |--------------------------------->|                                  |
    |                                  |INVITE                            |
    |                                  |sip:[email-masked]  |
    |                                  |--------------------------------->|

</Out Of Scope>

So, ignoring those, we seem to still have a huge disconnect on what the SSP needs to be able to do as a result of the MARTINI operations. Now, one of the nice things we get from E.164 numbers is that usernames now become unique. We can specify transformations such that the username that arrives at the SSP stays the same as it passes through the SSP. Unlike my earlier examples, I'm going to assume that limiting to E.164 enables this kind of trivial transformation. Not in the *general* case, of course -- only for MARTINI-routed E.164 numbers.

As you read through these, try to place each use case in one of the following categories:

 1.  This use case by itself is sufficient for the architecture {I am/my customers are} trying to deploy

 2.  This use case is necessary for the architecture {I am/my customers are} trying to deploy, but requires other use cases also.

 3.  This use case is neither necessary nor sufficient for the architecture {I am/my customers are} trying to deploy.

Frankly, I would expect almost everyone will be able to place each use case in category #1. All of these solutions certainly allow the PBX to figure out who the call is supposed to be sent to, and that appears to be the key criteria for the inbound messages.

________________________________

================
Use Case 1
================

Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:[email-masked] |                                  |
    |--------------------------------->|                                  |
    |                                  |INVITE                            |
    |                                  |sip:[email-masked]       |
    |                                  |--------------------------------->|

In this use case, the SSP receives a URI indicating its own domain. The SSP is provisioned to know that +12145550105 belongs to Pan-Am. Having received information from Pan-Am about its PBX's IP address, it changes the domain to "pan-am.com," keeps the user ID, ignores RFC 3263 procedures, and sends the request to the MARTINI-registered IP address it has for Pan-Am.

The key drawback for this use case is the disregard for RFC3263 procedures.

________________________________

================
Use Case 2
================

Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:[email-masked]       |                                  |
    |--------------------------------->|                                  |
    |                                  |INVITE                            |
    |                                  |sip:[email-masked]       |
    |                                  |--------------------------------->|

In this use case, the SSP receives a URI indicating the domain for pan-am.com. Having received information from Pan-Am about its PBX's IP address, it leaves the Request-URI alone, ignores RFC 3263 procedures, and sends the request to the MARTINI-registered IP address it has for Pan-Am.

Note that this use case is predicated on an external entity -- something on the other side of the "Internet" cloud -- being able to take the E.164 number "+12145550105" and figure out that it needs to go to the domain "pan-am.com". I emphasize this because I know some people are interested in models in which is tenable to track "phone number to SSP" mapping, while the relatively larger number of "phone number to end customer" mappings might be unpalatable.

 1.  The disregard for RFC3263 procedures
 2.  Ambiguity around which SIP nodes are "responsible for" pan-am.com (in the RFC 3261 sense of that word). Cullen had a litmus test for this: is CentricVoice allowed to redirect calls for pan-am.com to a voicemail server or answering service?

Given that 3261 lacks a formal description of "responsible for," we can potentially define the problem of "responsible for" away (as Keith has proposed) -- but I'm pretty certain it's not within MARTINI's scope to clarify the terms appearing in RFC 3261. I think that would need to go back to DISPATCH, and I doubt we want to wait for such an effort to complete.

________________________________

================
Use Case 3
================

Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:[email-masked] |                                  |
    |--------------------------------->|                                  |
    |                                  |INVITE                            |
    |                                  |sip:[email-masked]    |
    |                                  |--------------------------------->|

In this use case, the SSP receives a request for its own domain. The SSP is provisioned to know that +12145550105 belongs to Pan-Am. Having received information from Pan-Am about its PBX's IP address, it changes the domain to that registered IP address (192.168.17.25), keeps the user ID, correctly invokes RFC 3263 procedures, and sends the request to the resulting host (192.168.17.25).

This use case does not suffer from any of the drawbacks discussed to date, other than differing from the model that is currently deployed for bulk registrations (even though it is functionally identical to the model deployed for single registrations).

________________________________

================
Use Case 4
================

Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:[email-masked]       |                                  |
    |--------------------------------->|                                  |
    |                                  |INVITE                            |
    |                                  |sip:[email-masked]    |
    |                                  |--------------------------------->|

In this use case, the SSP receives a URI indicating the domain for pan-am.com. Having received information from Pan-Am about its PBX's IP address, it changes the domain to that registered IP address (192.168.17.25), keeps the user ID, correctly invokes RFC 3263 procedures, and sends the request to the resulting host (192.168.17.25).

Like use case 3, this use case does not suffer from any of the drawbacks discussed to date, other than differing from the model that is currently deployed for bulk registrations (even though it is functionally identical to the model deployed for single registrations). However, it is predicated on an external entity -- something on the other side of the "Internet" cloud -- being able to take the E.164 number "+12145550105" and figure out that it needs to go to the domain "pan-am.com".

________________________________

================
Use Case 5
================

Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:[email-masked] |                                  |
    |--------------------------------->|                                  |
    |                                  |INVITE                            |
    |                                  |tel:+12145550105                  |
    |                                  |--------------------------------->|

In this use case, the SSP receives a URI indicating its own domain. The SSP is provisioned to know that +12145550105 belongs to Pan-Am. It changes the R-URI to a tel: URI containing only the E.164 number in question. Having received information from Pan-Am about its PBX's IP address, it sends the request to the resulting host (192.168.17.25). Since the URI in question is a TEL URI, RFC3263 issues are avoided altogether, eliminating any alt-root considerations.

The major drawback to this use case is that it (likely) requires the ability to register TEL URIs, which is currently normatively forbidden by RFC 3261. While this is tractable, it would require companion work in SIPCORE to relax this normative requirement. It also would likely require more mechanism than other approaches, since we're effectively adding on a new URI-to-host address resolution procedure.

================
Use Case 5a
================

A variation on Use Case 5, this use case ends up with a R-URI of the PBX's lead number, with an extension parameter that indicates the desired extension on the PBX:

Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:[email-masked] |                                  |
    |--------------------------------->|                                  |
    |                                  |INVITE                            |
    |                                  |tel:+12145550100;extension=1214555|
    |                                  |                              0105|
    |                                  |--------------------------------->|

This is effectively the exact same procedure as Use Case 5; however, it may make contact registration somewhat easier (depending on the exact mechanism used to communicate domain IP addresses).

________________________________

================
Use Case 6
================

Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:[email-masked] |                                  |
    |--------------------------------->|INVITE                            |
    |                                  |sip:[email-masked] |
    |                                  |Route: <sip:[email-masked]><sip:[email-masked]>    |
    |                                  |--------------------------------->|

In this example, In this use case, the SSP receives a URI indicating its own domain. The SSP is provisioned to know that +12145550105 belongs to Pan-Am. It pushes the MARTINI-registered contact into the route set, leaves the Request-URI unmodified, invokes RFC 3263 procedures (on the Route) and sends the request to the resulting host.

A key drawback to this use case is that it cannot be effected using REGISTER without radically changing the semantics of REGISTER (i.e., registering a path towards an AOR instead of a contact for an AOR). These changes necessarily require intermediaries who are a party to the REGISTER transaction (e.g., using Path and/or Service-Route) to understand these changed semantics, and would require the use of a Proxy-Require to avoid the ensuing problems. Using a method other than REGISTER eliminates this class of problems.

A second major drawback to this approach pertains to domain responsibility: unless the Pan-Am PBX is "responsible for" centricvoice.com, it is in violation of SIP routing procedures if it fails to route it back to CentricVoice: "If the domain of the Request-URI indicates a domain this element is not responsible for, the Request-URI MUST be placed into the target set as the only target, and the element MUST proceed to the task of Request Forwarding."  In practice, I imagine it wants to route it to one of its internal extensions.

________________________________

================
Use Case 7
================

Internet                         CentricVoice                          Pan-Am
    |INVITE                            |                                  |
    |sip:[email-masked] |                                  |
    |--------------------------------->|INVITE sip:[email-masked]      |
    |                                  |History-Info: sip:+12145550105@cen|
    |                                  |                     tricvoice.com|
    |                                  |--------------------------------->|

Similar to use case 6, except the SSP swaps out the registered Contact URI for the Request-URI, and squirrels the incoming R-URI (containing the phone number) away in a History-Info header field.

On the plus side, this looks a lot like normal proxy/registrar behavior. Drawbacks include defining concrete procedures around which History-Info entry to use (which is a problem the 4244bis draft is currently struggling with), especially in the case that there are intermediaries between the SSP and the PBX. We would also be creating a normative dependency on the 4244bis document, which may delay a final delivery of MARTINI work substantially.

________________________________
======================================================================

Now, I've heard and read things that imply that each these use cases are under consideration by at least one person. I think we need to focus. Clearly just saying "phone numbers" is not sufficient. Look back over how you rated each of the use cases relative to the "sufficient," "necessary but not sufficient," and "neither necessary nor sufficient" criteria. I think you'll find that, if you were honest with yourself, all or most of these use cases fall into the first category. I'm not saying you *like* them all -- merely that they will get the job done, if push were to come to shove.

So, I think we need to pick one and work on the mechanism required to enable it. And I think we need to be vigilant against scope creep. As we get into mechanism, it will be overwhelmingly tempting to say, "oh, but we can add on Use Case X if we just do *this* small thing!" But those small things can spiral out of control.

All other things being equal, I have a strong preference for Use Case 3, as its only real drawback is that it varies from the demonstrably flawed [1] mechanism that showed up on the IETF's doorstep. Any other approach is going to require interested parties coming to consensus on the issues associated with the other use cases, and I think we've seen that won't be a very fast process.

/a

[1] Lest this offend anyone as being too general a criticism, I refer to the set of shortcomings enumerated here: http://www.ietf.org/mail-archive/web/martini/current/msg00412.html

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Feb 2010 10:01:53 -0600

Adam,

I'm getting a late start this morning, and your use cases posting was at the top of my queue (followed by, so far, about 40 other MARTINI e-mails).

Speaking as co-chair, I wanted to thank you for providing this structure. I'm expecting it will be very helpful as we work through the details.

I probably won't follow up on anything else until I'm current (see you guys in a bit).

Spencer
  ----- Original Message ----- 
  From: Adam Roach 
  To: [email-masked] 
  Sent: Monday, February 01, 2010 5:45 PM
  Subject: [martini] Use Cases: what's important, what's not

  <Out Of Scope>

  </Out Of Scope>

    1.. This use case by itself is sufficient for the architecture {I am/my customers are} trying to deploy

    2.. This use case is necessary for the architecture {I am/my customers are} trying to deploy, but requires other use cases also.

    3.. This use case is neither necessary nor sufficient for the architecture {I am/my customers are} trying to deploy. 

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

  ================
  Use Case 1
  ================

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

  ================
  Use Case 2
  ================

    1.. The disregard for RFC3263 procedures

    2.. Ambiguity around which SIP nodes are "responsible for" pan-am.com (in the RFC 3261 sense of that word). Cullen had a litmus test for this: is CentricVoice allowed to redirect calls for pan-am.com to a voicemail server or answering service? 

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

  ================
  Use Case 3
  ================

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

  ================
  Use Case 4
  ================

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

  ================
  Use Case 5
  ================

  ================
  Use Case 5a
  ================

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

  ================
  Use Case 6
  ================

      |                                  |Route: <sip:[email-masked]>    |

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

  ================
  Use Case 7
  ================

------------------------------------------------------------------------------
  ======================================================================

  /a

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

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

---

From: Adam Roach <[email-masked]>
Date: Tue, 02 Feb 2010 12:30:52 -0600

On 2/2/10 02:32, Feb 2, Elwell, John wrote:
> Ignoring use case 8, this leaves use cases 1 to 4. From a PBX point of 
> view, cases 1 and 2 are the same. The difference is how the request 
> reaches the SP. Is this an issue for MARTINI? Or put it another way, 
> if we provide a solution for case 1, does this stop people 
> implementing case 2? Similarly for cases 3 and 4: if we provide a 
> solution for case 3, does this stop people implementing case 4?

At this 10,000-mile high view, there is effectively no difference. I 
think that once we get into the syntax and semantics of what needs to go 
in the MARTINI deliverables, there will almost certainly be differences. 
Perhaps not. But I don't want to get caught up in analysis and 
discussions about whether doing case 3 *also* enables case 4 unless we 
come to an agreement that someone absolutely must have case 4. Even if 
all we need to do is the analysis that the solution works for both, 
that's still additional work.

/a

---

From: David Hancock <[email-masked]>
Date: Tue, 2 Feb 2010 12:58:17 -0700

Adam,

Thanks for documenting these different use cases.

Here is my understanding of John Elwell's use-case 8 (combination of 2 and 6) and my use-case 9 (combination of 1 and 6).

================
Use Case 8
================

    |sip:[email-masked]<sip:[email-masked]>       |                                  |

================
Use Case 9
================

I think that 9 would be the most common case in the real world. A user in the originating VoIP network dials a digit string identifying the Pan-Am enterprise user, the originating network converts the string to an E.164 number, and converts that to the SIP URI sip:[email-masked]; user=phone (probably via ENUM). The CentricVoice network receives the request, and converts the received E.164 number via its private database (possibly ENUM), to sip:[email-masked], and then routes the request using to the registered contact address for that URI using loose-routing

Thanks
David

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Monday, February 01, 2010 4:46 PM
To: [email-masked]
Subject: [martini] Use Cases: what's important, what's not

<Out Of Scope>

================
Use Case 1
================

================
Use Case 2
================

================
Use Case 3
================

================
Use Case 4
================

================
Use Case 5
================

================
Use Case 5a
================

================
Use Case 6
================

================
Use Case 7
================

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Feb 2010 15:54:31 -0500

David,

A slight variant on these cases is using 
sip:[email-masked].

It that case the domain used by the pbx is a subdomain of the SSPs 
domain, and so it presumably owns and manages it on behalf of the pbx 
customer. Using pan-am.com would be just as goof, *if* centricvoice also 
owned and managed the domain name on behalf of the customer. But that 
wouldn't make sense for a company the size of pan-am (when it was a 
going concern.)

Otherwise the SSP is put in the position of having to legally vouch for 
this particular pbx belonging to somebody who has rights to the domain 
name pan-am.com. It seems questionable whether an SSP could/would do 
that if the question came to their legal department.

	Thanks,
	Paul

David Hancock wrote:
> Here is my understanding of John Elwell’s use-case 8 (combination of 2 
> and 6) and my use-case 9 (combination of 1 and 6).
> 
> 
> ================
> Use Case 8
> ================
> 
>  
> 
>  
> 
> Internet                         CentricVoice                          
> Pan-Am
> 
>     |INVITE                            |                                  |
>     |sip:[email-masked] <sip:[email-masked]> 
>       |                                  |
> I think that 9 would be the most common case in the real world. A user 
> in the originating VoIP network dials a digit string identifying the 
> Pan-Am enterprise user, the originating network converts the string to 
> an E.164 number, and converts that to the SIP URI 
> sip:[email-masked]; user=phone (probably via ENUM). The 
> CentricVoice network receives the request, and converts the received 
> E.164 number via its private database (possibly ENUM), to 
> sip:[email-masked], and then routes the request using to the 
> registered contact address for that URI using loose-routing
> 
>  
> 
> Thanks
> 
> David
> 
>  
> 
>  
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Adam Roach
> *Sent:* Monday, February 01, 2010 4:46 PM
> *To:* [email-masked]
> *Subject:* [martini] Use Cases: what's important, what's not
> 
>  
> 
> There appears to be a lot of ocean boiling going on right now, such that 
> even when we can decide on a fairly narrow scope ("phone numbers only"), 
> the system behavior that people expect appears to vary literally from 
> person to person.
> 
> this time focusing on just what happens for E.164 numbers. I'll continue 
> with using the same dead companies as before (CentricVoice as the SSP, 
> and Pan-Am as the PBX).
> 
>    2. This use case is necessary for the architecture {I am/my customers
>       are} trying to deploy, but requires other use cases also.
>    3. This use case is neither necessary nor sufficient for the
> ------------------------------------------------------------------------
> 
> 
> ================
> Use Case 1
> ================
> 
> ------------------------------------------------------------------------
> 
> 
> ================
> Use Case 2
> ================
> 
> address, it leaves the Request-URI alone, ignores RFC 3263 procedures, 
> and sends the request to the MARTINI-registered IP address it has for 
> Pan-Am.
> 
> Note that this use case is predicated on an external entity -- something 
> on the other side of the "Internet" cloud -- being able to take the 
> E.164 number "+12145550105" and figure out that it needs to go to the 
> domain "pan-am.com". I emphasize this because I know some people are 
> interested in models in which is tenable to track "phone number to SSP" 
> mapping, while the relatively larger number of "phone number to end 
> customer" mappings might be unpalatable.
> 
>    2. Ambiguity around which SIP nodes are "responsible for" pan-am.com
>       this: is CentricVoice allowed to redirect calls for pan-am.com to
>       a voicemail server or answering service?
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ================
> Use Case 3
> ================
> 
> In this use case, the SSP receives a request for its own domain. The SSP 
> is provisioned to know that +12145550105 belongs to Pan-Am. Having 
> the domain to that registered IP address (192.168.17.25), keeps the user 
> ID, correctly invokes RFC 3263 procedures, and sends the request to the 
> resulting host (192.168.17.25).
> 
> date, other than differing from the model that is currently deployed for 
> bulk registrations (even though it is functionally identical to the 
> ------------------------------------------------------------------------
> 
> 
> ================
> Use Case 4
> ================
> 
> address, it changes the domain to that registered IP address 
> (192.168.17.25), keeps the user ID, correctly invokes RFC 3263 
> Like use case 3, this use case does not suffer from any of the drawbacks 
> discussed to date, other than differing from the model that is currently 
> deployed for bulk registrations (even though it is functionally 
> identical to the model deployed for single registrations). However, it 
> is predicated on an external entity -- something on the other side of 
> the "Internet" cloud -- being able to take the E.164 number 
> "+12145550105" and figure out that it needs to go to the domain 
> "pan-am.com".
> 
> ------------------------------------------------------------------------
> 
> 
> ================
> Use Case 5
> ================
> 
> by RFC 3261. While this is tractable, it would require companion work in 
> SIPCORE to relax this normative requirement. It also would likely 
> ------------------------------------------------------------------------
> 
> 
> ================
> Use Case 6
> ================
> 
> In this example, In this use case, the SSP receives a URI indicating its 
> own domain. The SSP is provisioned to know that +12145550105 belongs to 
> Pan-Am. It pushes the MARTINI-registered contact into the route set, 
> leaves the Request-URI unmodified, invokes RFC 3263 procedures (on the 
> Route) and sends the request to the resulting host.
> 
> practice, I imagine it wants to route it to one of its internal extensions.
> 
> ------------------------------------------------------------------------
> 
> 
> ================
> Use Case 7
> ================
> 
> tricvoice.com|  
> On the plus side, this looks a lot like normal proxy/registrar behavior. 
> Drawbacks include defining concrete procedures around which History-Info 
> entry to use (which is a problem the 4244bis draft is currently 
> struggling with), especially in the case that there are intermediaries 
> between the SSP and the PBX. We would also be creating a normative 
> dependency on the 4244bis document, which may delay a final delivery of 
> MARTINI work substantially.
> 
> ------------------------------------------------------------------------
> 
> Now, I've heard and read things that imply that each these use cases are 
> under consideration by at least one person. I think we need to focus. 
> Clearly just saying "phone numbers" is not sufficient. Look back over 
> how you rated each of the use cases relative to the "sufficient," 
> saying you *like* them all -- merely that they will get the job done, if 
> push were to come to shove.
> 
> enable it. And I think we need to be vigilant against scope creep. As we 
> get into mechanism, it will be overwhelmingly tempting to say, "oh, but 
> we can add on Use Case X if we just do *this* small thing!" But those 
> small things can spiral out of control.
> 
> All other things being equal, I have a strong preference for Use Case 3, 
> as its only real drawback is that it varies from the demonstrably flawed 
> ^[1] mechanism that showed up on the IETF's doorstep. Any other approach 
> is going to require interested parties coming to consensus on the issues 
> associated with the other use cases, and I think we've seen that won't 
> be a very fast process.
> 
> /a
> 
> [1] Lest this offend anyone as being too general a criticism, I refer to 
> the set of shortcomings enumerated here:

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 2 Feb 2010 16:08:18 -0500

Inline...

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Tuesday, February 02, 2010 3:32 AM
To: Adam Roach; [email-masked]
Subject: Re: [martini] Use Cases: what's important, what's not

Adam,

I agree with John on the above.

Same here, and in fact I don't think use-case 1 or 2 are tenable without having the Route header. (otherwise a downstream proxy won't know how to get it to the PBX)

Exactly my thoughts too - if we solve case 1 or 3, nothing stops 2 or 4.

Agreed.
BTW, Adam: for Case-3 you said "This use case does not suffer from any of the drawbacks discussed to date, other than differing from the model that is currently deployed for bulk registrations (even though it is functionally identical to the model deployed for single registrations)."  Actually use-case 3 is pretty common in current deployments, afaict.  Arguably more common than use-case 1.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Tue, 02 Feb 2010 15:12:58 -0600

On 2/2/10 15:08, Feb 2, Hadriel Kaplan wrote:
>
> BTW, Adam: for Case-3 you said "This use case does not suffer from any 
> of the drawbacks discussed to date, other than differing from the 
> model that is currently deployed for bulk registrations (even though 
> it is functionally identical to the model deployed for single 
> registrations)."  Actually use-case 3 is pretty common in current 
> deployments, afaict.  Arguably more common than use-case 1.
>

Excellent. I'm happy to hear that.

/a

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 2 Feb 2010 14:23:15 -0800

[BA] I think we're conflating multiple distinct things here.

One thing is the use of a domain name in the Contact URI. 
This is already legal in a single AOR registration; however
before doing "Contact routing", the SSP should check that the
A/AAAA RR corresponding to the domain name corresponds to the 
address from which the PBX registration arrived.  Of course, the
same check needs to be made if the PBX used an address within
the domain portion of the Contact URI, so the domain name case
only adds a name resolution step. 

The second (distinct) thing is "domain registration".  Here 
there may be no RRs for the SSP to check against, so the SSP
needs to validate the claim by other means.  This may be very
difficult if the domain in question is not delegated by the
SSP and the SSP is not a registrar or in partnership with one.  

Paul said:

"A slight variant on these cases is using 
sip:[email-masked].

Otherwise the SSP is put in the position of having to legally vouch for 
this particular pbx belonging to somebody who has rights to the domain 
name pan-am.com. It seems questionable whether an SSP could/would do 
that if the question came to their legal department."

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Feb 2010 17:25:48 -0500

I'll echo others and thank Adam for focusing things.
(I know some additional candidates have been added, but I think others 
are falling off the list.)

I propose that we need some additional detail in all of these cases that 
hasn't been focused on much so far. Namely, the From and To addresses. I 
realize they aren't germane to routing the request, but they are 
potentially important for security and simply for a recipient deciding 
where to send a followup request. The choice made affects whether these 
values will have to be replaced by some middlebox along the way, and so 
is significant. Maybe we need to discuss P-Asserted-ID as well, for 
those that use it.

	Thanks,
	Paul

---

From: David Hancock <[email-masked]>
Date: Tue, 2 Feb 2010 17:39:27 -0700

Paul,

I agree, it's possible for the PBX to use a subdomain of the SSP. In fact I expect this to be a common case for operators targeting small businesses that don't have their own domains.

Regarding the security issue you raised -- does the same security issue exist for the "peering" model, where the SSP network (say SSPt in the diagram) acts as a transit network to provide connectivity between the enterprise-peer and the global network?

  UAx---SSPx---+
               |-----SSPt---PBXpanam---UApa
  UAy---SSPy---+

Thanks
David

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, February 02, 2010 1:55 PM
> To: David Hancock
> Cc: Adam Roach; [email-masked]
> > Here is my understanding of John Elwell's use-case 8 (combination of 2
> >     |                                  |INVITE
> >     |                                  |INVITE
> >     |                                  |INVITE
> >     |                                  |INVITE
> >     |                                  |INVITE
> >     |                                  |INVITE
> >     |                                  |INVITE
> >     |                                  |INVITE
> >     |                                  |INVITE
> >     |                                  |tel:+12145550105
> >     |                                  |INVITE
> |sip:[email-masked] |

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 3 Feb 2010 10:04:41 +0100

Notwithstanding dicusssions about use of domain names instead of IP addresses in certain circumstances, there seems to be some convergence on Adam's use case 3 (not necessarily as the only solution, but let's focus on that).

To Paul's questions about From, To and PAI, I think we should also add Contact.
In the following examples I will show only the flows between the SSP and the PBX

1. Inbound call to PBX.

PBX                     SSP
      INVITE sip:[email-masked]
      To: Q1 (see below)
      From: Not relevant
      PAI: Not relevant
      Contact: Not relevant
<-------------------------

      180
      Contact: Q2 (see below)
-------------------------->

2. Outbound call from PBX.       
PBX                     SSP
      INVITE Any off-PBX value
      To: Q3 (see below)
      From: Q4 (see below)
      PAI: Q5 (see below)
      Contact: Q6 (see below)
------------------------->

      180
      Contact: Not relevant
<--------------------------

Questions raised:
Q1: Value of To URI in inbound INVITE request:
In principle, it could be any value, since the request may have been retargeted to the PBX. However, in the most common case I would expect it to have a URI of the form sip:[email-masked];useer=phone.

Q2: Value of Contact URI sent by PBX in response to inbound INVITE request:

Option 1: It must be one of the registered contact URIs (i.e., corresponding to one of the registered E.164 numbers). This is not viable for two reasons:
a) because this would fail to identify the particular UA on the PBX that has accepted the call;
b) because the call might have been retargeted by the PBX to a destination that is not one of the registered E.164 numbers.

Option 2: Any value ending in @10.1.2.3. The PBX could then choose a value that identifies the specific UA that accepted the call. The SSP would probably need to record-route to ensure inbound mid-dialog requests can reach the PBX, and would probably need to act as a B2BUA and map to a globally routable contact URI if it needs a URI with gruu properties for functions like transfer.

Option 3: I don't think the PBX would necessarily be able claim gruu properties for a contact URI in accordance with option 2, in which case if it needed a gruu, it would need to obtain one from the SSP using the REGISTER transaction. I really don't know if and how this would work.

Q3: Value of To URI in outbound INVITE request:
In most cases it would reflect the value of the Request-URI. In some cases it could differ, if the request has already been retargeted. If the original target was an on-PBX E.164 number, similar considerations to From (Q4) apply.

Q4: Value of From URI in outbound INVITE request:
Option 1: Of the form sip:[email-masked]. But this is a contact URI.
Option 2: Of the form sip:[email-masked];user=phone.
Option 3: Of the form sip:[email-masked];user=phone. But this brings back the whole argument about domain names.
Option 4: Of the form tel:+123456789

Also, what if the request comes from a source that is not reachable by inbound requests, i.e., it is not from a registered E.164 number?

If you want to use RFC 4474, I think only option 3 would be viable, so perhaps we have to rule out the ability to use RFC 4474 except under certain conditions.

Q5: Value of PAI in outbound INVITE request:
Similar considerations to Q5: In addition, option 2 looks suspect, because it would require the PBX to make an assertion on behalf of the SSP.

Q6: Value of Contact URI in outbound INVITE request:
Similar considerations to Q2, bearing in mind the source of the request might not be a UA bound to one of the registered E.164 numbers.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 02 February 2010 22:26
> To: Adam Roach
> Cc: [email-masked]

---

From: Adam Roach <[email-masked]>
Date: Wed, 03 Feb 2010 10:26:58 -0600

John:

Thanks for taking a deeper dive into these issues. Some comments inline.

>        INVITE sip:[email-masked]

I would agree that it can have pretty much any value. I'm not sure we 
need to make any assumptions about the form it actually takes in 
practice, since the value of the "To" header field is generally useless 
for processing purposes.

> b) because the call might have been retargeted by the PBX to a destination that is not one of the registered E.164 numbers.

I agree that this approach has shortcomings. We might not see eye-to-eye 
on what those shortcomings are, but as long as we all agree that this 
approach is sub-optimal, we can discard it and move on.

> Option 2: Any value ending in @10.1.2.3. The PBX could then choose a value that identifies the specific UA that accepted the call.
>    

I think you're making some (not universally true) assumptions here about 
the way the PBX behaves. In particular, you're assuming it will act as a 
B2BUA for all calls. And I acknowledge that the vast majority of PBXes 
do exactly this. For these PBXes, the approach you're describing would 
work fine.

Now, if someone wanted to deploy a PBX that acted as a proxy for some of 
its calls (which is exactly how the PBX we're using for our office 
works), then the contact URI would be whatever the terminal itself 
generated. Based on the relatively broad range of terminals I've played 
with, this contact URI will end up being some kind of cookie (like a 
line identifier) in the user part, and the phone's own IP address in the 
hostport part.

Since the PBX, in these kinds of environments, is often straddling a NAT 
boundary, it will usually need to Record-Route so that it stays in the call.

How all this works becomes much clearer if you look at the whole 
interaction instead of just the interaction between the PBX and the SSP:

                                            PBX              Terminal
Internet               SSP              192.0.2.3         10.20.30.127
     |                   |                   |                   |
     |                   |                   |                   |
     |                   |                   |                   |
     |INVITE sip:[email-masked]    |                   |
     |------------------>|                   |                   |
     |                   |                   |                   |
     |                   |                   |                   |
     |                   |INVITE sip:[email-masked]          |
     |                   |Record-Route:<sip:[email-masked]>
     |                   |------------------>|                   |
     |                   |                   |                   |
     |                   |                   |INVITE 
sip:[email-masked]
     |                   |                   |Record-Route: 
<sip:[email-masked]>
     |                   |                   
|Record-Route:<sip:[email-masked]>
     |                   |                   |------------------>|
     |                   |                   |200 OK             |
     |                   |                   |Record-Route: 
<sip:[email-masked]>
     |                   |                   
|Record-Route:<sip:[email-masked]>
     |                   |                   |Contact: 
<sip:[email-masked]>
     |                   |                   |<------------------|
     |                   |200 OK             |                   |
     |                   |Record-Route: <sip:[email-masked]> |
     |                   |Record-Route:<sip:[email-masked]>
     |                   |Contact: <sip:[email-masked]>     |
     |                   |<------------------|                   |
     |200 OK             |                   |                   |
     |Record-Route: <sip:[email-masked]> |                   |
     |Record-Route:<sip:[email-masked]>                |
     |Contact: <sip:[email-masked]>     |                   |
     |<------------------|                   |                   |
     |                   |                   |                   |
     |ACK sip:[email-masked]            |                   |
     |Route:<sip:[email-masked]>   |                   |
     |Route: <sip:[email-masked]>        |                   |
     |------------------>|                   |                   |
     |                   |                   |                   |
     |                   |                   |                   |
     |                   |ACK sip:[email-masked]            |
     |                   |Route: <sip:[email-masked]>        |
     |                   |------------------>|                   |
     |                   |                   |                   |
     |                   |                   |                   |
     |                   |                   |                   |
     |                   |                   |ACK sip:[email-masked]
     |                   |                   |------------------>|

I'll admit that's a bit hard to look at; here it is in a somewhat less 
cluttered form:

The thing that's kind of nice here is that this works for both the B2BUA 
case and for the proxy case.

In any case, I don't think we need to be proscriptive about this -- in 
general, having the PBX Record-Route will work; and, if B2BUA PBXes want 
to use a Contact that indicates their own IP address, they can do that.

> Option 3: I don't think the PBX would necessarily be able claim gruu properties for a contact URI in accordance with option 2, in which case if it needed a gruu, it would need to obtain one from th…

I go over GRUUs in the GIN draft. These GRUUs do actually have GRUU 
properties (which is the point) and can be used accordingly (including 
use in Contact header fields).

> In most cases it would reflect the value of the Request-URI. In some cases it could differ, if the request has already been retargeted.

Yes.

> Option 4: Of the form tel:+123456789

Keep in mind that an unauthenticated "From" URI  cannot generally be 
used for anything. Really. It can't.

So, it only makes sense to evaluate this question in the context of RFC 
4474, which actually gives some meaning to this value. In other words, 
the question about what we want to put in "From" comes down to how we 
want to treat identity.

I'm not sure MARTINI has to open that particular can of worms. However, 
I will make the following observations:

   1. Option 1 would be effectively impossible to apply RFC 4474 to, as
      I seriously doubt any legitimate CA will issue a cert asserting
      ownership of an IP address.

   2. Given the types of business relationships we're talking about, the
      entity that seems in the best position to make an assertion about
      the value in the "From" header field, which would mean that Option
      2 makes the most sense.

   3. Option 3 gets us mired back down into the domain conversation.
      Also, it would require the PBX operator to operate as a 4474
      authentication service, which seems extremely unlikely for these
      kinds of deployments.

   4. For option 4: we haven't even begun to get any kind of a grip on
      how to apply identity to naked phone numbers.

> Also, what if the request comes from a source that is not reachable by inbound requests, i.e., it is not from a registered E.164 number?

Using an analog to deployed ISDN-connected PBXes: if I call out from an 
internal extension that cannot be direct-dialed, the calling party ID 
presented to the called party will generally be the PBX's lead number. I 
would assume this is treated in the same way: if the request comes from 
a source that is not directly reachable by inbound requests, then the 
"From" header field will generally be the PBX's lead number. Subject to 
policy, configuration, etc.

> Similar considerations to Q4: In addition, option 2 looks suspect, because it would require the PBX to make an assertion on behalf of the SSP.
>    

I would really rather leave this out of scope for MARTINI. If some 
external body -- like SIPForum -- wants to define how this is done to be 
"SIP Connect 1.2 Compliant," then that's great. But I don't think the 
answer has an impact on the solution we choose, and I don't think we 
want to tackle those issues in MARTINI.

> Similar considerations to Q2, bearing in mind the source of the request might not be a UA bound to one of the registered E.164 numbers.

The answer here is pretty much identical to the answer I gave for Q2: 
the contact will come from the phone itself. The PBX can either 
Record-Route, or it can act as a B2BUA and mint a new contact with a 
state cookie that gives it a handle back to the correct device. I prefer 
the latter, but acknowledge that both can work -- and, as before, I see 
no reason to be proscriptive about how this works.

Really, once we've figured out how to route the first 
dialog-establishing request, all the Contact/Route/Record-Route 
shenanigans will Just Work. Making sure this particular thing works is 
one of the things we did pretty well in SIP.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 3 Feb 2010 18:12:00 +0100

Adam,

Thanks for your responses. Just a couple of things to pick up on.

Yes, of course you a right about contact/record-route. I meant to ask what would go in record-route in the non-B2BUA case, but I forgot. Presumably the PBX can put anything in the user part, as long as it keeps the same IP address that it registered in the host part?

Concerning From, I know that sometimes there is a practice of inserting the default value for the PBX if the request comes from off-PBX (i.e., if the caller is not reachable from the SP via that particular PBX), but that can often be misleading, so a value that can be reached via some other PBX (perhaps via some other SP) would also make sense. It comes down to policy whether the SP will accept that, but in principle it should be possible. This is probably a detail MARTINI doesn't need to be concerned with.

Also I am happy to keep PAI outside the scope of MARTINI, if others agree.

Concerning RFC 4474, what you seem to be saying is that the SP would have to sign the request, because the PBX would not have the necessary certificate. So it depends on transitive trust, i.e., the SP trusts the PBX to have trusted the UA. Of course, if the request has originated in a domain that has a domain name published in DNS and also a certificate, then signing can take place in that domain, and the Identity header field would simply be passed through the PBX to the service provider. But again, this is probably beyond the scope of our work.

John

________________________________
From: Adam Roach [mailto:[email-masked]]
Sent: 03 February 2010 16:27
To: Elwell, John
Cc: Paul Kyzivat; [email-masked]
Subject: Re: Further details around use case 3

John:

1. Inbound call to PBX.

PBX                     SSP

      180
      Contact: Q2 (see below)

      180
      Contact: Not relevant

Questions raised:

I would agree that it can have pretty much any value. I'm not sure we need to make any assumptions about the form it actually takes in practice, since the value of the "To" header field is generally useless for processing purposes.

I agree that this approach has shortcomings. We might not see eye-to-eye on what those shortcomings are, but as long as we all agree that this approach is sub-optimal, we can discard it and move on.

I think you're making some (not universally true) assumptions here about the way the PBX behaves. In particular, you're assuming it will act as a B2BUA for all calls. And I acknowledge that the vast majority of PBXes do exactly this. For these PBXes, the approach you're describing would work fine.

Now, if someone wanted to deploy a PBX that acted as a proxy for some of its calls (which is exactly how the PBX we're using for our office works), then the contact URI would be whatever the terminal itself generated. Based on the relatively broad range of terminals I've played with, this contact URI will end up being some kind of cookie (like a line identifier) in the user part, and the phone's own IP address in the hostport part.

Since the PBX, in these kinds of environments, is often straddling a NAT boundary, it will usually need to Record-Route so that it stays in the call.

How all this works becomes much clearer if you look at the whole interaction instead of just the interaction between the PBX and the SSP:

                                           PBX              Terminal
Internet               SSP              192.0.2.3         10.20.30.127
    |                   |                   |                   |
    |                   |                   |                   |
    |                   |                   |                   |
    |INVITE sip:[email-masked]    |                   |
    |------------------>|                   |                   |
    |                   |                   |                   |
    |                   |                   |                   |
    |                   |INVITE sip:[email-masked]          |
    |                   |Record-Route:<sip:[email-masked]><sip:[email-masked]>
    |                   |------------------>|                   |
    |                   |                   |                   |
    |                   |                   |INVITE sip:[email-masked]
    |                   |                   |Record-Route: <sip:[email-masked]><sip:[email-masked]>
    |                   |                   |Record-Route:<sip:[email-masked]><sip:[email-masked]>
    |                   |                   |------------------>|
    |                   |                   |200 OK             |
    |                   |                   |Record-Route: <sip:[email-masked]><sip:[email-masked]>
    |                   |                   |Record-Route:<sip:[email-masked]><sip:[email-masked]>
    |                   |                   |Contact: <sip:[email-masked]><sip:[email-masked]>
    |                   |                   |<------------------|
    |                   |200 OK             |                   |
    |                   |Record-Route: <sip:[email-masked]><sip:[email-masked]> |
    |                   |Record-Route:<sip:[email-masked]><sip:[email-masked]>
    |                   |Contact: <sip:[email-masked]><sip:[email-masked]>     |
    |                   |<------------------|                   |
    |200 OK             |                   |                   |
    |Record-Route: <sip:[email-masked]><sip:[email-masked]> |                   |
    |Record-Route:<sip:[email-masked]><sip:[email-masked]>                |
    |Contact: <sip:[email-masked]><sip:[email-masked]>     |                   |
    |<------------------|                   |                   |
    |                   |                   |                   |
    |ACK sip:[email-masked]            |                   |
    |Route:<sip:[email-masked]><sip:[email-masked]>   |                   |
    |Route: <sip:[email-masked]><sip:[email-masked]>        |                   |
    |------------------>|                   |                   |
    |                   |                   |                   |
    |                   |                   |                   |
    |                   |ACK sip:[email-masked]            |
    |                   |Route: <sip:[email-masked]><sip:[email-masked]>        |
    |                   |------------------>|                   |
    |                   |                   |                   |
    |                   |                   |                   |
    |                   |                   |                   |
    |                   |                   |ACK sip:[email-masked]
    |                   |                   |------------------>|

I'll admit that's a bit hard to look at; here it is in a somewhat less cluttered form:

The thing that's kind of nice here is that this works for both the B2BUA case and for the proxy case.

In any case, I don't think we need to be proscriptive about this -- in general, having the PBX Record-Route will work; and, if B2BUA PBXes want to use a Contact that indicates their own IP address, they can do that.

I go over GRUUs in the GIN draft. These GRUUs do actually have GRUU properties (which is the point) and can be used accordingly (including use in Contact header fields).

Yes.

Keep in mind that an unauthenticated "From" URI  cannot generally be used for anything. Really. It can't.

So, it only makes sense to evaluate this question in the context of RFC 4474, which actually gives some meaning to this value. In other words, the question about what we want to put in "From" comes down to how we want to treat identity.

I'm not sure MARTINI has to open that particular can of worms. However, I will make the following observations:

 1.  Option 1 would be effectively impossible to apply RFC 4474 to, as I seriously doubt any legitimate CA will issue a cert asserting ownership of an IP address.

 2.  Given the types of business relationships we're talking about, the entity that seems in the best position to make an assertion about the value in the "From" header field, which would mean that Option 2 makes the most sense.

 3.  Option 3 gets us mired back down into the domain conversation. Also, it would require the PBX operator to operate as a 4474 authentication service, which seems extremely unlikely for these kinds of deployments.

 4.  For option 4: we haven't even begun to get any kind of a grip on how to apply identity to naked phone numbers.

Using an analog to deployed ISDN-connected PBXes: if I call out from an internal extension that cannot be direct-dialed, the calling party ID presented to the called party will generally be the PBX's lead number. I would assume this is treated in the same way: if the request comes from a source that is not directly reachable by inbound requests, then the "From" header field will generally be the PBX's lead number. Subject to policy, configuration, etc.

I would really rather leave this out of scope for MARTINI. If some external body -- like SIPForum -- wants to define how this is done to be "SIP Connect 1.2 Compliant," then that's great. But I don't think the answer has an impact on the solution we choose, and I don't think we want to tackle those issues in MARTINI.

The answer here is pretty much identical to the answer I gave for Q2: the contact will come from the phone itself. The PBX can either Record-Route, or it can act as a B2BUA and mint a new contact with a state cookie that gives it a handle back to the correct device. I prefer the latter, but acknowledge that both can work -- and, as before, I see no reason to be proscriptive about how this works.

Really, once we've figured out how to route the first dialog-establishing request, all the Contact/Route/Record-Route shenanigans will Just Work. Making sure this particular thing works is one of the things we did pretty well in SIP.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 03 Feb 2010 13:25:10 -0600

On 2/3/10 11:12 AM, Elwell, John wrote:
> Yes, of course you a right about contact/record-route. I meant to ask 
> what would go in record-route in the non-B2BUA case, but I forgot. 
> Presumably the PBX can put anything in the user part, as long as it 
> keeps the same IP address that it registered in the host part?

That's correct. In fact, if it didn't have anything useful to squirrel 
away in there, it could omit the user portion completely.

> Concerning From, I know that sometimes there is a practice of 
> inserting the default value for the PBX if the request comes from 
> off-PBX (i.e., if the caller is not reachable from the SP via that 
> particular PBX), but that can often be misleading, so a value that can 
> be reached via some other PBX (perhaps via some other SP) would also 
> make sense. It comes down to policy whether the SP will accept that, 
> but in principle it should be possible.

Right. That's pretty much what I meant by the rather vague disclaimer 
"subject to policy, configuration, etc."

> This is probably a detail MARTINI doesn't need to be concerned with.

I agree 100%.

> Also I am happy to keep PAI outside the scope of MARTINI, if others agree.

It's a separable issue. Reducing scope decreases the time to develop a 
solution; increasing scope does the opposite. If we're in the hurry that 
some people seem to think we are, then we should eliminate all separable 
issues from our work items.

> Concerning RFC 4474, what you seem to be saying is that the SP would 
> have to sign the request, because the PBX would not have the necessary 
> certificate.

I'm saying that my understanding of the types of environments we're 
interested in -- based primarily on Richard Shockey's characterization 
of target markets -- is that they will not generally have these kinds of 
certs.

> So it depends on transitive trust, i.e., the SP trusts the PBX to have 
> trusted the UA.

Yep. Not much way around that.

> Of course, if the request has originated in a domain that has a domain 
> name published in DNS and also a certificate, then signing can take 
> place in that domain, and the Identity header field would simply be 
> passed through the PBX to the service provider.

True. But if all of the above is true, I'm boggled as to why the 
customer you describe is using MARTINI instead of normal SIP peering.

> But again, this is probably beyond the scope of our work.

Exactly -- that's what I meant when I said that MARTINI probably doesn't 
need to open up this can of worms. (I'm personally keeping an eye on 
things to make sure we don't do anything to *break* the ability to do 
4744 in the future, but I don't think the WG needs to spell out exactly 
how this is handled or by whom.)

/a

>     *From:* Adam Roach [mailto:[email-masked]]
>     *Sent:* 03 February 2010 16:27
>     *To:* Elwell, John
>     *Cc:* Paul Kyzivat; [email-masked]
>     *Subject:* Re: Further details around use case 3
>
>     John:
>
>>            INVITEsip:[email-masked]
>>            To: Q1 (see below)
>>            From: Not relevant
>>            PAI: Not relevant
>>            Contact: Not relevant
>>     In principle, it could be any value, since the request may have been retargeted to the PBX. However, in the most common case I would expect it to have a URI of the formsip:[email-masked];useer=phone.
>>        
>
>     I would agree that it can have pretty much any value. I'm not sure
>     we need to make any assumptions about the form it actually takes
>     in practice, since the value of the "To" header field is generally
>     useless for processing purposes.
>
>     I agree that this approach has shortcomings. We might not see
>     eye-to-eye on what those shortcomings are, but as long as we all
>     agree that this approach is sub-optimal, we can discard it and
>     move on.
>
>     I think you're making some (not universally true) assumptions here
>     about the way the PBX behaves. In particular, you're assuming it
>     will act as a B2BUA for all calls. And I acknowledge that the vast
>     majority of PBXes do exactly this. For these PBXes, the approach
>     you're describing would work fine.
>
>     Now, if someone wanted to deploy a PBX that acted as a proxy for
>     some of its calls (which is exactly how the PBX we're using for
>     our office works), then the contact URI would be whatever the
>     terminal itself generated. Based on the relatively broad range of
>     terminals I've played with, this contact URI will end up being
>     some kind of cookie (like a line identifier) in the user part, and
>     the phone's own IP address in the hostport part.
>
>     Since the PBX, in these kinds of environments, is often straddling
>     a NAT boundary, it will usually need to Record-Route so that it
>     stays in the call.
>
>     In any case, I don't think we need to be proscriptive about this
>     -- in general, having the PBX Record-Route will work; and, if
>     B2BUA PBXes want to use a Contact that indicates their own IP
>     address, they can do that.
>
>
>     I go over GRUUs in the GIN draft. These GRUUs do actually have
>     GRUU properties (which is the point) and can be used accordingly
>     (including use in Contact header fields).
>
>>     Option 1: Of the formsip:[email-masked]. But this is a contact URI.
>>     Option 2: Of the formsip:[email-masked];user=phone.
>>     Option 3: Of the formsip:[email-masked];user=phone. But this brings back the whole argument about domain names.
>     So, it only makes sense to evaluate this question in the context
>     of RFC 4474, which actually gives some meaning to this value. In
>     other words, the question about what we want to put in "From"
>     comes down to how we want to treat identity.
>
>     I'm not sure MARTINI has to open that particular can of worms.
>     However, I will make the following observations:
>
>        1. Option 1 would be effectively impossible to apply RFC 4474
>           to, as I seriously doubt any legitimate CA will issue a cert
>           asserting ownership of an IP address.
>
>        2. Given the types of business relationships we're talking
>           about, the entity that seems in the best position to make an
>           assertion about the value in the "From" header field, which
>           would mean that Option 2 makes the most sense.
>
>        3. Option 3 gets us mired back down into the domain
>           conversation. Also, it would require the PBX operator to
>           operate as a 4474 authentication service, which seems
>           extremely unlikely for these kinds of deployments.
>
>        4. For option 4: we haven't even begun to get any kind of a
>           grip on how to apply identity to naked phone numbers.
>
>
>
>     Using an analog to deployed ISDN-connected PBXes: if I call out
>     from an internal extension that cannot be direct-dialed, the
>     calling party ID presented to the called party will generally be
>     the PBX's lead number. I would assume this is treated in the same
>     way: if the request comes from a source that is not directly
>     reachable by inbound requests, then the "From" header field will
>     generally be the PBX's lead number. Subject to policy,
>     configuration, etc.
>
>     external body -- like SIPForum -- wants to define how this is done
>     to be "SIP Connect 1.2 Compliant," then that's great. But I don't
>     think the answer has an impact on the solution we choose, and I
>     don't think we want to tackle those issues in MARTINI.
>
>     The answer here is pretty much identical to the answer I gave for
>     Q2: the contact will come from the phone itself. The PBX can
>     either Record-Route, or it can act as a B2BUA and mint a new
>     contact with a state cookie that gives it a handle back to the
>     correct device. I prefer the latter, but acknowledge that both can
>     work -- and, as before, I see no reason to be proscriptive about
>     how this works.
>
>     shenanigans will Just Work. Making sure this particular thing
>     works is one of the things we did pretty well in SIP.
>
>     /a
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 03 Feb 2010 13:26:50 -0600

On 2/3/10 10:26 AM, Adam Roach wrote:
> The PBX can either Record-Route, or it can act as a B2BUA and mint a 
> new contact with a state cookie that gives it a handle back to the 
> correct device. I prefer the latter...

Yikes. That was a bad typo. I meant "I prefer the former." In other 
words, I think the Record-Routing approach is far cleaner. But both 
work, and I see no reason to prohibit one or the other.

/a

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 03 Feb 2010 12:37:50 -0800

Regarding the difference between use cases 1/3 and 2/4, if there's a 
chance that people start passing these URIs around, presumably customers 
would have a strong preference for 2 and 4 where they get to advertise 
their own domain names. In other words, if I run pan-am.com I'd rather 
put sip:[email-masked] on my business card than 
sip:[email-masked].

Anders

On 2/2/2010 12:32 AM, Elwell, John wrote:
> Adam,
> That's great that you have taken the trouble to enumerate these
> different cases. Talking from a PBX perspective, I think you are correct
> in saying that all would get the job done. Inevitably there are some I
> dislike.
> I dislike 5/5a because of the implications of making REGISTER work with
> tel URIs (and also tel URIs tend not to be used so much today on PBXs,
> in my opinion).
> I dislike 6, because the PBX can't do anything with the received
> Request-URI - strictly speaking it would have to route it back to the SP.
> I dislike 7, for the same reason, plus the known difficulties with
> extracting information from History-Info (I have my doubts whether the
> present effort to revise History-Info will really solve its problems).
> I suppose you could have a use case 8, which is a kind of combination of
> 2 and 6. So you start of with sip:[email-masked] and deliver
> the same Request-URI, together with Route: sip:[email-masked]. This
> was what I had in mind pre-MARTINI. It solves the problem of 6, but
> still has the issues of 2.
> reaches the SP. Is this an issue for MARTINI? Or put it another way, if
> we provide a solution for case 1, does this stop people implementing
> case 2? Similarly for cases 3 and 4: if we provide a solution for case
> 3, does this stop people implementing case 4?
> So this narrows it down to cases 1 and 3. The recent "Implications"
> thread seemed to be homing in on a solution that would give both 1 and
> 3, which sounds reasonable to me. I am not convinced that there is a
> problem with case 1's by-passing RFC 3263 procedures.
> John
>
>     *From:* [email-masked] [mailto:[email-masked]]
>     *On Behalf Of *Adam Roach
>     *Sent:* 01 February 2010 23:46
>     *To:* [email-masked]
>     that even when we can decide on a fairly narrow scope ("phone
>     numbers only"), the system behavior that people expect appears to
>     vary literally from person to person.
>
>     I'm going to try to do something like I did before with the
>     diagrams, this time focusing on just what happens for E.164 numbers.
>     I'll continue with using the same dead companies as before
>     (CentricVoice as the SSP, and Pan-Am as the PBX).
>
>     numbers means that these kinds of use cases are not under discussion
>     at the moment:
>
>
>     <Out Of Scope>
>
>     So, ignoring those, we seem to still have a huge disconnect on what
>     the SSP needs to be able to do as a result of the MARTINI
>     operations. Now, one of the nice things we get from E.164 numbers is
>     that usernames now become unique. We can specify transformations
>     such that the username that arrives at the SSP stays the same as it
>     passes through the SSP. Unlike my earlier examples, I'm going to
>     assume that limiting to E.164 enables this kind of trivial
>     transformation. Not in the *general* case, of course -- only for
>     MARTINI-routed E.164 numbers.
>
>        2. This use case is necessary for the architecture {I am/my
>     Frankly, I would expect almost everyone will be able to place each
>     use case in category #1. All of these solutions certainly allow the
>     PBX to figure out who the call is supposed to be sent to, and that
>     appears to be the key criteria for the inbound messages.
>
>     In this use case, the SSP receives a URI indicating its own domain.
>     The SSP is provisioned to know that +12145550105 belongs to Pan-Am.
>     Having received information from Pan-Am about its PBX's IP address,
>     it changes the domain to "pan-am.com," keeps the user ID, ignores
>     RFC 3263 procedures, and sends the request to the MARTINI-registered
>     IP address it has for Pan-Am.
>
>     pan-am.com. Having received information from Pan-Am about its PBX's
>     IP address, it leaves the Request-URI alone, ignores RFC 3263
>     procedures, and sends the request to the MARTINI-registered IP
>     address it has for Pan-Am.
>
>     take the E.164 number "+12145550105" and figure out that it needs to
>     go to the domain "pan-am.com". I emphasize this because I know some
>     people are interested in models in which is tenable to track "phone
>     number to SSP" mapping, while the relatively larger number of "phone
>     number to end customer" mappings might be unpalatable.
>
>        2. Ambiguity around which SIP nodes are "responsible for"
>           pan-am.com (in the RFC 3261 sense of that word). Cullen had a
>           litmus test for this: is CentricVoice allowed to redirect
>           calls for pan-am.com to a voicemail server or answering service?
>
>
>     Given that 3261 lacks a formal description of "responsible for," we
>     can potentially define the problem of "responsible for" away (as
>     Keith has proposed) -- but I'm pretty certain it's not within
>     MARTINI's scope to clarify the terms appearing in RFC 3261. I think
>     that would need to go back to DISPATCH, and I doubt we want to wait
>     for such an effort to complete.
>
>     SSP is provisioned to know that +12145550105 belongs to Pan-Am.
>     Having received information from Pan-Am about its PBX's IP address,
>     it changes the domain to that registered IP address (192.168.17.25),
>     keeps the user ID, correctly invokes RFC 3263 procedures, and sends
>     the request to the resulting host (192.168.17.25).
>
>     for bulk registrations (even though it is functionally identical to
>     the model deployed for single registrations).
>
>     pan-am.com. Having received information from Pan-Am about its PBX's
>     IP address, it changes the domain to that registered IP address
>     drawbacks discussed to date, other than differing from the model
>     that is currently deployed for bulk registrations (even though it is
>     functionally identical to the model deployed for single
>     registrations). However, it is predicated on an external entity --
>     take the E.164 number "+12145550105" and figure out that it needs to
>     go to the domain "pan-am.com".
>
>     In this use case, the SSP receives a URI indicating its own domain.
>     The SSP is provisioned to know that +12145550105 belongs to Pan-Am.
>     It changes the R-URI to a tel: URI containing only the E.164 number
>     in question. Having received information from Pan-Am about its PBX's
>     IP address, it sends the request to the resulting host
>     (192.168.17.25). Since the URI in question is a TEL URI, RFC3263
>     issues are avoided altogether, eliminating any alt-root considerations.
>
>     ability to register TEL URIs, which is currently normatively
>     forbidden by RFC 3261. While this is tractable, it would require
>     companion work in SIPCORE to relax this normative requirement. It
>     also would likely require more mechanism than other approaches,
>     since we're effectively adding on a new URI-to-host address
>     resolution procedure.
>
>     ================
>     Use Case 5a
>     ================
>
>     This is effectively the exact same procedure as Use Case 5; however,
>     it may make contact registration somewhat easier (depending on the
>     exact mechanism used to communicate domain IP addresses).
>
>     its own domain. The SSP is provisioned to know that +12145550105
>     belongs to Pan-Am. It pushes the MARTINI-registered contact into the
>     route set, leaves the Request-URI unmodified, invokes RFC 3263
>     procedures (on the Route) and sends the request to the resulting host.
>
>     These changes necessarily require intermediaries who are a party to
>     the REGISTER transaction (e.g., using Path and/or Service-Route) to
>     Proxy-Require to avoid the ensuing problems. Using a method other
>     than REGISTER eliminates this class of problems.
>
>     Request-URI indicates a domain this element is not responsible for,
>     the Request-URI MUST be placed into the target set as the only
>     target, and the element MUST proceed to the task of Request
>     Forwarding." In practice, I imagine it wants to route it to one of
>     its internal extensions.
>
>     Similar to use case 6, except the SSP swaps out the registered
>     Contact URI for the Request-URI, and squirrels the incoming R-URI
>     (containing the phone number) away in a History-Info header field.
>
>     behavior. Drawbacks include defining concrete procedures around
>     which History-Info entry to use (which is a problem the 4244bis
>     draft is currently struggling with), especially in the case that
>     there are intermediaries between the SSP and the PBX. We would also
>     be creating a normative dependency on the 4244bis document, which
>     may delay a final delivery of MARTINI work substantially.
>
>
>     focus. Clearly just saying "phone numbers" is not sufficient. Look
>     back over how you rated each of the use cases relative to the
>     "sufficient," "necessary but not sufficient," and "neither necessary
>     nor sufficient" criteria. I think you'll find that, if you were
>     honest with yourself, all or most of these use cases fall into the
>     first category. I'm not saying you *like* them all -- merely that
>     they will get the job done, if push were to come to shove.
>
>     So, I think we need to pick one and work on the mechanism required
>     to enable it. And I think we need to be vigilant against scope
>     creep. As we get into mechanism, it will be overwhelmingly tempting
>     to say, "oh, but we can add on Use Case X if we just do *this* small
>     thing!" But those small things can spiral out of control.
>
>     All other things being equal, I have a strong preference for Use
>     Case 3, as its only real drawback is that it varies from the
>     demonstrably flawed ^[1] mechanism that showed up on the IETF's
>     doorstep. Any other approach is going to require interested parties
>     coming to consensus on the issues associated with the other use
>     cases, and I think we've seen that won't be a very fast process.
>
>     /a
>
>     [1] Lest this offend anyone as being too general a criticism, I
>     refer to the set of shortcomings enumerated here:

---

From: Adam Roach <[email-masked]>
Date: Wed, 03 Feb 2010 14:57:19 -0600

On 2/3/10 2:37 PM, Anders Kristensen wrote:
> chance that people start passing these URIs around, presumably 
> customers would have a strong preference for 2 and 4 where they get to 
> advertise their own domain names. In other words, if I run pan-am.com 
> I'd rather put sip:[email-masked] on my business card than 

I would be /mortified/ to put either on my business card. What goes on 
my business card would be "sip:[email-masked]" or something 
similar. But that's a different kettle of fish.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Feb 2010 16:51:31 -0500

> similar. But that's a different kettle of fish.

I don't know why you should be *mortified*.

IMO it would make much more sense to put:

tel:+1-214-555-0105
email:[email-masked]
sip:[email-masked]

And yes, I would put the punctuation in the tel:, and I would expect 
that to work too.

And it might be inferred that sip:[email-masked] might work 
too. That might also be listed on the card, but would be a tad geeky.

This is also my obsession with From values. (Substitute PAID if that is 
what you use in your environment.) Namely, if you call me, I will hope 
my phone will capture your URI in its call history, and that I will then 
be able to use it to call you back. So whatever I get there ought to 
work for that purpose. I realize that it may be a lie, just as callerid 
might be a lie. But if I want to call you back, and that is what you 
gave me, it still seems like the most appropriate thing to use.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Thu, 4 Feb 2010 23:51:33 -0600

> only adds a name resolution step.

Not necessarily true. Third party registration is perfectly valid  
(although somewhat useless with Outbound).

It's also possible that an intervening proxy will cause the request to  
reach the registrar in a packet sourced from a different IP address,  
so in general requiring that the name used in the Contact resolve to  
the address from which the request was received is not a feasible  
solution.

--
Dean