Subject: [martini] Need for a SIP/SDP profile for SIP trunking , was Re: #21: 3.2.2 describes an issue with some PBX

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 31 Mar 2010 13:28:42 +0200

Yes, I agree with that observation.

Only solving the routing issue does not solve the overall problem. For that
a minimum SIP/SDP profile needs to be agreed upon. Also what are common
denominator as codec for voice, fax, dtmf etc.

The question rises if there should be an option tag to signal support for a
profile instead of only signalling what routing method is preferred.

BR,
/Hans Erik van Elburg

On Wed, Mar 31, 2010 at 1:18 PM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

>  So assuming that this text is accepted, I guess the key argument of
> providing this distinction is not that both behaviours are non-standard, but
> that some means is needed to distinguish the two.
>
> While I do not have a problem with that specifically, I still have an issue
> that providing some signalling to do this solves all the issues. There are
> all sorts of other issues associated with what the PBX "expects" that also
> cause all sorts of issues, such as whether it expects a tel URI in tel URI
> format or SIP URI format, and so on, that are not signalled.
>
> Therefore at the end of the day, one is still going to end up with
> configuration information at either end of this interface that is not
> explicitly signalled, and in the absence of both sides having preconfigured
> knowledge of that information, the interface is not going to work.
>
> regards
>
> Keith
>
>  ------------------------------
>  *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Elwell, John
> *Sent:* Tuesday, March 30, 2010 6:11 PM
> *To:* Hans Erik van Elburg
>
> *Cc:* [email-masked]
> *Subject:* Re: [martini] #21: 3.2.2 describes an issue with some PBX
>
>  OK, fixed in my working copy.
>
> John
>
>  ------------------------------
> *From:* Hans Erik van Elburg [mailto:[email-masked]]
> *Sent:* 30 March 2010 11:49
> *To:* Elwell, John
> *Cc:* [email-masked]
> *Subject:* Re: [martini] #21: 3.2.2 describes an issue with some PBX
>
> Hi John,
>
> Inline...
>
> /Hans Erik van Elburg
>
> On Mon, Mar 29, 2010 at 9:55 PM, Elwell, John <
> [email-masked]> wrote:
>
>> Hans Erik,
>>
>> I think the point you are trying to make is that it is not one-sided. The
>> fact is, each side has different ways of working, and you need to have the
>> two sides operating in compatible manners for it to work. In practice, I
>> think there are other variants, besides the two cited in the present 3.2.2.
>
> Yes. And there is no objective way to automatically determine what variant
> the PBX or the SSP is supporting. Which is what an options tag could
> resolve.
>
>
>> I would suggest:
>>
>>        <t>Even where all information needed by the SIP-PBX is provided, in
>> some deployments inbound SIP requests from the SSP have the registered
>> Contact URI in the Request-URI, whereas in other deployments inbound SIP
>> requests have the intended target (AOR) in the Request-URI and the Contact
>> URI in the Route header field. There are other variants too.
>> Interoperability problems arise when a PBX designed for or configured for
>> one variant attempts to interwork with an SSP designed for or configured for
>> another variant.</t>
>>
> Yes, slightly modified to add the objective means issue:
>  <t>Even where all information needed by the SIP-PBX is provided, in some
> deployments inbound SIP requests from the SSP have the registered PBX
> Contact URI in the Request-URI, whereas in other deployments inbound SIP
> requests have the intended target PBX user (AOR) in the Request-URI and the
> Contact URI in the Route header field. There are other variants too.
> Interoperability problems arise when a PBX designed for or configured for
> one variant attempts to interwork with an SSP designed for or configured for
> another variant. There is currently no objective means in the signalling
> during registration for either party to discover what mechanism the other
> side supports.</t>
>
>
>> To accompany this, I think the title of the section should be changed too:
>> "Inconsistent placement of information in inbound requests"
>>
>> Yes, slightly modified to make it more specific: "Inconsistent placement
> of target URI information in inbound requests".
>
>
>> John
>>
>> > -----Original Message-----
>> > From: Hans Erik van Elburg [mailto:[email-masked]]
>>  > Sent: 29 March 2010 17:27
>> > To: Elwell, John
>> > Cc: [email-masked]
>> > Subject: Re: [martini] #21: 3.2.2 describes an issue with some PBX
>> >
>> > Hi John,
>> >
>> > I was just trying to find a text that describes the issue.
>> >
>> > But now the issue reads like "some PBX like apples, some like
>> > bananas". To me that does not sound like a usefull issue to
>> > describe in an RFC.
>> >
>> > So I think one or two more sentence would make clear why this
>> > is an issue.
>> >
>> > I think there is multiple underlying issues here:
>> > - PBX have different SIP profiles or all SIP-PBX are different
>> > - PBX support SIP trunking flavour A, or support SIP trunking
>> > flavour B
>> > - SSP systems don't know what mechanism the PBX support (can
>> > be resolved with explicit indicator, this draft proposes an
>> > indicator for flavour B but for another purpose it seems)
>> > - PBX do not know what SIP trunking flavour the SSP supports
>> > (not addressed it seems)
>> >
>> > I don't seem to have a lucky hand with proposing an improved
>> > text, so maybe you should have a go at it.
>> >
>> > BR,
>> > /Hans Erik van Elburg
>> >
>> > p.s. I never said or implied that a SIP-PBX shall implement
>> > IMS. But it would be really, really, really good if they
>> > would interwork on the UNI with the IMS business trunking.  I
>> > think that should also be in your interest and in fact you
>> > have been part of that work...
>> >
>> >
>> >
>> > On Mon, Mar 29, 2010 at 5:56 PM, Elwell, John
>> > <[email-masked]> wrote:
>> >
>> >
>> >       Hans Erik,
>> >
>> >       As an individual, I disagree with the proposed text,
>> > since it is misleading. The "international standards" to
>> > which you prefer are standards specific to an IMS
>> > environment. The implication of the wording as proposed is
>> > that SIP-PBXs ought to implement IMS specifications. And as
>> > Hadriel points out, implementing those IMS specifications
>> > does not eliminate the problems that the SIPconnect people
>> > are trying to solve. I believe the existing text in draft-03
>> > is sufficient.
>> >
>> >
>> >       John
>> >
>> >       > -----Original Message-----
>> >       > From: Hans Erik van Elburg [mailto:[email-masked]]
>> >
>> >       > Sent: 26 March 2010 23:03
>> >       > To: Elwell, John
>> >       > Cc: [email-masked]
>> >       > Subject: Re: [martini] #21: 3.2.2 describes an issue
>> > with some PBX
>> >       >
>> >       > I will not argue with you about the validity of that argument.
>> >       >
>> >       > Can you agree to the modified text?
>> >       >
>> >       > "Request-URI vs. loose-route acceptance
>> >       > Some IP-PBX do not implement international standards or SIP
>> >       > profiles for SIP trunking. As a consequence some SIP-PBXs
>> >       > expect that inbound SIP requests from the SSP will have the
>> >       > registered Contact-URI in the Request-URI, and thus not
>> >       > interoperate with the loose-route scheme of 3GPP and ETSI.
>> >       > Other SIP-PBXs are fine with the Request-URI being the
>> >       > intended target, but cannot handle receiving a Route header
>> >       > field identifying their registered Contact-URI as a
>> >       > loose-route entry."
>> >       >
>> >       > BR,
>> >       > /Hans Erik van Elburg
>> >       >
>> >       >
>> >       > On Fri, Mar 26, 2010 at 9:03 PM, Elwell, John
>> >       > <[email-masked]> wrote:
>> >       >
>> >       >
>> >       >       The IETF does not have a mechanism, and that is the
>> >       > reason for the MARTINI work. In particular, the IETF has not
>> >       > published the so-called loose-route mechanism. Hence the
>> >       > reason for the IETF, as owner of SIP, to publish a mechanism
>> >       > for bulk registrations.
>> >       >
>> >       >       John
>> >       >
>> >       >
>> >       >       > -----Original Message-----
>> >       >       > From: Hans Erik van Elburg
>> > [mailto:[email-masked]]
>> >       >       > Sent: 26 March 2010 02:21
>> >       >       > To: [email-masked]
>> >       >       > Cc: Elwell, John; [email-masked]
>> >       >       > Subject: Re: [martini] #21: 3.2.2 describes an issue
>> >       > with some PBX
>> >       >       >
>> >       >       >
>> >       >       > Then you should rephrase to what the real issue is:
>> >       >       > "
>> >       >       >
>> >       >       >
>> >       >       > Request-URI vs. loose-route acceptance
>> >       >       >
>> >       >       >
>> >       >       > Some IP-PBX do not implement international
>> > standards or SIP
>> >       >       > profiles for SIP trunking. As a consequence
>> > some SIP-PBXs
>> >       >       > expect that inbound SIP requests from the SSP
>> > will have the
>> >       >       > registered Contact-URI in the Request-URI,
>> > and thus not
>> >       >       > interoperate with the loose-route scheme of
>> > 3GPP and ETSI.
>> >       >       > Other SIP-PBXs are fine with the Request-URI being the
>> >       >       > intended target, but cannot handle receiving
>> > a Route header
>> >       >       > field identifying their registered Contact-URI as a
>> >       >       > loose-route entry."
>> >       >       >
>> >       >       >
>> >       >       > Is this an issue, yes. Does introducing yet another
>> >       > profile help? No.
>> >       >       >
>> >       >       > /Hans Erik van Elburg
>> >       >       >
>> >       >       >
>> >       >       > On Thu, Mar 25, 2010 at 9:22 PM, martini issue tracker
>> >       >       > <[email-masked]> wrote:
>> >       >       >
>> >       >       >
>> >       >       >       #21: 3.2.2 describes an issue with some PBX
>> >       >       >
>> >       >       >
>> > -------------------------------------+------------------------
>> >       >       > --------------
>> >       >       >        Reporter:  ietf.hanserik@...
>> > |        Owner:
>> >       >       >
>> >       >       >           Type:  defect                   |
>> >       > Status:  closed
>> >       >       >
>> >       >       >        Priority:  minor                    |
>> >       > Milestone:  milestone1
>> >       >       >       Component:  reqs                     |
>> >       > Version:  1.0
>> >       >       >
>> >       >       >        Severity:  In WG Last Call          |
>> >       > Resolution:  invalid
>> >       >       >        Keywords:                           |
>> >       >       >
>> >       >       >
>> > -------------------------------------+------------------------
>> >       >       > --------------
>> >       >       >       Changes (by john.elwell@...):
>> >       >       >
>> >       >       >        * status:  new => closed
>> >       >       >        * resolution:  => invalid
>> >       >       >
>> >       >       >
>> >       >       >       Comment:
>> >       >       >
>> >       >       >
>> >       >       >        The text of 3.2.2 just underlines the
>> > fact that there
>> >       >       > are different
>> >       >       >        implementations around. A PBX that
>> > expects the loose
>> >       >       > route mechanism to be
>> >       >       >        used would fail to interwork with SSPs using a
>> >       >       > different mechanism (e.g.,
>> >       >       >        SIPconnect 1.0), and a PBX not
>> > expecting the loose
>> >       >       > route mechanism to be
>> >       >       >        used would fail to interwork with a loose route
>> >       >       > implementation (e.g.,
>> >       >       >        ETSI/3GPP). Hence the urgent need for
>> > a standard.
>> >       >       >
>> >       >       >       --
>> >       >       >       Ticket URL:
>> >       >       >
>> >       >
>> > <http://trac.tools.ietf.org/wg/martini/trac/ticket/21#comment:1>
>> >       >       >
>> >       >       >       martini <http://tools.ietf.org/martini/>
>> >       >       >
>> >       >       >
>> >       >       >       _______________________________________________
>> >       >       >       martini mailing list
>> >       >       >       [email-masked]
>> >       >       >       https://www.ietf.org/mailman/listinfo/martini
>> >       >       >
>> >       >       >
>> >       >       >
>> >       >       >
>> >       >
>> >       >
>> >       >
>> >
>> >
>> >
>>
>
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 31 Mar 2010 14:23:44 +0200

