Subject: Re: [Sip] INFO

From: Eric Burger <[email-masked]>
Date: Tue, 04 Sep 2007 13:34:07 -0700

That is the point of the draft.  All of the uses of INFO today have
alternatives that do not have the same problems.

In fact, I am really thinking the draft should point out the use of INFO for
SIP-T is also incorrect.  SIP-T should use a control channel, not the "SIP"
channel, for transporting proprietary signaling.  The only thing SIP-T does
is re-create TCP over SIP.  Not a very useful use of SIP.

That said, if this is to be a work group draft, I would sure appreciate the
work group's opinion here.  Do we:

[1] Deprecate SIP-T, indicating the flaw of using INFO for transporting
Q.931/Q.sig/DPNSS/telco foobar, as well as writing a new draft to replace
SIP-T?  Downside is no one will care and it will be ignored.

[2] Ignore the issue and hope people do not notice the hypocrisy of saying
"do not use INFO, but we have this use that we are afraid to admit we have
learned from experience this was a mistake"?

[3] Mention the SIP-T issue, point out that it may have been a Best Current
Practice in 2002, but that it is no longer the best practice.  However, it
is what it is.

To be clear, the "SIP-T issue" is really the INFO issue: the endpoint has no
idea why they are getting an INFO nor what it means.  The approach in this
draft is to say the INFO means SIP-T and only SIP-T.  I am getting less and
less enamored with keeping the SIP-T use, as people keep piling on yet one
more "kind of like Q.931" signaling on INFO.  Before we know it, we get to
"UserInputIndication", which is simply DTMF in ASN.1.

On 8/31/07 2:31 AM, "Peili Xu" <[email-masked]> wrote:

> 
> 
> 
> I fully understand your concern. But just to forbidden
> using INFO does not
> solve the "how do the endpoints know they will be able
> to communicate?" problem/requirement either.
> 
> I'd suggest we first consider to find solution for the
> prolem
> then after that we can say "Don't use INFO for this, Use
> that solution."
> 
> Do you think this is a more convising way?
> 
> Peili
> 
> 
> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: Friday, August 31, 2007 6:03 AM
> To: Peili Xu
> Cc: sip
> Subject: Re: [Sip] INFO
> 
> Saying, "OK for interworking" does not really say
> anything.  If I come up with a really broken method for
> interworking, saying that it is for interworking does
> not make it correct.
> 
> The problem is, how do the endpoints know they will be
> able to communicate?
> For the ISUP/Q.sig/DPNSS/mumble case, the endpoints know
> they will be able to interoperate because they know
> a'priori: they are configured to work.
> However, this means that the devices must be in the same
> administrative domain and configured properly.
> 
> Said in a different manner, INFO works fine for
> non-inter-network use.  It would be hard for the IETF to
> say, "Here is a non-IETF use.  We will not use it.  You
> cannot use it with anyone else.  You cannot use it
> between manufacturers, unless you get them to agree to
> this use."  That is a bit more of what we call the toxic
> waste warning that accompanies 3GPP specifications...
> 
> 
> On 8/27/07 8:35 AM, "Peili Xu" <[email-masked]>
> wrote:
> 
>> Hi Eric,
>> 
>> Several cases I encounter to use INFO is for
> interworking with PSTN
>> signaling, or simulate PSTN services at SIP entities
> such as SIP UA or
>> SIP GW, which require mid-dialog information change.
>> 
>> For such SIP entities, It's not always possible or
> required to support
>> encapsulation of ISUP or QSIG package. Just some XML
> body with
>> application info is enough and light-weight for this
> purpose.
>> 
>> 
>> INFO is not an ideal tool for everything, but is an
> ideal tool for some thing.
>> 
>> I'd prpose to at lease allow using INFO for
> interworking or simulation
>> purpose with legacy system.
>> 
>> Regards.
>> Peili
>> 
>> 2007/8/22, Eric Burger <[email-masked]>:
>>> Since list traffic is down, how about something to
> spice things up?
>>> 
>>> 
>>> Any thoughts on
>>> 
>>> 
> http://www.ietf.org/internet-drafts/draft-burger-sip-inf
> o-01.txt
>>> 
>>> ???
>>> 
>>> If you like it, say so.  If you hate it, say so.
>>> 
>>> Text welcome.
>>> 
>>> 
>>> Notice:  This email message, together with any
> attachments, may
>>> contain information  of  BEA Systems,  Inc.,  its
> subsidiaries  and
>>> affiliated entities,  that may be confidential,
> proprietary, 
>>> copyrighted  and/or legally privileged, and is
> intended solely for
>>> the use of the individual or entity named in this
> message. If you are
>>> not the intended recipient, and have received this
> message in error,
>>> please immediately return this by email and then
> delete it.
>>> 
>>> 
>>> _______________________________________________
>>> Sip mailing list
> https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP
> Protocol Use
>>> [email-masked] for questions on
> current sip Use
>>> [email-masked] for new developments on the
> application of sip
>>> 
>> 
> 
> 
> 
> Notice:  This email message, together with any
> attachments, may contain information  of  BEA Systems,
> Inc.,  its subsidiaries  and  affiliated entities,  that
> may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use
> of the individual or entity named in this message. If
> you are not the intended recipient, and have received
> this message in error, please immediately return this by
> email and then delete it.
> 
> 
> _______________________________________________
> Sip mailing list
> https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
> Protocol Use [email-masked] for
> questions on current sip Use [email-masked] for new
> developments on the application of sip
> 
> 
> 

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Bram Verburg" <[email-masked]>
Date: Wed, 5 Sep 2007 14:56:58 +0300

