Subject: Re: [martini] The IETF versus reality (was: problems withexistingSIP trunking solutions)

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Tue, 6 Apr 2010 21:27:30 -0400

Agreed

________________________________

From: [email-masked] <[email-masked]> 
To: Adam Roach <[email-masked]> 
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]> 
Sent: Tue Apr 06 21:13:36 2010
Subject: Re: [martini] The IETF versus reality (was: problems withexistingSIP trunking solutions) 

I think most people are willing to investigate and accept technical fixes as long as there arguments are taken seriously and can agree that issues raised are really issues. 

Now where are the issues "the routing and URI issues in the ETSI/3GPP solution" enumerated? Then we can address them one by one. Apparently some people have joined the discussion after the wg already hummed to some preliminary conclusion, it does not harm to reiterate those. If these are all really issues I guess we are all lead to the same conclusion in some way.

Another way forward could be that martini recognises that its main task is the definition of a SIP protocol extension for signalling the SIP trunking variant, that the PBX supports. That would solve the main issues that are presented in the requirements document. I have nothing against such a framework also describing the GIN variant as one of the alternatives. If it is so good for pure SIP proxy implementations, why not?  

There is another alternative that is that martini only creates a SIP forum specific solution, nothing wrong with that. But then please state it in the title and make this an informative draft.  This will allow you to do a quick and expedient specification and people will let you do. Thats how other SDO's also need to do their extensions, as they are building walled garden solutions...

/Hans Erik van Elburg

On Wed, Apr 7, 2010 at 12:01 AM, Adam Roach <[email-masked]> wrote:

	On 4/6/10 15:46, Apr 6, Christer Holmberg wrote:

		The ETSI/3GPP solution has been has been part of the discussion more or less all the way from the beginning of the work, so I don't it's fair that it has now suddenly came up, and therefor we have wasted our time.

	You missed my point. I'll rephrase what I was trying to say: if we're just re-publishing someone else's mechanism as-is, then all the work in DISPATCH and all the work in DREGS was a terrible waste of time. If the problem is already solved and working, then we didn't (and don't) need to do anything.
	
	I think discussion of the IMS solution is perfectly reasonable, as long as people are willing to investigate and accept technical fixes to the issues that have been raised on the list. But that's not happening. Somehow, people think that slapping an options tag into the ETSI/3GPP solution will magically fix all its issues. You have enough SIP background that you should know that's simply not the case.
	
	So, until someone shows the initiative to actually tackle the routing and URI issues in the ETSI/3GPP solution, it's a non-starter. I fear, however, that the very property that the advocates of that solution hold most dear is quite precisely the property that makes it run afoul core SIP routing behavior.
	
	/a

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