I should have said "explicit indication" instead of "option tag". Feature
tags maybe more appropriate, when talking about a profile.

/Hans Erik van Elburg

On Wed, Mar 31, 2010 at 1:28 PM, Hans Erik van Elburg <
[email-masked]> wrote:

>> While I do not have a problem with that specifically, I still have an
>> issue that providing some signalling to do this solves all the issues. There
>> are all sorts of other issues associated with what the PBX "expects" that
>> also cause all sorts of issues, such as whether it expects a tel URI in tel
>> URI format or SIP URI format, and so on, that are not signalled.
>>
>>>        <t>Even where all information needed by the SIP-PBX is provided,
>>> in some deployments inbound SIP requests from the SSP have the registered
>>> To accompany this, I think the title of the section should be changed
>>> too: "Inconsistent placement of information in inbound requests"
>>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 31 Mar 2010 14:32:51 +0200

The problem is that I suspect noone is going to agree what that profile is to be sufficiently useful.

regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
Sent: Wednesday, March 31, 2010 1:24 PM
To: [email-masked]
Subject: Re: [martini] Need for a SIP/SDP profile for SIP trunking , was Re: #21: 3.2.2 describes an issue with some PBX

I should have said "explicit indication" instead of "option tag". Feature tags maybe more appropriate, when talking about a profile.

