Subject: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini))

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 8 Apr 2010 16:54:32 +0200

On Thu, Apr 8, 2010 at 4:45 PM, Hadriel Kaplan <[email-masked]>wrote:

>
> >   You've discussed changing the user portion below. Can you clarify why
> > the user portion would change in the Shaken approach?
>
> I explained it in the hitchhiker's guide.  It was not in draft-shaken, just
> like it's not in ETSI/3gpp/et-al.  But it actually makes a ton of sense, imo
> - so I was going to suggest we add it to draft-shaken, because normalizing
> the user name isn't that hard and does not require per-name or per-pbx
> config.  And it is a relatively common interop issue, which I failed to add
> to the "problems" draft.
>
>
Which entity would be responsible for that in your view?

/Hans Erik van Elburg

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Apr 2010 11:48:47 -0400

The resolving SSP proxy - i.e., the one that does the location-service lookup using the normalized form as the key.
(in IMS language, the S-CSCF)

Today I know SBC's do it (a LOT), and I assume other devices do it as well.  If the S-CSCF/Reg-proxy doesn't do it we'd be happy to do it for them. :)
But really it should be done there, imho.

-hadriel

________________________________________
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Thursday, April 08, 2010 10:55 AM

/Hans Erik van Elburg

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Apr 2010 12:08:11 -0400

> But really it should be done there, imho.

I agree with Hadriel.

Fundamentally, when a server is responsible for the domain of an 
incoming R-URI, and is retargeting to a URI in another domain, it needs 
to be careful to select a valid URI in the target domain. The most 
straightforward way to do this is to simply select from among URIs it 
was given. That is what a registrar/location service normally supports. 
In that case the user portion of the URI is presumed to be valid because 
it was minted by a server responsible for the domain of that URI.

In the gin case the full URI isn't specified. Rather only the domain 
portion is explicitly specified, while the user portion is *implied* and 
is defined by some service agreement between the pbx and the SP.

But its unlikely (and IMO undesirable) that the service agreement will 
specify every possible representation variation on the supported numbers 
that the SP may accept in incoming requests. Hence there will be a need 
to reformat some incoming numbers.

I think we have agreed that the scope is limited to E.164 numbers. Given 
that, I would expect that the URIs used to reach the pbx will then 
contain E.164 format. And its probably a good idea to specify further 
that the E.164 format will not contain any separator characters, thus 
yielding a single representation for each number.

Its important that the syntax be limited, because the pbx may need to 
use a portion of the username space for other URIs, that must not 
collide with incoming ones designating registered numbers.

	Thanks,
	Paul

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

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 8 Apr 2010 18:40:17 +0200

If I find a SIP URI that contains a E.164 number i.e.
[email-masked];user=phone
there is no need to normalize.

Do you mean that you also want to be able to handle 24764;phone-context=+
[email-masked];user=phone and normalise that to the previous form?

Or are you thinking:
- about local numbers?
- about alphanumeric SIP uri's that are to be interpreted as numbers, as
they are lacking the user=phone parameter.

I would expect martini compliant PBX's to understand SIP numbers URI's in
the sense of 3261/3966, i.e. with user=phone and to be 3966 compliant i.e:
- to start with a + for international number format
- to contain a phone-context for local numbers, without a starting +

So martini compliant pbx should not show the same diversity in what it
accepts as being a number as that what is currently in the field.

/Hans Erik van Elburg

On Thu, Apr 8, 2010 at 5:48 PM, Hadriel Kaplan <[email-masked]>wrote:

>
> The resolving SSP proxy - i.e., the one that does the location-service
> lookup using the normalized form as the key.
> Today I know SBC's do it (a LOT), and I assume other devices do it as well.
>  If the S-CSCF/Reg-proxy doesn't do it we'd be happy to do it for them. :)

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Apr 2010 13:01:50 -0400

What I expect and what I see in the field are two different things. :)

What I see in the field is that IP-PBX's often do not understand RFC3966 very well at all.  I would assume, however, that if we say "E.164 format" in whatever spec, that they would do E.164 format.