> That is the point of the draft.  All of the uses of INFO 
> today have alternatives that do not have the same problems.
> 
> In fact, I am really thinking the draft should point out the 
> use of INFO for SIP-T is also incorrect.  SIP-T should use a 
> control channel, not the "SIP"
> channel, for transporting proprietary signaling.  The only 
> thing SIP-T does is re-create TCP over SIP.  Not a very 
> useful use of SIP.

I don't think that's a fair assessment of SIP-T, since you seem to be
ignoring the fact that SIP-T also (primarily) uses other methods than
INFO.

The encapsulation of 'proprietary' signaling is done to convey
information that cannot currently be conveyed in pure SIP. But other
than that, within the VoIP domain the regular SIP dialog model is used
to establish and tear down sessions. SIP headers take precedence over
the contents of the ISUP/Q.931 message, so the 'tunneled' message is
only used to fill in some blanks at the receiving end. For the most part
proxies and even user agents can safely ignore the message body and
still participate in the SIP dialog.

Some ISUP/Q.931 messages arrive at a stage in the session where SIP
doesn't define any interaction between UAs, so currently INFO is used as
a tunnel. If you believe it should be replaced by something less
ambiguous, that won't be abused outside the scope of SIP-T the same way
INFO is today, I guess that's fair enough. But saying that SIP-T should
use TCP tunnels instead seems a bit harsh.

Bram

---

From: Eric Burger <[email-masked]>
Date: Wed, 05 Sep 2007 06:08:30 -0700

SIP-T suffers *all* of the issues with INFO.

Read section 3.3 for the 'right' way of doing SIP-T.

That said, let's be real: I don't think anyone will abandon SIP-T at this
late date.  Although this really is a counter example, I would liken this to
the story in:
http://www.snopes.com/history/american/gauge.htm

---

From: "Bram Verburg" <[email-masked]>
Date: Wed, 5 Sep 2007 16:46:57 +0300

OK, SIP-T is not going away, but I'm still not sure whether you are
trying to say that all of SIP-T is bad, or only its use of INFO? If all
of SIP-T is bad, then let's not fix it and wait till it does go away
eventually. If the problem is specifically with INFO, then let's define
an event package that allows endpoints to request mid-call 'proprietary'
signaling events, and then we can deprecate INFO altogether.

My point was that SIP-T is not simply a tunnel that could be replaced by
any other transport layer, which is what section 3.3 seems to describe.
It is a 'session initiation protocol' that does exactly what SIP is
designed to do: initiate sessions. The fact that the INFO method has a
problem doesn't mean that SIP-T is an inappropriate use of SIP.

Bram