/Hans Erik van Elburg

On Wed, Mar 31, 2010 at 1:28 PM, Hans Erik van Elburg <[email-masked]<mailto:[email-masked]>> wrote:
Yes, I agree with that observation.

Only solving the routing issue does not solve the overall problem. For that a minimum SIP/SDP profile needs to be agreed upon. Also what are common denominator as codec for voice, fax, dtmf etc.

The question rises if there should be an option tag to signal support for a profile instead of only signalling what routing method is preferred.

BR,
/Hans Erik van Elburg

On Wed, Mar 31, 2010 at 1:18 PM, DRAGE, Keith (Keith) <[email-masked]<mailto:[email-masked]>> wrote:
So assuming that this text is accepted, I guess the key argument of providing this distinction is not that both behaviours are non-standard, but that some means is needed to distinguish the two.

While I do not have a problem with that specifically, I still have an issue that providing some signalling to do this solves all the issues. There are all sorts of other issues associated with what the PBX "expects" that also cause all sorts of issues, such as whether it expects a tel URI in tel URI format or SIP URI format, and so on, that are not signalled.

Therefore at the end of the day, one is still going to end up with configuration information at either end of this interface that is not explicitly signalled, and in the absence of both sides having preconfigured knowledge of that information, the interface is not going to work.

