Subject: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 31 Mar 2010 11:35:05 +0200

Hi Hadriel,

(Changed the thread name.)

Is your point that the use of a loose-route to the PBX as such is not so
much of a problem, but that SSP's would use it to deliver Request-URI's
containing the SSP's domain to the IP-PBX?

BR,
/Hans Erik van Elburg

On Wed, Mar 31, 2010 at 9:26 AM, <[email-masked]> wrote:

>
>
>  ------------------------------
> *De :* Hadriel Kaplan [mailto:[email-masked]]
> *Envoyé :* mardi 30 mars 2010 20:35
> *À :* CHATRAS Bruno RD-CORE-ISS; [email-masked];
> [email-masked]; [email-masked]
> *Cc :* [email-masked]
> *Objet :* RE: [martini] #21: 3.2.2 describes an issue with some PBX
>
>
>   ------------------------------
>
> *From:* [email-masked] [mailto:
> [email-masked]]
> *Sent:* Tuesday, March 30, 2010 1:16 PM
> *To:* Hadriel Kaplan; [email-masked]; [email-masked];
> [email-masked]
> *Cc:* [email-masked]
> *Subject:* RE: [martini] #21: 3.2.2 describes an issue with some PBX
>
>
>
> OK. If loose-route was implemented in some of these IMS networks (I guess I
> know at least one of them) and you had to modify the R-URI on a per-trunk
> basis, it just means that some of the IP-PBXs connected to them were not
> IMS-compliant. Quite predictable as this loose-route mechanism is relatively
> new and therefore not yet available on all systems. Similarly, if a network
> implements the GIN solution, you will have to modify the R-URI on per-trunk
> basis because some of the IP-PBXs will be loose-route compliant and will
> therefore not be GIN-compliant. Where is the improvement compared to the
> current situation?
>
>
>
> Because then for the GIN-compliant devices you know they’re GIN compliant
> from their signaling.  There is no per-trunk guessing/config for the
> GIN-compliant case.  It’s true that some operators will have legacy
> IP-PBX’s, but now they’ll know which ones are *not* legacy anymore – right
> now they don’t.  They don’t know when an IP-PBX gets upgraded to support
> IMS, and they don’t know whether it is IMS to begin with.
>
>
>
> The current situation isn’t that bad, when dealing with medium-to-large
> Enterprise trunks.  Provisioning is fine for that.  But in SIP-Connect 1.1
> we were faced with trying to handle/support the large-volume small-business
> trunk case, and for that we’re trying to keep provisioning as low as
> possible, in as few systems as possible.  And we needed the tools to help
> find mismatches.  Hence the option-tag.
>
>
>
> Personally I was hoping to just take IMS/ETSI and add the option-tag and
> minor tweaks – that was the “shaken” draft in essence
> [==>BC:] Yes I remember that and would have preferred going down this
> route.
>
>  , but the WG was split and we needed to move forward.  And GIN really
> isn’t that much different either – is there something you’d like to see in
> GIN to make it more like the ETSI/IMS mechanism?
> [==>BC:] Of course. I would like the R-URI to contain the initial target
> identity rather than this special contact address.
>
>
>
> -hadriel
>
> p.s. Actually my guess is that even if all sides think they’re IMS
> compliant, that we’d have to re-write the req-uri on a case-by-case basis.
> Because it’s not clear what it should be.  Is the domain-portion the PBX
> gets supposed to be “ssp.com”, or “pbx.com”?  Is it either/both?  Could it
> be “ims.ssp.com”, or even “s-cscf.ssp.com”?
> [==>BC:] The domain portion can be "xxx.ssp.com" or "xxx.entreprise.com"
> with the understanding that the DNS maps "xxx.entreprise.com" to the SSP's
> network entry point.
>
>
>
>  Because those last two type/forms of host/domain names appear in the
> request-uri of requests received at the S-CSCF all the time in some IMS
> networks, so if IMS “loose-route” literally means
> “do-not-touch-the-request-uri”, it will be fraught with issues.
>
>
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 31 Mar 2010 09:52:49 -0400

Hi,
I'm not sure I understand the question exactly.
My only point was that in practice we've found that what IP-PBX's expect to receive in the request-uri is inconsistent, and that even if the IP-PBX thinks it is following the ETSI model it's not clear what it will or should expect to get.
But really we're also focusing too much on this particular issue I think - there're other reasons to have the options-tag.

-hadriel