> Sent: 05 September 2007 16:09
> To: Bram Verburg
> Cc: sip
> Subject: Re: [Sip] INFO
> 
> That said, let's be real: I don't think anyone will abandon 
> SIP-T at this late date.  Although this really is a counter 
> example, I would liken this to the story in:
> today have 
> >> In fact, I am really thinking the draft should point out 
> the use of 
> >> INFO for SIP-T is also incorrect.  SIP-T should use a control 
> >> channel, not the "SIP"
> >> channel, for transporting proprietary signaling.  The only thing 
> >> SIP-T does is re-create TCP over SIP.  Not a very useful 
> use of SIP.
> > 
> > only used to fill in some blanks at the receiving end. For the most 
> > part proxies and even user agents can safely ignore the 
> message body 
> > and still participate in the SIP dialog.
> > 
> > doesn't define any interaction between UAs, so currently 
> INFO is used 
> > as a tunnel. If you believe it should be replaced by something less 
> > ambiguous, that won't be abused outside the scope of SIP-T the same 
> > way INFO is today, I guess that's fair enough. But saying 
> that SIP-T 
> > should use TCP tunnels instead seems a bit harsh.
> > 
> > Bram
> > 
> 
> 
> 
> Notice:  This email message, together with any attachments, 
> may contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  affiliated entities,  that may be 
> confidential,  proprietary,  copyrighted  and/or legally 
> privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in 
> error, please immediately return this by email and then delete it.
>

---

From: Eric Burger <[email-masked]>
Date: Wed, 05 Sep 2007 07:11:06 -0700

The use of INFO part.  Hey, I'm not totally Henry - I do see a place for
communications service providers and I recognize the importance of
interworking with the PSTN for the next 15 years.

SIP-T is not a session initiation protocol.  It is a set of conventions for
TUNNELING proprietary signaling events over SIP.  Key word there is
TUNNELING.  That is the clue that section 3.3 applies.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 5 Sep 2007 08:18:06 -0700

Thanks Eric! :-)

The guidelines for the usage of SIP don't have as far as I remember any
recommendation for SIP to be used as a tunneling protocol. In this
respect, the use of SIP for a "tunneling convention" is non-truth in
advertising.

As for the most effective way of carrying SS7 over IP networks, I would
be interested to hear how VoIP providers are actually doing it. Can
anyone share such information?

Oh yes,...
> I do see a place for communications service providers
So do I. Aren't we all here in the IETF to communicate over the Internet
or in private IP networks?

>> The fact that the INFO method has a

Yes, it is inappropriate since people attempting to connect with a SIP
end device such as a SIP phone or PSTN gateway on the SIP side will
fail.

Henry

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2007 9:11 AM
To: Bram Verburg
Cc: sip
Subject: Re: [Sip] INFO

SIP-T is not a session initiation protocol.  It is a set of conventions
for
TUNNELING proprietary signaling events over SIP.  Key word there is
TUNNELING.  That is the clue that section 3.3 applies.

>> error, please immediately return this by email and then delete it.

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 5 Sep 2007 08:34:52 -0700

Actually, using the SIP-T protocol for tunneling SS7 is a designer
choice, though I would be interested to hear what other options there
are and what may be the best option. Are there reasons for SIP-T to be
the best option?

I still dislike to the use of "SIP" in the "SIP-T" name as mentioned
below.

Thanks, Henry 

=====================================
Thanks Eric! :-)

Oh yes,...

Henry

---

From: "Bram Verburg" <[email-masked]>
Date: Wed, 5 Sep 2007 19:37:02 +0300

I don't think you can really decouple the SIP layer and the encapsulated
ISUP/Q.931 body like that, and say that SIP-T is just the tunneling
part.

The fact that SIP-T says that SIP headers take precedence over the
ISUP/Q.931 means you can't send the INVITE and the IAM over separate
channels (for example a TCP or Sigtran tunnel for ISUP) without opening
a big can of worms. How do you synchronize those messages at the
receiving end; you'd need both the INVITE and the tunneled IAM before
you can send something out on the PSTN side. How do you even make sure
those two channels reach the same destination after passing through
proxies, NATs, SBCs, load balancers, etc.?

A proper SIP-T implementation can be fully SIP compliant, it's just that
it currently uses a somewhat controversial SIP method. If that
particular issue needs to be addressed, let's address it.

Bram