regards

Keith

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Elwell, John
Sent: Tuesday, March 30, 2010 6:11 PM
To: Hans Erik van Elburg

Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [martini] #21: 3.2.2 describes an issue with some PBX

John

________________________________
From: Hans Erik van Elburg [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 30 March 2010 11:49
To: Elwell, John
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [martini] #21: 3.2.2 describes an issue with some PBX

Hi John,

Inline...

/Hans Erik van Elburg

On Mon, Mar 29, 2010 at 9:55 PM, Elwell, John <[email-masked]<mailto:[email-masked]>> wrote:
Hans Erik,

I think the point you are trying to make is that it is not one-sided. The fact is, each side has different ways of working, and you need to have the two sides operating in compatible manners for it to work. In practice, I think there are other variants, besides the two cited in the present 3.2.2.
Yes. And there is no objective way to automatically determine what variant the PBX or the SSP is supporting. Which is what an options tag could resolve.

I would suggest:

       <t>Even where all information needed by the SIP-PBX is provided, in some deployments inbound SIP requests from the SSP have the registered Contact URI in the Request-URI, whereas in other deployments inbound SIP requests have the intended target (AOR) in the Request-URI and the Contact URI in the Route header field. There are other variants too. Interoperability problems arise when a PBX designed for or configured for one variant attempts to interwork with an SSP designed for or configured for another variant.</t>
Yes, slightly modified to add the objective means issue:
 <t>Even where all information needed by the SIP-PBX is provided, in some deployments inbound SIP requests from the SSP have the registered PBX Contact URI in the Request-URI, whereas in other deployments inbound SIP requests have the intended target PBX user (AOR) in the Request-URI and the Contact URI in the Route header field. There are other variants too. Interoperability problems arise when a PBX designed for or configured for one variant attempts to interwork with an SSP designed for or configured for another variant. There is currently no objective means in the signalling during registration for either party to discover what mechanism the other side supports.</t>

To accompany this, I think the title of the section should be changed too: "Inconsistent placement of information in inbound requests"

Yes, slightly modified to make it more specific: "Inconsistent placement of target URI information in inbound requests".

John

> From: Hans Erik van Elburg [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>> wrote:
>
>
>       Hans Erik,
>
>       > From: Hans Erik van Elburg [mailto:[email-masked]<mailto:[email-masked]>]
>
>       > Cc: [email-masked]<mailto:[email-masked]>
>       > <[email-masked]<mailto:[email-masked]>> wrote:
>       >
>       >
> [mailto:[email-masked]<mailto:[email-masked]>]
>       >       > To: [email-masked]<mailto:[email-masked]>
>       >       > Cc: Elwell, John; [email-masked]<mailto:[email-masked]>
>       >       > <[email-masked]<mailto:[email-masked]>> wrote:
>       >       >
>       >       >
>       >       >       [email-masked]<mailto:[email-masked]>

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

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 31 Mar 2010 14:48:47 +0200

Now that is pessimistic...

I thought that largely people should be able to agree on some common
denominator between ETSI and SIP connect profile, but maybe that is my
overly optimistic naive stagnant mindset.

/Hans Erik van Elburg

On Wed, Mar 31, 2010 at 2:32 PM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

> Behalf Of *Hans Erik van Elburg
> *Sent:* Wednesday, March 31, 2010 1:24 PM
> *To:* [email-masked]
> *Subject:* Re: [martini] Need for a SIP/SDP profile for SIP trunking , was
> Re: #21: 3.2.2 describes an issue with some PBX
>
>> Only solving the routing issue does not solve the overall problem. For
>> that a minimum SIP/SDP profile needs to be agreed upon. Also what are common
>> The question rises if there should be an option tag to signal support for
>> a profile instead of only signalling what routing method is preferred.
>>
>> BR,
>> /Hans Erik van Elburg
>>
>>
>>>> I think the point you are trying to make is that it is not one-sided.
>>>> The fact is, each side has different ways of working, and you need to have
>>>> the two sides operating in compatible manners for it to work. In practice, I
>>> Yes. And there is no objective way to automatically determine what
>>> variant the PBX or the SSP is supporting. Which is what an options tag could
>>> resolve.
>>>
>>>
>>>> I would suggest:
>>>>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 31 Mar 2010 14:58:28 +0200

Maybe that is indeed asking for to much.

In that case it would still be usefull to be able to distinguish between the
profiles, so that means you would need an indicator per profile.

/Hans Erik van Elburg

On Wed, Mar 31, 2010 at 2:48 PM, Hans Erik van Elburg <
[email-masked]> wrote:

>> *Subject:* Re: [martini] Need for a SIP/SDP profile for SIP trunking ,
>> was Re: #21: 3.2.2 describes an issue with some PBX
>>
>>>> some deployments inbound SIP requests from the SSP have the registered PBX
>>>>> Yes, slightly modified to make it more specific: "Inconsistent
>>>> placement of target URI information in inbound requests".
>>>>
>>>>
>>>>> John
>>>>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 31 Mar 2010 14:57:36 +0200

I wasn't trying to be pessimistic. It was more along the lines that no matter how much we tie down in the profile, there will always be another bit of configuration data that will need to be known at both ends.

We have already discussed significantly the set of numbers in use at both sides of the interface, and decided that these are outside the scope of martini, but get these misconfigured and things will not work (neither will a phone where I try and register a number that does not belong to me).

regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
Sent: Wednesday, March 31, 2010 1:49 PM
To: DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: Re: [martini] Need for a SIP/SDP profile for SIP trunking , was Re: #21: 3.2.2 describes an issue with some PBX

I thought that largely people should be able to agree on some common denominator between ETSI and SIP connect profile, but maybe that is my overly optimistic naive stagnant mindset.

/Hans Erik van Elburg

On Wed, Mar 31, 2010 at 2:32 PM, DRAGE, Keith (Keith) <[email-masked]<mailto:[email-masked]>> wrote:
The problem is that I suspect noone is going to agree what that profile is to be sufficiently useful.

regards

Keith

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Hans Erik van Elburg
Sent: Wednesday, March 31, 2010 1:24 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [martini] Need for a SIP/SDP profile for SIP trunking , was Re: #21: 3.2.2 describes an issue with some PBX

/Hans Erik van Elburg

BR,
/Hans Erik van Elburg

regards

Keith

John

Hi John,

Inline...

/Hans Erik van Elburg

I would suggest:

John

---

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

Hi,

While I agree on the usefulness of such profiles, I doubt IETF is the correct place to define those. I also think that it is outside the scope of MARTINI.

Different SDO/customers/vendors might have different requirements on the profiles, but we could of course provide a mechanism (e.g. using a feature tag) to indicate which profiles are supported/indicated.

>From a MARTINI perspective, I think the main issue is the difference in the routing mechanims.

Now, regarding the option-tag to indicate the routing mechanism: since an option-tag requires an RFC, would MARTINI be the place to define such option-tag for the IMS solution (should the involved people choose to define one)?

Regards,

Christer

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
Sent: 31. maaliskuuta 2010 15:49
To: DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: Re: [martini] Need for a SIP/SDP profile for SIP trunking , was Re: #21: 3.2.2 describes an issue with some PBX

/Hans Erik van Elburg

regards

Keith

/Hans Erik van Elburg

BR,
/Hans Erik van Elburg

regards

Keith

John

Hi John,

Inline...

/Hans Erik van Elburg

I would suggest:

John

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 31 Mar 2010 08:42:05 -0500

Christer,

Speaking as chair, I can assure you that an overall SIP PBX profile is out of scope for MARTINI :-)

Speaking as an individual, I would expect that http://tools.ietf.org/html/rfc5727 would point to having a proposal for an IMS option tag going through DISPATCH, but DISPATCH can certainly send work to an existing working group, and if that happens, MARTINI would be an obvious candidate destination.

<out of scope for MARTINI mailing list> 

Again, speaking as an individual - my understanding is that the SIPconnect guys were OK with an option tag for SIPconnect 1.1, because SIPconnect 1.0 was incredibly underspecified ("register one AOR and a miracle may occur"). SIPconnect really is ready to remove the earlier optionless mode of operation from SIPconnect 1.1.

Would ETSI/TISPAN/3GPP move to an optioned mode of operation for Release 1N? Or would this be retained, so that IMS would have two modes of operation? 

No reason to answer this question on the MARTINI mailing list, or even to discuss it here, but I think that would be good to know, if you're thinking about bringing a proposal to DISPATCH.

</out of scope for MARTINI mailing list> 

Spencer
  ----- Original Message ----- 
  From: Christer Holmberg 
  To: Hans Erik van Elburg ; DRAGE, Keith (Keith) 
  Cc: [email-masked] 
  Sent: Wednesday, March 31, 2010 8:01 AM
  Subject: Re: [martini] Need for a SIP/SDP profile for SIP trunking , was Re: #21: 3.2.2 describes an issue with some PBX

  Hi,

---

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

Somehow I knew we were going to get that question. :)
IF we really need this type of thing, then while we can't decide on profiles in the IETF (or at least won't ever finish if we try), what we could do is make the Martini option-tag require a complaint device to support a "Profile" header, such that if a "Profile" header exists in the message, then the receiver must support one of the profiles names listed in it.
In other words, we don't have to define any profiles in the IETF, and inserting a Profile header field would be optional, but if you get it then you have to understand it.

