Subject: RE: [Sipping] MIME media types for SCCP and TCAP Objects

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 24 Mar 2005 17:27:50 -0500

Hi Seamus,

Personally, I think there might be two reasons, why one would like to do
something like that:
a)Using SIP as transport for IP offloading
b)Expecting SIP UAs, to be aware of IN/AIN concepts/protocols to receive
services

b), I would call imposing PSTN domain constructs in SIP domain -and also to
certain degree the architecture itself-, because things like BSCM, EDP-R,
PromptAndCollectInformation, TC-BEGIN, invokeId are not native to SIP. IMHO,
for such cases, the first step needs to be to figure out, how to provide
that service in a pure SIP-way. I believe for service interworking, the
starting question should be "What does the service?" rather than "How is
this service implemented in PSTN?".

For a), I believe it is clear that it reduces SIP to a transport protocol,
which it isn't.

  Tolga

> -----Original Message-----
> From: Seamus Gilchrist [mailto:[email-masked]]
> Sent: Thursday, March 24, 2005 5:04 PM
> To: 'Tolga Asveren'; [email-masked]
> Subject: RE: [Sipping] MIME media types for SCCP and TCAP Objects
>
>
> Tolga,
>
> >IMO the approach shouldn't be:
> >1- Impose PSTN concepts/architecture in SIP domain
>
> I don't think adding the SCCP/TCSP MIME capability as Vikram proposes
> "imposes" the PSTN architecture in the SIP domain.
>
> Seamus
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Tolga Asveren
> Sent: Thursday, March 24, 2005 3:12 PM
> To: [email-masked]
> Subject: RE: [Sipping] MIME media types for SCCP and TCAP Objects
>
> Vikram,
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Vikram Nair
> > Sent: Thursday, March 24, 2005 11:31 AM
> > To: [email-masked]
> > Subject: Re: [Sipping] MIME media types for SCCP and TCAP Objects
> >
> >
> > Hello, to all the respected list members.
> >
> > There had been few discussion over past couple of days on this topic.
> > I would like to sumarize those and get some more valuable inputs.
> >
> > 1) List is yet to get an answers as to how ISUP/QSIG model is
> > different from the SCCP/TCAP model. There was a genuine comment in the
> > list that
> >
> > 	"These efforts centered around transporting ISUP
> > 	 and QSIG messages in SIP messages that mean
> > 	 roughly the same thing as the messages they
> > 	 carry -- which means that existing user agents
> > 	 who don't know ISUP or QSIG will "do the right
> > 	 thing" upon receipt of such messages"
> >
> > The same holds true for SCCP/TCAP messages as explained in the
> > previous post  citing some examples. Like call signaling messages in
> > ISUP, similar call signaling messages in IN/AIN.
> [TOLGA]Conceptually there is quite some difference between those
> cases. With
> QSIG/ISUP, you are trying to offload a call via IP. The embedded ISUP/QSIG
> information is necessary to make the PSTN far-end leg of this
> communciation
> to work properly, it is not used by SIP UA logic. With SCCP/TCAP case, you
> expect the SIP device to be aware of those concepts.
> >
> > Are we saying that people when working for ISUP/QSIG MIMEs were unable
> > to locate the http://www.ietf.org/rfc/rfc3332.txt ?
> [TOLGA]I would think, for pure IP offloading scenarios, BICC migt
> be a good
> alternative but people probably choose SIP, because they want to be
> future-safe, i.e. they don;t want to replace much in the core
> network, when
> SIP UAs become more popular.
> >
> > We should look here that the question is not about protocol selection
> > towards PSTN domain. Rather analyzing the need to communicate such
> > info. between SIP nodes in SIP network where rfc3332 might not make
> > sense.
> >
> > 2) Suggestion:
> >
> > 	"If you need to interwork with a PSTN entity
> > 	 -e.g. SCP-, you just have a GW functionality
> > 	 at the boundary and that is it. There is
> > 	 definitly no need to expose IN/AIN concepts
> > 	to SIP domain."
> >
> > Agreed. The GW will do interworking. But what about parameters which
> > does not find place holder in SIP. And still a deployment needs to
> > travel the last mile in SIP domain with such a useful information.
> >
> > 3) Suggestion:
> >
> > 	"IMHO, if there is an event in IN/AIN domain, which
> > 	 does not have an equivalent in SIP domain -and if
> > 	 there is really a need for it-, SIP domain signaling
> > 	 needs to be enhanced -for example extending dialog
> > 	 package-, rather than requiring SIP domain entities
> > 	 to know about PSTN concepts/messages/protocols."
> >
> > This is the reason of having SCCP/TCAP MIME as an alternate to,
> > waiting for a new extension when everyone knows how to interpret
> > "Carrier" or "AlternateCarrier" (AIN prameters) and go ahead and
> > deploy the solution.
> [TOLGA]IMO, the approach should be:
> 1- First try to understand -independent of PSTN concepts- how to implement
> the reqested service purely in SIP domain -consistent with SIP
> architecture,
> which foresees intelligent endpoints-.
> 2- If there is information, which needs to be convesyed by UA, Proxy,
> Application Server etc.., and which can't be carried with some SIP message
> currently, extend the protocol.
> 3- Now, you know how to provide that service in SIP domain, interworking
> with PSTN is trivial with a gateway.
>
> IMO the approach shouldn't be:
> 1- Impose PSTN concepts/architecture in SIP domain
> 2- Try a parameter-to-parameter mapping rather than a mapping on service
> level
>
> BTW, people usually use HTTP as transport in IP domain, why insisting on
> SIP, in case there is a need to carry some information? (I am not
> proposing
> HTTP to carry SCCP/TCAP :-) )
> >
> > tx
> > - Vikram
> >
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

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

---

From: "Seamus Gilchrist" <[email-masked]>
Date: Thu, 24 Mar 2005 17:54:44 -0500

Tolga,

I don't disagree with your points, IMHO by having such an option you are not
imposing anything.

Seamus

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tolga Asveren
Sent: Thursday, March 24, 2005 5:28 PM
To: [email-masked]
Subject: RE: [Sipping] MIME media types for SCCP and TCAP Objects

Hi Seamus,

  Tolga