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

From: <[email-masked]>
Date: Thu, 1 Apr 2010 10:38:30 +0200

I agree as well of course!

________________________________

	De : [email-masked] [mailto:[email-masked]] De la part de Christer Holmberg
	Envoyé : mercredi 31 mars 2010 23:16
	À : 'Hans Erik van Elburg'; Hadriel Kaplan
	Cc : [email-masked]
	Objet : Re: [martini] Issue with existing SIP trunking solutions, was Re: #21: 3.2.2 describes an issue with some PBX

	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]> 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,
		
		(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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Apr 2010 11:01:53 +0200

Hi, 

>>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. 

That is not completely true.

It is true that 3GPP do not specify what happens inside the PBX (which is also true for IETF).

However, 3GPP does specify the interface that is used between a UE and the core network, and that interface is used as base also for the PBX.

Regards,

Christer

> 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).
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 1 Apr 2010 11:06:49 -0400

No thank you.  Some of us  want to get this done before the next US
presidential election. 

Both specifications have "issues" but with an well understood option tag the
problems go away and BTW if it didn't  take a full RFC to get a option tag
this WG would never have been formed.

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Christer Holmberg
Sent: Wednesday, March 31, 2010 5:16 PM
To: 'Hans Erik van Elburg'; 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,

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]>
wrote:

Hi,

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: Christer Holmberg <[email-masked]>
Date: Sat, 3 Apr 2010 10:30:51 +0200

Hi,
 
>No thank you.  Some of us  want to get this done before the next US presidential election.  

Is that a valid argument for not trying to re-use things? Can we use that argument in other IETF WGs also? :)