Unfortunately, RFC3966 allows all of the following E.164 user formats:
+12125551212
+1(212)555-1212
+1(212)5551212
Etc.

And we actually see those, in the field, and they cause interop issues, in the field. (it was frankly a mistake for RFC3966 to do this, imo, but that's another topic for another day)

But more importantly, what the Reg-proxy actually *gets* is also often not E.164 to begin with.  It processes received target URIs as E.164 based on local policy transformation/translation rules, and logically converts them to E.164 internally, if not also externally.  That's all fine/legal/etc.  To be useful to an IP-PBX which expects E.164, that internal transform has to actually change the user name in the request-URI itself.  Thus *in practice*, the reg-proxy often will be changing the request-uri based on local policy rules *anyway*.  Ergo, the user name and domain name are both changing.

-hadriel

________________________________________
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Thursday, April 08, 2010 12:40 PM
To: Hadriel Kaplan
Cc: Brian Lindsay; [email-masked]
Subject: Re: number normalization (was Re: [martini] Changing the domain (was: Hitchhiker's Guide to MakingMartini))

If I find a SIP URI that contains a E.164 number i.e. [email-masked];user=phone there is no need to normalize.

Do you mean that you also want to be able to handle 24764;phone-context=[email-masked];user=phone and normalise that to the previous form?

Or are you thinking:
- about local numbers?
- about alphanumeric SIP uri's that are to be interpreted as numbers, as they are lacking the user=phone parameter.

I would expect martini compliant PBX's to understand SIP numbers URI's in the sense of 3261/3966, i.e. with user=phone and to be 3966 compliant i.e:
- to start with a + for international number format
- to contain a phone-context for local numbers, without a starting +

So martini compliant pbx should not show the same diversity in what it accepts as being a number as that what is currently in the field.

/Hans Erik van Elburg

On Thu, Apr 8, 2010 at 5:48 PM, Hadriel Kaplan <[email-masked]> wrote:

-hadriel

/Hans Erik van Elburg

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 8 Apr 2010 19:02:05 +0200

The question remains is what needs to be specified. I am not disagreeing,
but it is not entirely clear what to agree with at the moment.

The easy part seems to be specify clearly how the PBX shall receive numbers.
So that it is clear for PBX vendors what to do.

What formats incoming formats the SSP shall accept gets already more fuzzy.
Do we need to specify that or does it suffice to say what the martini
compliant PBX has to understand?

/Hans Erik van Elburg

On Thu, Apr 8, 2010 at 6:08 PM, Paul Kyzivat <[email-masked]> wrote:

>> Today I know SBC's do it (a LOT), and I assume other devices do it as
>> well.  If the S-CSCF/Reg-proxy doesn't do it we'd be happy to do it for
>> them. :)
> Fundamentally, when a server is responsible for the domain of an incoming
> R-URI, and is retargeting to a URI in another domain, it needs to be careful
> to select a valid URI in the target domain. The most straightforward way to
> do this is to simply select from among URIs it was given. That is what a
> registrar/location service normally supports. In that case the user portion
> of the URI is presumed to be valid because it was minted by a server
> responsible for the domain of that URI.
>
> portion is explicitly specified, while the user portion is *implied* and is
> defined by some service agreement between the pbx and the SP.
>
> that the SP may accept in incoming requests. Hence there will be a need to
> reformat some incoming numbers.
>
> that, I would expect that the URIs used to reach the pbx will then contain
> E.164 format. And its probably a good idea to specify further that the E.164
> format will not contain any separator characters, thus yielding a single
> representation for each number.
>
> Its important that the syntax be limited, because the pbx may need to use a
> portion of the username space for other URIs, that must not collide with
> incoming ones designating registered numbers.
>
>        Thanks,
>        Paul
>
>  -hadriel
>>
>> From: Hans Erik van Elburg [mailto:[email-masked]] Sent:
>> Thursday, April 08, 2010 10:55 AM
>>
>>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 8 Apr 2010 19:08:02 +0200

Hi Paul,

On Thu, Apr 8, 2010 at 6:08 PM, Paul Kyzivat <[email-masked]> wrote:

> Did we? Not so sure that we did.

> What do you mean? (to advanced for me:-D "the pbx may need to use a portion
of the username space for other URIs")

/Hans Erik

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Apr 2010 13:20:40 -0400

When you say "What formats incoming formats the SSP shall accept" do you mean accept from the IP-PBX, or you mean in general globally?

I don't think there's any point in specifying what the SSP should expect to get in general globally. (and even if we tried it would never fly)  I'm dubious about doing it for requests from IP-PBX's too.

-hadriel

________________________________________
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Thursday, April 08, 2010 1:02 PM
To: Paul Kyzivat
Cc: Hadriel Kaplan; [email-masked]
Subject: Re: [martini] number normalization (was Re: Changing the domain (was: Hitchhiker's Guide to MakingMartini))

The question remains is what needs to be specified. I am not disagreeing, but it is not entirely clear what to agree with at the moment.

The easy part seems to be specify clearly how the PBX shall receive numbers. So that it is clear for PBX vendors what to do.

What formats incoming formats the SSP shall accept gets already more fuzzy. Do we need to specify that or does it suffice to say what the martini compliant PBX has to understand?

/Hans Erik van Elburg

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 8 Apr 2010 19:21:00 +0200

On Thu, Apr 8, 2010 at 7:01 PM, Hadriel Kaplan <[email-masked]>wrote:

> And we actually see those, in the field, and they cause interop issues, in
> the field. (it was frankly a mistake for RFC3966 to do this, imo, but that's
> another topic for another day)
>
This is clear and can be specified.

> But more importantly, what the Reg-proxy actually *gets* is also often not
> E.164 to begin with.  It processes received target URIs as E.164 based on
> local policy transformation/translation rules, and logically converts them
> to E.164 internally, if not also externally.  That's all fine/legal/etc.

That is fine but hard to specify.

>  To be useful to an IP-PBX which expects E.164, that internal transform has
> to actually change the user name in the request-URI itself.  Thus *in
> practice*, the reg-proxy often will be changing the request-uri based on
> local policy rules *anyway*.  Ergo, the user name and domain name are both
> changing.
>
> QED.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 8 Apr 2010 19:28:10 +0200

On Thu, Apr 8, 2010 at 7:20 PM, Hadriel Kaplan <[email-masked]>wrote:

>
> When you say "What formats incoming formats the SSP shall accept" do you
> mean accept from the IP-PBX, or you mean in general globally?
>
> I ment arriving at the SSP for delivery to the PBX, but you alread answered
that in another mail.

We havent touched what the SSP accepts from the PBX, but I would expect that
what we specify as acceptable format to deliver to the PBX, will also be the
format that we expect on calls from the PBX to the SSP.

> I don't think there's any point in specifying what the SSP should expect to
> get in general globally. (and even if we tried it would never fly)  I'm
> dubious about doing it for requests from IP-PBX's too.
>
> I agree, thats why I asked as it was not clear to me to what level you
where wanting to take this.But you clarified that in your other mail.

> Subject: Re: [martini] number normalization (was Re: Changing the domain
> (was: Hitchhiker's Guide to MakingMartini))
>
> The easy part seems to be specify clearly how the PBX shall receive
> numbers. So that it is clear for PBX vendors what to do.
>

---

From: "Brian Lindsay" <[email-masked]>
Date: Thu, 8 Apr 2010 13:44:15 -0400

Hi,

   I wonder though if normalizing/canonicalizing/constraining RFC3966 allowable syntax (for example) is something that MARTINI needs to deal with, or if it would be better left to something like the SIP Connect which covers a wide gamut of interconnect recommendations.

   Regards
       Brian

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Thursday, April 08, 2010 1:02 PM
To: Hans Erik van Elburg
Cc: Lindsay, Brian (CAR:AR00); [email-masked]
Subject: RE: number normalization (was Re: [martini] Changing the domain (was: Hitchhiker's Guide to MakingMartini))

-hadriel

Or are you thinking:
- about local numbers?

/Hans Erik van Elburg

Today I know SBC's do it (a LOT), and I assume other devices do it as well.  If the S-CSCF/Reg-proxy doesn't do it we'd be happy to do it for them. :) But really it should be done there, imho.

-hadriel

/Hans Erik van Elburg

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 8 Apr 2010 21:24:33 +0200

Yet again having to convert to plain text before replying - sigh!

The other form of E.164 number a SSP might need to normalise is one that is not fully qualified, e.g., a national number, or when with dialled prefix digits.

Also, what is more important to nail down is what an entity must send - on receipt an entity can be more liberal, but obvious must be able to accept the format that the other entity is required to send.

John 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
> Sent: 08 April 2010 18:21
> To: Hadriel Kaplan
> Cc: [email-masked]
> Subject: Re: [martini] number normalization (was Re: Changing 
> the domain (was: Hitchhiker's Guide to MakingMartini))
> 
> On Thu, Apr 8, 2010 at 7:01 PM, Hadriel Kaplan 
> <[email-masked]> wrote:
> 
> 
> 
> 
> 	And we actually see those, in the field, and they cause 
> interop issues, in the field. (it was frankly a mistake for 
> RFC3966 to do this, imo, but that's another topic for another day)
> 	
> 
> 	But more importantly, what the Reg-proxy actually 
> *gets* is also often not E.164 to begin with.  It processes 
> received target URIs as E.164 based on local policy 
> transformation/translation rules, and logically converts them 
> 	 To be useful to an IP-PBX which expects E.164, that 
> internal transform has to actually change the user name in 
> the request-URI itself.  Thus *in practice*, the reg-proxy 
> often will be changing the request-uri based on local policy 
> rules *anyway*.  Ergo, the user name and domain name are both 
> changing.
> 	
> 
> 
> QED.
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Apr 2010 16:09:48 -0400

> The other form of E.164 number a SSP might need to normalise is one that is not fully qualified, e.g., a national number, or when with dialled prefix digits.

John, while I realize those are used a lot, they aren't E.164 numbers.
They *could* be telephone-subscriber format (e.g. 
sip:2125551234;phone-context=[email-masked];user=phone)

But that form, while valid, isn't E.164 and it explicitly is *not* 
equivalent to sip:[email-masked];user=phone.

> Also, what is more important to nail down is what an entity must send - on receipt an entity can be more liberal, but obvious must be able to accept the format that the other entity is required to…

I agree. I don't think we need to specify what the SSP must be able to 
convert *from* - only that it should convert *to* cannonical E.164 (no 
separators) when retargeting *to* the pbx according to martini.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 8 Apr 2010 22:18:13 +0200

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 08 April 2010 21:10
> To: Elwell, John
> Cc: Hans Erik van Elburg; Hadriel Kaplan; [email-masked]
> > The other form of E.164 number a SSP might need to 
> normalise is one that is not fully qualified, e.g., a 
> national number, or when with dialled prefix digits.
> 
[JRE] Well, whether they are E.164 or not is moot - the fact is an SSP might convert a national number, say into a fully qualified E.164 number for delivery to the SIP-PBX.

> 
> 
> > Also, what is more important to nail down is what an entity 
> must send - on receipt an entity can be more liberal, but 
> obvious must be able to accept the format that the other 
> entity is required to send.
> 
[JRE] I was really talking about what the SIP-PBX is able to receive. It clearly would have to receive a canonical E.164 number from the SSP, but can of course be more liberal.

John

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 8 Apr 2010 22:38:04 +0200

Being liberal is good in theory. But I still think it would be beneficial if
we specify what a PBX is minimally required to handle, so that an SSP can
trust that if it uses that format all connected martini pbx's can and will
handle it as intended.

/Hans Erik van Elburg

On Thu, Apr 8, 2010 at 10:18 PM, Elwell, John <
[email-masked]> wrote:

> [JRE] I was really talking about what the SIP-PBX is able to receive. It
> clearly would have to receive a canonical E.164 number from the SSP, but can
> of course be more liberal.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 8 Apr 2010 16:21:47 -0500

Exactly. I don't see us prohibiting a PBX from accepting something else :-) 
but we do need a minimum requirement.

Spencer

----- Original Message ----- 
From: Hans Erik van Elburg
To: Elwell, John
Cc: [email-masked] ; Hadriel Kaplan
Sent: Thursday, April 08, 2010 3:38 PM
Subject: Re: [martini] number normalization (was Re: Changing the 
domain(was: Hitchhiker's Guide to MakingMartini))

/Hans Erik van Elburg

On Thu, Apr 8, 2010 at 10:18 PM, Elwell, John 
<[email-masked]> wrote:

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 9 Apr 2010 09:35:33 +0200

Yes, of course, and obviously it has to accept what we mandate the other side to send, as I thought I made clear in an earlier message.

John 

> From: Spencer Dawkins [mailto:[email-masked]] 
> Sent: 08 April 2010 22:22
> To: Hans Erik van Elburg; Elwell, John
> Cc: [email-masked]; Hadriel Kaplan
> the domain(was: Hitchhiker's Guide to MakingMartini))
>

---

From: <[email-masked]>
Date: Mon, 12 Apr 2010 09:54:48 +0200

Hi,

Just for my clarification, when talking about what a martini PBX should be able to receive, which headers are we talking about ?
The "format" to be received might be different in Request-URI and FROM header for example.

Kind regards

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: 08 April 2010 23:22
To: Hans Erik van Elburg; Elwell, John
Cc: Hadriel Kaplan; [email-masked]
Subject: Re: [martini] number normalization (was Re: Changing the domain(was: Hitchhiker's Guide to MakingMartini))

Spencer

----- Original Message ----- 
From: Hans Erik van Elburg
To: Elwell, John
Cc: [email-masked] ; Hadriel Kaplan
Sent: Thursday, April 08, 2010 3:38 PM
Subject: Re: [martini] number normalization (was Re: Changing the 

/Hans Erik van Elburg

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

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 12 Apr 2010 11:55:17 +0200

Jan,

I think we are only talking about the Request-URI here.

John 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 12 April 2010 08:55
> To: [email-masked]; [email-masked]; Elwell, John
> Cc: [email-masked]; [email-masked]
> Subject: RE: [martini] number normalization (was Re: Changing 
> Just for my clarification, when talking about what a martini 
> PBX should be able to receive, which headers are we talking about ?
> [mailto:[email-masked]] On Behalf Of Spencer Dawkins

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 12 Apr 2010 12:20:04 +0200

I think this thread is heading here into over specification.

All the examples given by Hadriel are syntactically valid forms of RFC 3966 and the PBX should be able to handle them. If we think there are interoperability problems with that, then someone should update RFC 3966, rather than fiddle with it in Martini. 

However I suspect there is no interoperability problem except a tendency to sloppy implementation. We might just as well specify that abbreviated forms of header field names should not be used, as they are a second way of specifying the same thing.

regards

Keith

> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: Thursday, April 08, 2010 6:02 PM
> To: Hans Erik van Elburg
> Cc: [email-masked]
> What I see in the field is that IP-PBX's often do not 
> understand RFC3966 very well at all.  I would assume, 
> however, that if we say "E.164 format" in whatever spec, that 
> they would do E.164 format.
> 
> But more importantly, what the Reg-proxy actually *gets* is 
> also often not E.164 to begin with.  It processes received 
> target URIs as E.164 based on local policy 
> to E.164 internally, if not also externally.  That's all 
> fine/legal/etc.  To be useful to an IP-PBX which expects 
> E.164, that internal transform has to actually change the 
> user name in the request-URI itself.  Thus *in practice*, the 
> reg-proxy often will be changing the request-uri based on 
> local policy rules *anyway*.  Ergo, the user name and domain 
> name are both changing.
> 
> -hadriel
> 
> Subject: Re: number normalization (was Re: [martini] Changing 
> [email-masked];user=phone there is no need to normalize.
> 
> Do you mean that you also want to be able to handle 
> 24764;phone-context=[email-masked];user=phone and normalise 
> that to the previous form?
> 
> Or are you thinking:
> - about local numbers?
> - about alphanumeric SIP uri's that are to be interpreted as 
> numbers, as they are lacking the user=phone parameter.
> 
> I would expect martini compliant PBX's to understand SIP 
> numbers URI's in the sense of 3261/3966, i.e. with user=phone 
> and to be 3966 compliant i.e:
> So martini compliant pbx should not show the same diversity 
> in what it accepts as being a number as that what is 
> currently in the field.
> 
> /Hans Erik van Elburg
> 
> The resolving SSP proxy - i.e., the one that does the 
> location-service lookup using the normalized form as the key.
> Today I know SBC's do it (a LOT), and I assume other devices 
> do it as well.  If the S-CSCF/Reg-proxy doesn't do it we'd be 
> happy to do it for them. :) But really it should be done there, imho.
> 
> -hadriel
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Apr 2010 10:43:15 -0400

> I think we are only talking about the Request-URI here.

Well, that may be the first order of business.
But there are issues with others also. For instance, whatever the callee 
uses to identify the caller (From or P-Asserted-ID) could also be 
problematic unless it is normalized by somebody.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 12 Apr 2010 09:50:29 -0500

On 4/12/10 9:43 AM, Paul Kyzivat wrote:
> But there are issues with others also. For instance, whatever the 
> callee uses to identify the caller (From or P-Asserted-ID) could also 
> be problematic unless it is normalized by somebody.

Maybe, but I don't think that's in MARTINI's scope.

But it's a pretty weak "maybe" anyway. Keep in mind that "From" can't be 
changed after the caller creates it. Any "normalization" would need to 
take place at the UAC, so we're kind of limited in what we can do here 
anyway.

Also recall that "From" is meaningless as an identifier unless you're 
also using RFC 4474. There's a well-known and completely different can 
of worms that arises from the interaction between 4474 and E.164 
numbers. And MARTINI is emphatically not the place to address that issue.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Apr 2010 11:17:59 -0400

yeah, ok, I agree its not a martini thing.

	Thanks,
	Paul

---

From: Victor Pascual Avila <[email-masked]>
Date: Mon, 12 Apr 2010 17:26:03 +0200

On Mon, Apr 12, 2010 at 4:50 PM, Adam Roach <[email-masked]> wrote:
> Also recall that "From" is meaningless as an identifier unless you're also
> using RFC 4474. There's a well-known and completely different can of worms
> that arises from the interaction between 4474 and E.164 numbers. And MARTINI
> is emphatically not the place to address that issue.

+1 Martini is not the place for such a discussion.

Cheers,
-- 
Victor Pascual Ávila

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 12 Apr 2010 12:17:15 -0400

Hi Jan,
Just the Request-URI.  I know people have problems with From (and To, and PAI, and Diversion/Hist-Info, etc.) but there's no way to change a From/To in a Proxy.  I'm just trying to address as much as we can legally address.  And the first order of priority is making sure the IP-PBX at least knows what the target of the request is. :)

Maybe what we should do is put in language in the draft to remind folks that the To/From/PAI/etc. can be of various flavors/formats, and hope for the best?

-hadriel

> Sent: Monday, April 12, 2010 3:55 AM
> 
> Just for my clarification, when talking about what a martini PBX should be
> able to receive, which headers are we talking about ?

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 12 Apr 2010 13:08:20 -0400

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Monday, April 12, 2010 6:20 AM
> 
> All the examples given by Hadriel are syntactically valid forms of RFC
> 3966 and the PBX should be able to handle them. If we think there are
> interoperability problems with that, then someone should update RFC 3966,
> rather than fiddle with it in Martini.

We're NOT fiddling with it - we're bypassing it altogether.  [draft-gin] isn't specifying a specific 3966 translation rule to get rid of visual-separators or whatever in req-uri phone numbers, it's just saying "do what rfc3261 does and replace the req-uri with the contact-uri".  

As a matter of fact, the IP-PBX doesn't have to support RFC 3966 to begin with!  How do you even know the IP-PBX supports rfc3966 when you send it the request?  

> However I suspect there is no interoperability problem except a tendency
> to sloppy implementation. We might just as well specify that abbreviated
> forms of header field names should not be used, as they are a second way
> of specifying the same thing.

No that's not analogous.  

For one thing, there's a level of interop problems beyond which it's no longer "sloppy implementation", but bad protocol design/spec.  Honestly, rfc3966 fits in the latter (well really rfc2806).  Allowing human-display visual-separators to be mixed into a resource address used by machines for identification and routing is simply mind-boggling.

Secondly, GOOD protocol specs use a model of "strict on send, liberal on receipt".  Just because the receiver *should* support Foo, doesn't mean the sender should assume it if it can avoid doing so.  For some things (many things) the assumption can't be avoided.  But we have the opportunity to avoid it here. 

And let's be honest - it's not like the SSP's Proxy isn't going to be changing the req-uri user name a lot *anyway*.  Unless you really believe every request it receives has a full E.164 in the user portion.  That's not the real world, afaict.  People don't type full E.164's into their phone a lot.  They type something which needs to be translated anyway, because they type a dial-string for all intents and purposes.

-hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 12 Apr 2010 19:47:16 +0200

On Mon, Apr 12, 2010 at 7:08 PM, Hadriel Kaplan <[email-masked]>wrote:

> We're NOT fiddling with it - we're bypassing it altogether.  [draft-gin]
> isn't specifying a specific 3966 translation rule to get rid of
> visual-separators or whatever in req-uri phone numbers, it's just saying "do
> what rfc3261 does and replace the req-uri with the contact-uri".
>
> As a matter of fact, the IP-PBX doesn't have to support RFC 3966 to begin
> with!  How do you even know the IP-PBX supports rfc3966 when you send it the
> request?
>
> Why not isn't that part of it saying hey I am martini compliant???

> For one thing, there's a level of interop problems beyond which it's no
> longer "sloppy implementation", but bad protocol design/spec.  Honestly,
> rfc3966 fits in the latter (well really rfc2806).  Allowing human-display
> visual-separators to be mixed into a resource address used by machines for
> identification and routing is simply mind-boggling.
>
Agree.

> Secondly, GOOD protocol specs use a model of "strict on send, liberal on
> receipt".  Just because the receiver *should* support Foo, doesn't mean the
> sender should assume it if it can avoid doing so.  For some things (many
> things) the assumption can't be avoided.  But we have the opportunity to
> avoid it here.
>
Agree, but the sender is not the SSP. The sender is the originating UA,
these devices are not martini compliant.

> And let's be honest - it's not like the SSP's Proxy isn't going to be
> changing the req-uri user name a lot *anyway*.  Unless you really believe
> every request it receives has a full E.164 in the user portion.  That's not
> the real world, afaict.  People don't type full E.164's into their phone a
> lot.  They type something which needs to be translated anyway, because they
> type a dial-string for all intents and purposes.
>
That is problematic. If the originating domain would just comply with
RFC3966, in the sense of "strict on send, liberal on receipt". Then there
was no need on the SSP serving the terminating party to fix things. In fact
having the terminating SSP fix things makes the unknow of what has to be
fixed a lot larger as it could mean that you need to fix whatever device
there exists in the universe is sending at a PBX served by that SSP.

I have nothing against filtering human-display-visual-separators, as they
dont carry any useful information. And if they create more succesful calls
why not? The question is of course if we need to specify that as part of a
trunking solution.

This makes me believe that Keith has a point. If we believe RFC3966 has an
issue we should start create RFC3966bis and refer that from the martini
specification. Or just live with RFC3966 and demand that martini compliant
PBX implement it correctly.

/Hans Erik van Elburg

---

From: <[email-masked]>
Date: Tue, 13 Apr 2010 09:17:13 +0200

Well, in my simple mind I assume the IP-PB expects the Request-URI to match what he used to REGISTER, right ?
So, whatever you decide on what the "network" should send to the IP-PBX, the "network" will also receive this in REGISTER messages (unless we talk about registrationless operation)

Jan Van Geel 

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: 12 April 2010 18:17
To: VAN GEEL Jan (ITN/NIS); [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [martini] number normalization (was Re: Changing the domain(was: Hitchhiker's Guide to MakingMartini))

Hi Jan,

-hadriel

**** DISCLAIMER ****