________________________________
From: Hans Erik van Elburg [mailto:[email-masked]]
Sent: Wednesday, March 31, 2010 5:35 AM
To: [email-masked]
Cc: Hadriel Kaplan; [email-masked]; [email-masked]; [email-masked]
Subject: Issue with existing SIP trunking solutions, was Re: [martini] #21: 3.2.2 describes an issue with some PBX

Hi Hadriel,

Is your point that the use of a loose-route to the PBX as such is not so much of a problem, but that SSP's would use it to deliver Request-URI's containing the SSP's domain to the IP-PBX?

BR,
/Hans Erik van Elburg

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 31 Mar 2010 16:06:55 +0200

Hi Hadriel,

People say there is a mistake in the ETSI/3GPP solution that martini is
addressing. I'm only trying to see if there really is a mistake or if this
is just an opinion about a design choice being made. I am not yet convinced
that it is a mistake.

Also I think we need to be fair on this, martini is not addressing the
issues with existing solutions and fixing them, it is creating a new
solution trying to avoid some issues with existing solutions. That is a
different approach.

I think nobody denies the need for an option tag. In fact having an option
tag for the IMS method would make sense. And would fix an issue with that
solution.

/Hans Erik van Elburg

On Wed, Mar 31, 2010 at 3:52 PM, Hadriel Kaplan <[email-masked]>wrote:

>
>
> Hi,
>
> I’m not sure I understand the question exactly.
>
> My only point was that in practice we’ve found that what IP-PBX’s expect to
> receive in the request-uri is inconsistent, and that even if the IP-PBX
> thinks it is following the ETSI model it’s not clear what it will or should
> expect to get.
>
> But really we’re also focusing too much on this particular issue I think –
> there’re other reasons to have the options-tag.
>
>
>
> -hadriel
>
>
> *From:* Hans Erik van Elburg [mailto:[email-masked]]
> *Sent:* Wednesday, March 31, 2010 5:35 AM
> *To:* [email-masked]
> *Cc:* Hadriel Kaplan; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Issue with existing SIP trunking solutions, was Re: [martini]
> #21: 3.2.2 describes an issue with some PBX
>
>
>
> Hi Hadriel,
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Mar 2010 23:15:50 +0200

Hi,

I agree with Hans Erik.

If it is about issues within existing solutions, wouldn't it be better to try to address those (by communicating with 3GPP/ETSI) instead of defining a completely new mechanism?

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
Sent: 31. maaliskuuta 2010 17:07
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX

Hi Hadriel,

People say there is a mistake in the ETSI/3GPP solution that martini is addressing. I'm only trying to see if there really is a mistake or if this is just an opinion about a design choice being made. I am not yet convinced that it is a mistake.

Also I think we need to be fair on this, martini is not addressing the issues with existing solutions and fixing them, it is creating a new solution trying to avoid some issues with existing solutions. That is a different approach.

I think nobody denies the need for an option tag. In fact having an option tag for the IMS method would make sense. And would fix an issue with that solution.

/Hans Erik van Elburg

On Wed, Mar 31, 2010 at 3:52 PM, Hadriel Kaplan <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

-hadriel

________________________________
From: Hans Erik van Elburg [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, March 31, 2010 5:35 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Hadriel Kaplan; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Issue with existing SIP trunking solutions, was Re: [martini] #21: 3.2.2 describes an issue with some PBX

Hi Hadriel,

BR,
/Hans Erik van Elburg

---

From: Dean Willis <[email-masked]>
Date: Wed, 31 Mar 2010 18:36:24 -0500

On Mar 31, 2010, at 8:52 AM, Hadriel Kaplan wrote:

> My only point was that in practice we’ve found that what IP-PBX’s  
> expect to receive in the request-uri is inconsistent, and that even  
> if the IP-PBX thinks it is following the ETSI model it’s not clear  
> what it will or should expect to get.
> But really we’re also focusing too much on this particular issue I  
> think – there’re other reasons to have the options-tag.

The ETSI model for PBX behavior is currently underspecified. The IETF  
model is currently unspecified: we think of PBXes as big phones, and  
our phone model is underspecified.

You expected this stuff to actually work without a more rigid interop  
spec?

And yeah, we need the options-tag anyhow.

--
Dean (who expects to be struck by a meteor tomorrow, just after the  
alarm clock goes off, and will be pleasantly surprised if it doesn't,  
assuming he hasn't died first of something else and is therefore  
unable to appreciate having not been hit by a meteor).