Also, I guess it is then ok for other SDOs (e.g. 3GPP) to start defining their own protocol extensions etc, instead of bringing them to IETF - simply based on the argument (whether it's true or not) that it will take too long to do it in IETF... 

Also, based on what argument do you think it would take a long time to do this with 3GPP/ETSI?

In addition, as indicated by Keith a number of times, the current IETF solution lacks a number of features, which the 3GPP/ETSI solution provides.

>Both specifications have "issues" but with an well understood option tag the problems go away and BTW if it didn't  take a full RFC to get a option tag this WG would never have been formed.

The problem does not go away if you end up having to implement two solutions - no matter if you have an option tag to indicate which is used or not.

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Wednesday, March 31, 2010 5:16 PM
To: 'Hans Erik van Elburg'; 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,

I agree with Hans Erik.

Regards,

Christer

Hi Hadriel,

/Hans Erik van Elburg

Hi,

-hadriel

Hi Hadriel,

BR,
/Hans Erik van Elburg

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 3 Apr 2010 13:09:05 -0400

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Saturday, April 03, 2010 4:31 AM
> To: 'Richard Shockey'; 'Hans Erik van Elburg'; Hadriel Kaplan
> 
> 
> Also, I guess it is then ok for other SDOs (e.g. 3GPP) to start defining
> their own protocol extensions etc, instead of bringing them to IETF -
> simply based on the argument (whether it's true or not) that it will take
> too long to do it in IETF...

Umm... you do realize that is what some folks believe happened in this case, right?
Some folks view ETSI's usage of a loose-route model for Registered contacts as conflicting with the current 3261 model.  (i.e., extending it)
Personally I think a good lawyer could make the case it isn't, but we couldn't get consensus to go that way.

> Also, based on what argument do you think it would take a long time to do

I think he meant in the context of your suggested "communicating changes with 3gpp".  I too have been told that trying to coordinate changes/updates to specs with both IETF and 3GPP at the same time through liaisons takes a long time.

And it _would_ still require something to be published in the IETF.  There are plenty of SIP networks in existence which are not IMS, and won't be IMS.

-hadriel 
p.s. And I'm not disparaging IMS (most of my revenue comes from IMS!) - but it's not the only game in town.  IP-PBX SIP trunks need to work with any SSP network architecture.

---

From: <[email-masked]>
Date: Tue, 6 Apr 2010 10:22:46 +0200

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Hadriel Kaplan
> Envoyé : samedi 3 avril 2010 19:09
> À : Christer Holmberg; 'Richard Shockey'; 'Hans Erik van Elburg'
> Cc : [email-masked]
> Objet : Re: [martini] Issue with existing SIP trunking 
> solutions, was Re: #21: 3.2.2 describes an issue with some PBX
> 
> 
> 
> > Also, I guess it is then ok for other SDOs (e.g. 3GPP) to start 
> > defining their own protocol extensions etc, instead of 
> bringing them 
> > to IETF - simply based on the argument (whether it's true 
> or not) that 
> > it will take too long to do it in IETF...
> 
> Some folks view ETSI's usage of a loose-route model for 
> Registered contacts as conflicting with the current 3261 
> model.  (i.e., extending it) Personally I think a good lawyer 
> could make the case it isn't, but we couldn't get consensus 
> to go that way.
>  
> 
> > Also, based on what argument do you think it would take a 
> long time to 
> > do this with 3GPP/ETSI?
> 
> I think he meant in the context of your suggested 
> "communicating changes with 3gpp".  I too have been told that 
> trying to coordinate changes/updates to specs with both IETF 
> and 3GPP at the same time through liaisons takes a long time.
> 
> And it _would_ still require something to be published in the 
> IETF.  There are plenty of SIP networks in existence which 
> are not IMS, and won't be IMS.
> 
> -hadriel
> p.s. And I'm not disparaging IMS (most of my revenue comes 
> from IMS!) - but it's not the only game in town.  IP-PBX SIP 
> trunks need to work with any SSP network architecture.

BC: The solution documented in 3GPP/ETSI specifications would work with a different architecture than the IMS. We should actually refrain from calling it "IMS solution" as this sows confusion is people's mind.

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 7 Apr 2010 10:19:17 +0200

Bruno,

So the essential aspects of the 3GPP/ETSI solution, without unnecessary IMS baggage, would need to be made available as an I-D. However, bear in mind that we had two earlier drafts, Dregs/Stirred and Shaken, which were found to be lacking, so any new draft would need to differentiate itself from those. In my opinion, the gin draft, while not in line with some existing implementations, is not far away from some other implementations, and seems to meet requirements, particularly in terms of not breaking core SIP or DNS architecture. So it is my hope that we can progress that draft, and in the absence of a competing proposal the gin draft does indeed appear to be the way forward.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 06 April 2010 09:23
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [martini] Issue with existing SIP trunking 
> BC: The solution documented in 3GPP/ETSI specifications would 
> work with a different architecture than the IMS. We should 
> actually refrain from calling it "IMS solution" as this sows 
> confusion is people's mind.
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Apr 2010 12:44:52 +0200

Hi, 

>So the essential aspects of the 3GPP/ETSI solution, without 
>unnecessary IMS baggage, would need to be made available as 
>an I-D. However, bear in mind that we had two earlier drafts, 
>Dregs/Stirred and Shaken, which were found to be lacking, so 
>any new draft would need to differentiate itself from those. 

A draft is never perfect/complete from the beginning - that is why we discuss them and submit new versions :)

Regards,

Christer

>In my opinion, the gin draft, while not in line with some 
>existing implementations, is not far away from some other 
>implementations, and seems to meet requirements, particularly 
>in terms of not breaking core SIP or DNS architecture. So it 
>is my hope that we can progress that draft, and in the 
>absence of a competing proposal the gin draft does indeed 
>appear to be the way forward.
> 
> John
> 
> 
> solutions, was 
> > Re: #21: 3.2.2 describes an issue with some PBX
> > 
> >  
> > 
> > > Envoyé : samedi 3 avril 2010 19:09 À : Christer Holmberg; 
> 'Richard 
> > > Shockey'; 'Hans Erik van Elburg'
> > > Cc : [email-masked]
> > > Objet : Re: [martini] Issue with existing SIP trunking solutions, 
> > > was Re: #21: 3.2.2 describes an issue with some PBX
> > > 
> > > 
> > > 
> Registered 
> > > contacts as conflicting with the current 3261 model.  (i.e., 
> > > extending it) Personally I think a good lawyer could make 
> the case 
> > > it isn't, but we couldn't get consensus to go that way.
> > >  
> > >