> Sent: 05 September 2007 17:11
> To: Bram Verburg
> Cc: sip
> Subject: Re: [Sip] INFO
> 
> The use of INFO part.  Hey, I'm not totally Henry - I do see 
> a place for communications service providers and I recognize 
> the importance of interworking with the PSTN for the next 15 years.
> 
> SIP-T is not a session initiation protocol.  It is a set of 
> conventions for TUNNELING proprietary signaling events over 
> SIP.  Key word there is TUNNELING.  That is the clue that 
> section 3.3 applies.
> 
> 
> > trying to say that all of SIP-T is bad, or only its use of INFO? If 
> > all of SIP-T is bad, then let's not fix it and wait till it does go 
> > away eventually. If the problem is specifically with INFO, 
> then let's 
> > define an event package that allows endpoints to request 
> mid-call 'proprietary'
> > My point was that SIP-T is not simply a tunnel that could 
> be replaced 
> > by any other transport layer, which is what section 3.3 
> seems to describe.
> >> That said, let's be real: I don't think anyone will 
> abandon SIP-T at 
> >> this late date.  Although this really is a counter 
> example, I would 
> >> Notice:  This email message, together with any attachments, may 
> >> affiliated entities,  that may be confidential,  proprietary,  
> >> copyrighted  and/or legally privileged, and is intended solely for 
> >> the use of the individual or entity named in this message. 
> If you are 
> >> not the intended recipient, and have received this message 
> in error, 
> >> please immediately return this by email and then delete it.
> >> 
> > 
> 
> 
>

---

From: "Beith, Gordon" <[email-masked]>
Date: Wed, 5 Sep 2007 14:00:59 -0400

I agree with Peili here.

And regarding the other question, Sigtran (e.g. M3UA, M2PA) is used as
an alternative IP-based transport for SS7 on the PSTN (i.e.
interconnect) side of the network.
I don't think Sigtran is a good replacement for SIP-T between
"SIP-T"-aware devices across the SIP VoIP network.

/Gordon

-----Original Message-----
From: Peili Xu [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2007 11:53 AM
To: Henry Sinnreich
Cc: sip
Subject: Re: [Sip] INFO - more on SIP-T

Hi,

I would rather treat SIP-T (ISUP encapsulation) as an enhancement for
SIP in case of interworking.

Basically, it's a SIP session which route the call to the destination
(GW) and carry out SDP offer/answer negotiation. The reason why
encapsulation is just to guarantee minimum information lost.

I don't think the control channel concept for SIP is proper to replace
SIP-T, because we need SIP to do SDP exchange and most of the ISUP
information is semantically related to SIP dialog setup messages.

Peili

> I still dislike to the use of "SIP" in the "SIP-T" name as mentioned
conventions
> all
> > My point was that SIP-T is not simply a tunnel that could be
replaced
> by
contain

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 6 Sep 2007 09:54:52 +0100

you can send something out on the PSTN side.

[Chris Boulton] I am struggling to see what the difference is between
passing SIP-T using a potentially un-reliable INFO and using a reliable
channel.  You synchronize the messages in the same way you synchronize
receiving the INFO. 

 How do you even make sure
those two channels reach the same destination after passing through
proxies, NATs, SBCs, load balancers, etc.?

[Chris Boulton] These are all issues that are (and will be) considered
in the MediaCtrl work in drafts like
http://tools.ietf.org/html/draft-boulton-sip-control-framework-05 (*note
- new WG version to be submitted this week).  It is already understood
that the solution MUST work in these cases.

Chris.

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Ubiquity Software Corporation plc, a company registered under the laws of England and Wales, Registration 2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom.

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 6 Sep 2007 09:58:48 +0100

[Chris Boulton] Sorry - this doesn't fly for me.  The Control channel
being developed in MediaCtrl has a strong requirement to explicitly
'relate' its primitives and commands to a SIP dialog (as it needs to
work for IVR commands to a SIP dialog).

Chris.

---

From: Peili Xu <[email-masked]>
Date: Thu, 06 Sep 2007 19:35:35 +0800

SIP-T talks about mapping between different session
setup protocols. It's very different from requirements
in MediaCtrl.

Please don't mix them together just because INFO is
used.  8-)

Peili

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]] 
Sent: Thursday, September 06, 2007 4:59 PM
To: Peili Xu; Henry Sinnreich
Cc: sip
Subject: RE: [Sip] INFO - more on SIP-T

I don't think the control channel concept for SIP is
proper to replace SIP-T, because we need SIP to do SDP
exchange and most of the ISUP information is
semantically related to SIP dialog setup messages.

