Subject: RE: [Sipping] TCAP tunneling

From: "Farahmand, Fardad" <[email-masked]>
Date: Thu, 12 Feb 2004 11:31:31 -0500

The Yu draft describes a redirector or proxy which would perform the LNP for
the called number. The redirector would add a Contact in 3XX with the
information about the ported number. The proxy would add the information to
the R-URI.

CNAM is a bit different since we are dealing with the calling party
information. I am a bit confused about Jonathan's comment regarding adding
the CNAM information to the Contact header. It seems that the right approach
would be for Proxies to add a PAI with display name.  Looking at RFC3325, it
seems that PAI can also be present in 3XX responses.  So potentially
redirectors can also add CNAM information by adding a PAI.  

So it seems like there are standard methods of introducing LNP and CNAM
services in SIP networks.  But what about all the other TCAP based services?
This is yet to be resolved.

Thanks,
Fardad

> -----Original Message-----
> From: Hearty, John [mailto:[email-masked]]
> Sent: Wednesday, February 11, 2004 6:50 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]; Peterson, Jon
> Subject: RE: [Sipping] TCAP tunneling
> 
> 
> In looking at the ENUM RFC, it looks like NAPTR records are used, and
> they convert E.164 numbers to URIs.  The syntax for the URIs does not
> appear to allow for Display Names, which is what I believe needs to be
> populated when forwarding SIP messages.  I suppose we could 
> still do TXT
> type DNS records for this, but can't find any standards specific to
> CNAM.  The alternate idea similar to the yu draft seems to contradict
> the statement that SIP isn't a database query protocol.  If anyone is
> already doing something like this or has plans I'd love to hear about
> it.
> 
> John
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:[email-masked]]
> > Sent: Monday, February 02, 2004 11:29 PM
> > To: Hearty, John
> > Cc: [email-masked]; Peterson, Jon
> > Subject: Re: [Sipping] TCAP tunneling
> > 
> > SIP isnt a database query protocol, and cnam is just a DB query
> service.
> > As such, I would think that enum would be an appropriate 
> technique for
> > this. Any other DB query mechanism will do as well.
> > 
> > Another idea would be to use a redirect service, similar to what has
> > been proposed in the past for LNP:
> > 
> > http://www.watersprings.org/pub/id/draft-yu-sip-np-02.txt
> > 
> > except that a request for a number would be redirected to a Contact
> > which contains that number plus the display name, representing the
> > calling name.
> > 
> > -Jonathan R.
> > 
> > Hearty, John wrote:
> > > Other than the miller draft below, is there any SIP standard
> proposed to
> > > carry cnam queries?
> > >
> > > John Hearty
> > > Level3
> > >
> > >
> > >>-----Original Message-----
> > >>From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > >
> > > Of
> > >
> > >>Arjun Roychowdhury
> > >>Sent: Monday, February 02, 2004 7:25 AM
> > >>To: Banibrata Dutta
> > >>Cc: [email-masked]; [email-masked];
> > >>[email-masked]; [email-masked]
> > >>Subject: RE: [Sipping] TCAP tunneling
> > >>
> > >>Actually, there _is_ an independant draft on how to carry TCAP in
> SIP.
> > >>http://www.ietf.org/internet-drafts/draft-miller-sip-tcap-00.txt
> > >>
> > >>Its another matter whether this is the right thing to do or not
> > >
> > > (please
> > >
> > >>refer to old archives for the debates).
> > >>Kaitaki, you may want to read the above draft as well as the
> > >
> > > discussions
> > >
> > >>on it to conclude for yourself which is the preferred 
> method in your
> > >>deployment scenario.
> > >>
> > >>regds
> > >>arjun
> > >>
> > >>
> > >>--
> > >>Arjun Roychowdhury @ Hughes Software Systems
> > >>11717 Exploration Lane, Germantown MD 20876
> > >>(O): 301 212 7860
> > >>VOIP: (SIP) [email-masked] (PSTN alias:360-207-0467)
> > >>
> > >>
> > >>
> > >>
> > >>"Banibrata Dutta" <[email-masked]>
> > >>Sent by: [email-masked]
> > >>02/02/2004 12:25 AM
> > >>
> > >>
> > >>        To:     <[email-masked]>,
> > >
> > > <[email-masked]>,
> > >
> > >><[email-masked]>
> > >>        cc:
> > >>        Subject:        RE: [Sipping] TCAP tunneling
> > >>
> > >>
> > >>hi,
> > >>
> > >>franly, i'd say that, it depends on your motivation/reason to use
> SIP
> > >>for
> > >>tunneling TCAP. of course you can tunnel TCAP, but why you'd want
> to,
> > >
> > > is
> > >
> > >>a justification you'd have to work out. AFAIK, there's not
> ietf-draft
> > >>that
> > >>says, how.
> > >>
> > >>you can obviously tunnel TCAP query in an INVITE or INFO for that
> > >
> > > matter
> > >
> > >>(ideally in INVITE s.t. a SIP-dialog is also created which may be
> used
> > >>to
> > >>model the TCAP dialog as well, perhaps!). the ASN.1 BER 
> encoded TCAP
> > >>messages may then reside within the body of a multi-part 
> (MIME) enc,
> > >>INVITE.
> > >>
> > >>infact 1 reason i see where this may make sense is that you would
> > >
> > > rather
> > >
> > >>not have two stacks s.a. SIGTRAN and SIP for signalling transport,
> and
> > >>use
> > >>SIP as the *only* signalling solution, i.e. for the signalling
> > >>application
> > >>as well as for signalling transport, and support 
> legacy/TCAP apps by
> > >>tunneling
> > >>them within SIP. but then, you generally have the constraints of
> > >>not-enough-
> > >>space, (for 2 stacks) only on resource-limited devices, s.a.
> > >
> > > hand-sets,
> > >
> > >>embedded devices etc., but i am unable see (yet), how TCAP can be
> > >>related to
> > >>such devices.
> > >>
> > >>my 2 cents,
> > >>Banibrata Dutta,
> > >>  Hewlett-Packard ISO (P) Ltd,
> > >>  29, Cunningham Road,
> > >>  Bangalore - 560052
> > >>  Ph: +91-80-22051796
> > >>
> > >>
> > >>>-----Original Message-----
> > >>>From: [email-masked] [mailto:[email-masked]]
> > >>>On Behalf Of [email-masked]
> > >>>Sent: Monday, February 02, 2004 10:20 AM
> > >>>To: [email-masked]; [email-masked]
> > >>>Subject: RE: [Sipping] TCAP tunneling
> > >>>
> > >>>
> > >>>Hi
> > >>>   TCAP is used for Transaction Capabilities i.e database
> > >>>related while SIP with ISUP tunneling is used between MGCs.
> > >>>So I don't think TCAP can be tunneled in SIP.
> > >>>
> > >>>Ranjit
> > >>>Ph: 8520408/16 extn: 2173
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>-----Original Message-----
> > >>>From: [email-masked] [mailto:[email-masked]]
> > >>>On Behalf Of Kaitki Agarwal
> > >>>Sent: Monday, February 02, 2004 8:28 AM
> > >>>To: [email-masked]
> > >>>Subject: [Sipping] TCAP tunneling
> > >>>
> > >>>
> > >>>Hi
> > >>> Can we tunnel tcap message in SIP as we do  ISUP. If not why.
> > >>>
> > >>>Thanks
> > >>>Kaitki
> > >>>Jj~Yzy=i~Rz}y
> > >>>
> > >>>_______________________________________________
> > >>>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
> > >
> > >
> > > _______________________________________________
> > > 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
> > >
> > 
> > --
> > Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> > Chief Technology Officer                    Parsippany, NJ 
> 07054-2711
> > dynamicsoft
> > [email-masked]                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> 
> _______________________________________________
> 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: "Tolga Asveren" <[email-masked]>
Date: Thu, 12 Feb 2004 11:53:44 -0500

A few thoughts below....

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Farahmand, Fardad
> Sent: Thursday, February 12, 2004 11:32 AM
> To: 'Hearty, John'; Jonathan Rosenberg
[TOLGA]Maybe the key point is that the services are *not* based on TCAP,
TCAP is just a way to do synchronous remote procedure calls, so it does not
really have service related semantics. Important is, what is transferred on
top of TCAP (e.g. INAP), and I would think in such a case, the best way is
thinking on a per service bases rather than trying to encapsulate such a
protocol (afterall also for INAP just the protocol is standardized by ITU,
there are different ways to implement a certain service from message flow
point of view)