-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
Sent: Wednesday, March 31, 2010 7:29 AM
To: DRAGE, Keith (Keith)
Cc: [email-masked]
Subject: [martini] Need for a SIP/SDP profile for SIP trunking , was Re: #21: 3.2.2 describes an issue with some PBX

BR,
/Hans Erik van Elburg

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 31 Mar 2010 17:41:47 +0200

I don't see the relevance of SDP, codecs, voice, fax, etc.. These are all issues for the UAs behind the SIP-PBX and the SSP. MARTINI is about reachability of the SIP-PBX from an SSP.

John

> Sent: 31 March 2010 12:29
> To: DRAGE, Keith (Keith)
> Subject: Need for a SIP/SDP profile for SIP trunking , was
> Re: [martini] #21: 3.2.2 describes an issue with some PBX
>
> Only solving the routing issue does not solve the overall
> problem. For that a minimum SIP/SDP profile needs to be
> agreed upon. Also what are common denominator as codec for
> voice, fax, dtmf etc.
>
> The question rises if there should be an option tag to signal
> support for a profile instead of only signalling what routing
> method is preferred.
>
> BR,
> /Hans Erik van Elburg
>
>
>
> On Wed, Mar 31, 2010 at 1:18 PM, DRAGE, Keith (Keith)
> <[email-masked]> wrote:
>
>
>       So assuming that this text is accepted, I guess the key
> argument of providing this distinction is not that both
> behaviours are non-standard, but that some means is needed to
> distinguish the two.
>
>       While I do not have a problem with that specifically, I
> still have an issue that providing some signalling to do this
> solves all the issues. There are all sorts of other issues
> associated with what the PBX "expects" that also cause all
> sorts of issues, such as whether it expects a tel URI in tel
>       Therefore at the end of the day, one is still going to
> end up with configuration information at either end of this
> interface that is not explicitly signalled, and in the
> absence of both sides having preconfigured knowledge of that
> information, the interface is not going to work.
>
>       regards
>
>       Keith
>
>       From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Elwell, John
>                       On Mon, Mar 29, 2010 at 9:55 PM,
> Elwell, John <[email-masked]> wrote:
>
>
>                               Hans Erik,
>
>                               I think the point you are
> trying to make is that it is not one-sided. The fact is, each
> side has different ways of working, and you need to have the
> two sides operating in compatible manners for it to work. In
> practice, I think there are other variants, besides the two
> cited in the present 3.2.2.
>
>                       Yes. And there is no objective way to
> automatically determine what variant the PBX or the SSP is
> supporting. Which is what an options tag could resolve.
>
>
>                               I would suggest:
>
>                                      <t>Even where all
> information needed by the SIP-PBX is provided, in some
> deployments inbound SIP requests from the SSP have the
> registered Contact URI in the Request-URI, whereas in other
> deployments inbound SIP requests have the intended target
> (AOR) in the Request-URI and the Contact URI in the Route
> header field. There are other variants too. Interoperability
> problems arise when a PBX designed for or configured for one
> variant attempts to interwork with an SSP designed for or
> configured for another variant.</t>
>
>
>                        <t>Even where all information needed
> by the SIP-PBX is provided, in some deployments inbound SIP
> requests from the SSP have the registered PBX Contact URI in
> the Request-URI, whereas in other deployments inbound SIP
> requests have the intended target PBX user (AOR) in the
> Request-URI and the Contact URI in the Route header field.
> There are other variants too. Interoperability problems arise
> when a PBX designed for or configured for one variant
> attempts to interwork with an SSP designed for or configured
> for another variant. There is currently no objective means in
> the signalling during registration for either party to
> discover what mechanism the other side supports.</t>
>
>
>                               To accompany this, I think the
> title of the section should be changed too: "Inconsistent
> placement of information in inbound requests"
>
>
>
>                       Yes, slightly modified to make it more
> specific: "Inconsistent placement of target URI information
> in inbound requests".
>
>
>                               John
>
>                               >       > registered
> Contact-URI in the Request-URI, and thus not
>                               >       > interoperate with the
>                               >       > reason for the
> MARTINI work. In particular, the IETF has not
>                               >       > published the
> so-called loose-route mechanism. Hence the
>                               >       > reason for the IETF,
>                               >       >       > Sent: 26
> March 2010 02:21
>                               >       >       > Then you
> should rephrase to what the real issue is:
>                               >       >       > "
>                               >       >       >
>                               >       >       >
>                               >       >       > Request-URI
>                               >       >       > Other
> SIP-PBXs are fine with the Request-URI being the
>                               >       >       > intended
>                               >       >       > field
> identifying their registered Contact-URI as a
>                               >       >       > loose-route entry."
>                               >       >       >
>                               >       >       >
>                               >       >       > Is this an
>                               >       >       > On Thu, Mar
> 25, 2010 at 9:22 PM, martini issue tracker
>                               >       >       >
>                               >       >       >        *
> status:  new => closed
>                               >       >       >        *
> resolution:  => invalid
>                               >       >       >        used
> would fail to interwork with SSPs using a
>                               >       >       > different
> mechanism (e.g.,
>                               >       >       >
>                               >       >       >        used
> would fail to interwork with a loose route
>                               >       >       > implementation (e.g.,
>                               >       >       >
>                               >       >       >       martini
> mailing list

---

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

Hi, 
 
>Speaking as an individual, I would expect that http://tools.ietf.org/html/rfc5727 would point to having a proposal for an IMS option tag going through DISPATCH, but DISPATCH can certainly send work to an 
>existing working group, and if that happens, MARTINI would be an obvious candidate destination.

I was wondering whether it could be taken directly to MARTINI. If it can be considered helpful for the work we are doing I think it could fit the MARTINI charter.

My main preference, however, is to have a single solution.

>Again, speaking as an individual - my understanding is that the SIPconnect guys were OK with an option tag for SIPconnect 1.1, because SIPconnect 1.0 was incredibly underspecified ("register one AOR and 
>a miracle may occur"). SIPconnect really is ready to remove the earlier optionless mode of operation from SIPconnect 1.1.
>

I don't think the issue is whether 3GPP would document the IETF solution, but to allow implementations to know which solution(s) are supported.

Regards,

Christer

	----- Original Message ----- 
	From: Christer Holmberg <mailto:[email-masked]>  
	To: Hans Erik van Elburg <mailto:[email-masked]>  ; DRAGE, Keith (Keith) <mailto:[email-masked]>  
	Cc: [email-masked] 
	Sent: Wednesday, March 31, 2010 8:01 AM
	Subject: Re: [martini] Need for a SIP/SDP profile for SIP trunking , was Re: #21: 3.2.2 describes an issue with some PBX

	Hi,