[Chris Boulton] Sorry - this doesn't fly for me.  The
Control channel being developed in MediaCtrl has a
strong requirement to explicitly 'relate' its primitives
and commands to a SIP dialog (as it needs to work for
IVR commands to a SIP dialog).

Chris.

Information contained in this e-mail and any attachments
are intended for the use of the addressee only, and may
contain confidential information of Ubiquity Software
Corporation. All unauthorized use, disclosure or
distribution is strictly prohibited.  If you are not the
addressee, please notify the sender immediately and
destroy all copies of this email. Ubiquity Software
Corporation plc, a company registered under the laws of
England and Wales, Registration 2719723, registered
offices at Eastern Business Park, Building 3, Wern Fawr
Lane, St. Mellons, Cardiff CF3 5EA, Wales, United
Kingdom.

---

From: Peili Xu <[email-masked]>
Date: Thu, 06 Sep 2007 19:40:00 +0800

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]] 
Sent: Thursday, September 06, 2007 4:55 PM
To: Bram Verburg; Eric Burger
Cc: sip
Subject: RE: [Sip] INFO

The fact that SIP-T says that SIP headers take
precedence over the
ISUP/Q.931 means you can't send the INVITE and the IAM
over separate channels (for example a TCP or Sigtran
tunnel for ISUP) without opening a big can of worms. How
do you synchronize those messages at the receiving end;
you'd need both the INVITE and the tunneled IAM before
you can send something out on the PSTN side.

[Chris Boulton] I am struggling to see what the
difference is between passing SIP-T using a potentially
un-reliable INFO and using a reliable channel.  You
synchronize the messages in the same way you synchronize
receiving the INFO. 

// Peili: using INFO to rarelly transfer some
un-mappable mid-dialog messages is just a small part of
SIP-T.
// SIP-T talks about mapping between ISUP-SIP, and
possibly try to minimize information lost by tunneling
the message.

 How do you even make sure
those two channels reach the same destination after
passing through proxies, NATs, SBCs, load balancers,
etc.?

[Chris Boulton] These are all issues that are (and will
be) considered in the MediaCtrl work in drafts like
http://tools.ietf.org/html/draft-boulton-sip-control-fra
mework-05 (*note
- new WG version to be submitted this week).  It is
already understood that the solution MUST work in these
cases.

// Peili: This cover's different requirments from SIP-T,
I don't see any relationship.

Chris.

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 6 Sep 2007 13:54:05 +0200

Hi,

In ETSI TISPAN, there is work on something called IMS based PSTN/ISDN
emulation. In that network, the ISUP information can actually be
originated/terminated inside the network (i.e. it's not simply tunneled
through the IP network between the MGCs, or something like that),
normally by an application server understanding the ISUP information.
There are also rules about proxies removing ISUP information before
forwarding messages to UAs and/or other networks.

My point is that the entities using the ISUP information may not have
"media access", so in case a separate channel is used they would have to
make sure that tunnel is relayed through those entities (in some cases
they would have to terminate the channel, if the ISUP content is not
meant to be forwarded), meaning they would have to modify SDPs etc.

Regards,

Christer

> Sent: 6. syyskuuta 2007 11:55
> ISUP/Q.931 means you can't send the INVITE and the IAM over 
> separate channels (for example a TCP or Sigtran tunnel for 
> ISUP) without opening a big can of worms. How do you 
> synchronize those messages at the receiving end; you'd need 
> both the INVITE and the tunneled IAM before you can send 
> something out on the PSTN side.
> 
> [Chris Boulton] I am struggling to see what the difference is 
> between passing SIP-T using a potentially un-reliable INFO 
> and using a reliable channel.  You synchronize the messages 
> in the same way you synchronize receiving the INFO. 
> 
> those two channels reach the same destination after passing 
> through proxies, NATs, SBCs, load balancers, etc.?
> 
> [Chris Boulton] These are all issues that are (and will be) 
> considered in the MediaCtrl work in drafts like
> - new WG version to be submitted this week).  It is already 
> understood that the solution MUST work in these cases.
> 
> Chris.
> 
> 
> 
> 
> 
> Information contained in this e-mail and any attachments are 
> intended for the use of the addressee only, and may contain 
> confidential information of Ubiquity Software Corporation. 
> All unauthorized use, disclosure or distribution is strictly 
> prohibited.  If you are not the addressee, please notify the 
> sender immediately and destroy all copies of this email. 
> Ubiquity Software Corporation plc, a company registered under 
> the laws of England and Wales, Registration 2719723, 
> registered offices at Eastern Business Park, Building 3, Wern 
> Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom.
> 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 6 Sep 2007 13:01:45 +0100

