Subject: RE: [Sipping] TCAP tunneling

From: "Hearty, John" <[email-masked]>
Date: Wed, 11 Feb 2004 16:50:26 -0700

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 12 Feb 2004 15:39:27 -0500

Hearty, John wrote:

> populated when forwarding SIP messages.

A URI can represent just about anything. I didnt find a URN namespace 
defined for containing people names; I suspect this is because of 
difficulty in uniqueness. But, in principle one could do:

urn:people:Jonathan.D.Rosenberg

In this case you would need to define an enumservices that maps phone 
numbers to people URNs.

>  I suppose we could still do TXT
> the statement that SIP isn't a database query protocol. 

Well, let me clarify. SIP is not itself a database protocol. However, 
when a DB query is involved in the process of proxying a request, you 
can access a SIP service that effectively performs a proxy operation to 
the result of the DB lookup.

Fardad writes:
> 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.  

Redirectors would not add a PAI; it says the wrong thing. It would 
assert the identity of the element generating the response, which is not 
what you want here. The redirect would look like this:

SIP/2.0 301 Name Added
Contact: 
sip:[email-masked]?P-Asserted-ID=John%20Example%20<[email-masked]>

In other words, the redirected-to URI contains a header parameter, which 
the "requesting" proxy would automatically populate into the outgoing 
request. Of course it would need to trust the source of the header, as a 
proxy should not normally accept a redirect with a p-asserted-id.

Thanks,
Jonathan R.

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Thu, 12 Feb 2004 22:05:10 +0000

Hi folks,
  ... and, from my explorations, people commonly use TXT records for 
names.
It's a hack but it works for human displayable items.
Anything more complex (like URN stuff) maybe cleaner but requires more 
work.

BTW, often the TXT records I see are 'cos folk haven't set their "split 
horizon"
correctly in BIND.

Number -> is a major privacy issue for many, and this will be an issue 
whatever
scheme one uses; NAPTRs use/are DNS so a 'people' URN NAPTR doesn't 
help.

Just my 14 centimes.

atb,
   Lawrence

On 12 Feb 2004, at 8:39 pm, Jonathan Rosenberg wrote:

> can access a SIP service that effectively performs a proxy operation 
> to the result of the DB lookup.
>
> Fardad writes:
> assert the identity of the element generating the response, which is 
> not what you want here. The redirect would look like this:
>
> SIP/2.0 301 Name Added
> Contact: 
> In other words, the redirected-to URI contains a header parameter, 
> which the "requesting" proxy would automatically populate into the 
> outgoing request. Of course it would need to trust the source of the 
> header, as a proxy should not normally accept a redirect with a 
> p-asserted-id.
>
> Thanks,
> Jonathan R.
>
>
>
> --