setup protocols.

[Chris Boulton] Yes - fully understood.

 It's very different from requirements
in MediaCtrl.

[Chris Boulton] I can assure that I am not mixing up the base
requirements of the Control Framework - which is actually MediaCtrl
agnostic.  The concept has been designed specifically with this in mind.
I am still waiting for concrete reasons why it is not a good match.

Chris.

---

From: Peili Xu <[email-masked]>
Date: Thu, 06 Sep 2007 20:13:00 +0800

Hi,

Encapsulation could be optional for mapping between SIP
& ISUP network.
That means, you could send INVITE with IAM  but receive
200 without ANM.
In this case only SIP dialog is setup.  I can't imagine
how this will be supported by control framework.

Peili

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]] 
Sent: Thursday, September 06, 2007 8:02 PM
To: Peili Xu; Henry Sinnreich
Cc: sip
Subject: RE: [Sip] INFO - more on SIP-T

[Chris Boulton] I can assure that I am not mixing up the
base requirements of the Control Framework - which is
actually MediaCtrl agnostic.  The concept has been
designed specifically with this in mind.
I am still waiting for concrete reasons why it is not a
good match.

Chris.

---

From: "Rafferty, James" <[email-masked]>
Date: Thu, 6 Sep 2007 11:00:14 -0400

Henry, 

Our company can either map SS7 to SIP, or use SIP-T in our gateways.
The main reason to use SIP-T (or what the ITU-T/3GPP calls SIP-I) is to
more completely preserve the SS7 parameter information for SS7 bridging
applications.  If the desire is to cut over completely to SIP, then the
direct mapping approach works, but much of the SS7 semantics are lost.
We see more of the SS7 to SIP mapping than the use of SIP-T these days.

James

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2007 11:35 AM
To: Eric Burger; Bram Verburg
Cc: sip
Subject: RE: [Sip] INFO - more on SIP-T

Thanks, Henry 

Oh yes,...

Henry

-----Original Message-----
From: Eric Burger [mailto:[email-masked]]
Sent: Wednesday, September 05, 2007 9:11 AM
To: Bram Verburg
Cc: sip
Subject: Re: [Sip] INFO

SIP-T is not a session initiation protocol.  It is a set of conventions
for TUNNELING proprietary signaling events over SIP.  Key word there is
TUNNELING.  That is the clue that section 3.3 applies.

all

>> That said, let's be real: I don't think anyone will abandon SIP-T at 
>> this late date.  Although this really is a counter example, I would 
>> liken this to the story in:
>> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  
>> the use of the individual or entity named in this message. If you are

>> not From [email-masked] Thu Sep 06 11:16:56 2007
Content-class: urn:content-classes:message
Subject: RE: [Sip] INFO - more on SIP-T
Date: Thu, 6 Sep 2007 11:00:14 -0400
From: "Rafferty, James" <[email-masked]>
To: "Henry Sinnreich" <[email-masked]>, "Eric Burger" <[email-masked]>,
	"Bram Verburg" <[email-masked]>
Cc: sip <[email-masked]>

Henry, 

Our company can either map SS7 to SIP, or use SIP-T in our gateways.
The main reason to use SIP-T (or what the ITU-T/3GPP calls SIP-I) is to
more completely preserve the SS7 parameter information for SS7 bridging
applications.  If the desire is to cut over completely to SIP, then the
direct mapping approach works, but much of the SS7 semantics are lost.
We see more of the SS7 to SIP mapping than the use of SIP-T these days.

James

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2007 11:35 AM
To: Eric Burger; Bram Verburg
Cc: sip
Subject: RE: [Sip] INFO - more on SIP-T

Thanks, Henry 

Oh yes,...

Henry

-----Original Messagthe intended recipient, and have received this message in error, 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 6 Sep 2007 12:36:55 -0700

James,

Thanks for the useful data.

> We see more of the SS7 to SIP mapping than the use of SIP-T these
days.

This makes sense since given the large number of SS7 variants; it is a
flexible solution that keeps the SS7 variant complexity at the edge of
the IP network.

SIP-T for bridging applications would probably make sense in a
homogeneous network, but given the almost weekly merger and acquisition
stories and the probably 100 SS7 variants, this does not seem a flexible
solution without some SS7-SS7 converters at some endpoints :-)

SIP in the middle is indeed the best choice.

Any comments?

Thanks again, Henry

-----Original Message-----
From: Rafferty, James [mailto:[email-masked]] 
Sent: Thursday, September 06, 2007 10:00 AM
To: Henry Sinnreich; Eric Burger; Bram Verburg
Cc: sip
Subject: RE: [Sip] INFO - more on SIP-T

Henry, 

James

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2007 11:35 AM
To: Eric Burger; Bram Verburg
Cc: sip
Subject: RE: [Sip] INFO - more on SIP-T

Thanks, Henry 

Oh yes,...

Henry

-----Original Message-----
From: Eric Burger [mailto:[email-masked]]
Sent: Wednesday, September 05, 2007 9:11 AM
To: Bram Verburg
Cc: sip
Subject: Re: [Sip] INFO

all

>> not the intended recipient, and have received this message in error,

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 7 Sep 2007 13:32:55 -0500

Agreed.

For what it's worth, I see the same thing in the Enteprise space where
there is a move to mapping and native SIP, away from various
"tunnelling"
techniques.

Tunnelling is sooooo 1998 :^)

> Sent: Thursday, September 06, 2007 12:37
> To: Rafferty, James; Eric Burger; Bram Verburg
> Cc: sip
> This makes sense since given the large number of SS7 
> variants; it is a flexible solution that keeps the SS7 
> variant complexity at the edge of the IP network.
> 
> SIP-T for bridging applications would probably make sense in 
> a homogeneous network, but given the almost weekly merger and 
> acquisition stories and the probably 100 SS7 variants, this 
> does not seem a flexible solution without some SS7-SS7 
> converters at some endpoints :-)
> 
> The main reason to use SIP-T (or what the ITU-T/3GPP calls 
> SIP-I) is to more completely preserve the SS7 parameter 
> information for SS7 bridging applications.  If the desire is 
> to cut over completely to SIP, then the direct mapping 
> approach works, but much of the SS7 semantics are lost.

---

From: "Bram Verburg" <[email-masked]>
Date: Sun, 9 Sep 2007 10:17:54 +0300

> in the same way you synchronize receiving the INFO. 

For those messages that are today sent using INFO there is no
difference. I was referring to messages being sent in
INVITE/BYE/CANCEL/...

I can't help feeling this would be a step back, in a way. I like to
think of SIP-T as an interim solution to speed up the deployment of SIP
technology by service providers who still have one leg (or two,
actually) in the old SS7 world. Over time, as more and more core
networks are migrated to SIP (IMS/TISPAN/...), the need for SIP-T will
disappear.

Apart from the infamous INFO method, I'm still not convinced anything is
'wrong' with SIP-T, and that it needs to be replaced. Especially since,
as others have pointed out, it already seems to be on its way out.

But I must admit that I haven't had a chance yet to read your draft
thoroughly. I'll do that now...

Bram

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 10 Sep 2007 21:00:28 +0200

I don't think those (and there are quite a few of them) doing DTMF with INFO will abandon it at this late date...

> Sent: 5. syyskuuta 2007 16:09
> To: Bram Verburg
> Cc: sip
> Subject: Re: [Sip] INFO
>

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 10 Sep 2007 14:03:53 -0500

Which is to say that you don't have to do DTMF exclusively with INFO.
You could use 2833/4733 in conjunction or exclusion to INFO depending
upon your needs. It becomes messy when nobody wants to acknowledge and
describe these mechanisms (with the goal of coming up with something
coherent as a means of using them).

Regards,
Brian 

> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: Monday, September 10, 2007 2:00 PM
> I don't think those (and there are quite a few of them) doing 
> DTMF with INFO will abandon it at this late date...
> 
> SIP-T at 
> > copyrighted  and/or legally privileged, and is intended 
> solely for the 
> > use of the individual or entity named in this message. If 
> you are not 
> > the intended recipient, and have received this message in error,