From gautyada@gmail.com Thu Mar 22 00:20:24 2012 Return-Path: X-Original-To: iptel@ietfa.amsl.com Delivered-To: iptel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B06821E8044 for ; Thu, 22 Mar 2012 00:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uf2W9qh+FsQw for ; Thu, 22 Mar 2012 00:20:23 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3F421E8036 for ; Thu, 22 Mar 2012 00:20:22 -0700 (PDT) Received: by werb10 with SMTP id b10so1847731wer.31 for ; Thu, 22 Mar 2012 00:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OG3Bpx3OT8hNb+cFCZkB4cYz4lsBZM/vD3NhbKAQOXE=; b=XYoD5y0K28XMUDqjexb+gDUHNHgi3yRoRoLMiJ+4wLj1yQD2HOjTilju5zghSottCW mXU+cGS2nLMgQsNcdxCASG6tL1OygsJihPaih7P15mOt/oUk4sYOipRebjHPh8z0CySe o5RBrQeVzHtFVfB6jRtF/3dt09ouGe4RnYO00tOiw6U2kMf6w/dhLLQl9/r4EJZsFzbR Q4eYX541jxyZtw5cwlpaRoeQJ73Hh28brZJKOppUi32mwif+tAjZVkeQ0ijTJo5wY/7M 1Y5bvhLq4N7c6Sj/l9KP/DxNZtvGVIVZ2OQVVwKMFYlYH20Jnzd67R+VTWJW7ankPi7r 1mcw== MIME-Version: 1.0 Received: by 10.216.225.12 with SMTP id y12mr3868969wep.39.1332400821443; Thu, 22 Mar 2012 00:20:21 -0700 (PDT) Received: by 10.180.88.228 with HTTP; Thu, 22 Mar 2012 00:20:21 -0700 (PDT) In-Reply-To: References: <4E244A60.6020508@bell-labs.com> <4E3FE736.3000004@bell-labs.com> Date: Thu, 22 Mar 2012 12:50:21 +0530 Message-ID: From: Gautam Yadav To: "Vijay K. Gurbani" Content-Type: multipart/alternative; boundary=00504502ce2aa91cc604bbcfbd0c Cc: fluffy@cisco.com, iptel@ietf.org Subject: Re: [Iptel] How To Give Suggestions X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 07:20:24 -0000 --00504502ce2aa91cc604bbcfbd0c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Vijay, Hope your are doing good. any thoughts on the trailing mail? Thanks, Gautam On Wed, Sep 7, 2011 at 2:43 PM, Gautam Yadav wrote: > Hi Vijay, > > thanks for your response. Please allow me to try one more time to explain > my point with help of an example. I have attached a call flow for your > reference. > > "A" party is the subscriber of Switch-1 and has taken a service called > "Caller Identity Delivery Supression" (CIDS). "B" party is the subscriber > of Switch-2. Switch-1 and Switch-2 are connected through SIP trunk. Also = we > need to transport the trunk group parameters in the contact header of the > INVITE message when A places the call to B. This is how the INVITE from > Switch-1 to Switch-2 looks like: > > > INVITE sip:5746064748@192.168.10.10:5060;user=3Dphone SIP/2.0 > > Via: SIP/2.0/UDP 192.168.10.20:5060;branch=3Dz9hG4bK_1103250270916482186 > > From: "Anonymous" >;tag=3D1_1103_f25027_yt52_CtkM381990 > > To: > > Call-ID: 0793308353@192.168.10.20 > > CSeq: 1 INVITE > > Max-Forwards: 70 > > Supported: 100rel,timer,replaces,unknown > > *Contact: context=3Dcontext-1;transport=3Dudp> * > > Allow: > INVITE,ACK,BYE,CANCEL,OPTIONS,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,REFER,= UPDATE > > Min-SE: 900 > > Session-Expires: 1800;refresher=3Duac > > Privacy: id > > Content-Length: 246 > > Content-Type: application/sdp > > The Switch-1 has constructed this INVITE message by refering to RFC 4904 > for encoding trunk group parameters and RFC 3323 for hiding the A > party's (Caller's) identity and ecnoded the "Anonymous" in the contact > header. > > Now, on receiving this INVITE the Switch-2 is rejecting the call because > it is saying that it expects a tel URI in the contact header if it contai= ns > the tgrp parameters as mentioned in RFC 4904. Switch-2 guys are also > saying that any locally generated number at Switch-1 can be placed in > contact header if the Caller's identity is to be hidden so that they can > convert It into a tel uri. > > Now the problem is that both the switches are from different vendors and > they have there respective arguments. Switch-1 guys are saying since RFC > 3323 says that you can use "Anonymous" in case caller id is to be hidden > which makes it a SIP uri and Switch-2 guys are saying that since tgrp > parameters are present in contact header they expect a tel uri in it. > Switch-2 guys are basing there argument on the fact that RFC 4904 says > that tgrp parameters must be in tel uri. RFC 4904 tallks about tel uri > because it talks about the SS7 trunks. But I am talking about SIP trunks = in > my case. That's why I had said that is it possible to include SIP trunks = in > rfc 4904 and allow the use of SIP uri along with tgrp parameters. > > Thanks, > Gautam > > > > On Mon, Aug 8, 2011 at 7:10 PM, Vijay K. Gurbani wrote= : > >> Please see inline. >> >> >> On 08/08/2011 07:26 AM, Gautam Yadav wrote: >> >>> Hi Vijay, Cullen, >>> >>> Sorry for the delayed response as I was busy with some other activities= . >>> My suggestion is with regards to the rfc 4904 and it comes from on of >>> the inter-operational that I faced. I am starting by quoting the aim of >>> the rfc 4904 to begin with followed by problem statement and suggestion= . >>> From Section 2: >>> >>> The aim of this specification is to outline how to structure and >>> >>> represent the trunk group parameters as an extension to the tel URI >>> >>> [4] in a standardized manner. >>> >>> My Understanding: I believe the rfc 4904 talks about the extension to >>> the tel URI only because it specifically talks about the >>> inter-operational issues for the scenarios where SIP to SS7 gateways >>> come into picture. >>> >>> Problem Statement: We have the call scenario of MGCP to MGCP call where >>> A and B parties are on different soft-switches. Topology: A =E0Switch-1 >>> --- SIP Trunk --=E0Switch-2 --=E0B. We need to transport the trunk grou= p >>> >>> parameters in the Contact Header and called ID needs to be hidden >>> because of the privacy concerns. Our contact header looks like: Contact= : >>> SIP:Anonymous;tgrp=3D1000;trunk-**context=3Dcontext-1@192.168.10.**20 >>> >. >>> We are >>> >>> facing an inter-operational issue because of this contact header. >>> Switch-1 is referring to the rfc 3323 and encoding =93Anonymous=94 but = the >>> switch-2 is referring the rfc 4904 and expects tel URI and =93557=94 in= its >>> user part. >>> >> >> As far as I can tell, you appear to be having the problem because >> Switch-1 is encoding an anonymous identifier whereas Switch-2 is >> expecting an identity of some sort (probably a telephone extension) >> in the Contact header. >> >> >> My Suggestion/Query: Is it possible to increase the scope of the rfc >>> 4904 and consider the SIP trunks also and not just the SS7 trunks and b= y >>> implication allow the SIP URI also and not just tel URI. >>> >> >> I can't see how increasing the scope of rfc4904 will help you here. >> You need to impart the identity to Switch-2 by some means, if that is >> what it wants. Doing so will be outside the scope of rfc4904. >> >> That said, there are ways around this but at the philosophical level, >> if the sender has decided to stay anonymous and you can still correlate >> that sender to a specific identity, then the assumed anonymity of the >> system is not of much help. >> >> You could be wanting to anonymise the caller ID during transit only, and >> not to provide a complete anonymity service. If that is the case, then >> you could correlate the identity at Switch-2, but again, doing so is >> outside the scope of rfc4904 as far as I can see it. >> >> Thanks, >> >> >> - vijay >> -- >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) >> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.**com<= vijay.gurbani@alcatel-lucent.com> >> Web: http://ect.bell-labs.com/who/**vkg/ >> > > --00504502ce2aa91cc604bbcfbd0c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Vijay,

Hope your are doing good.

=
any thoughts on the trailing mail?

Thanks,
Gautam



On Wed, Sep 7, 2011 at 2:43 PM, Gautam Yadav <gautyada@gmail.com> wrote:
=
Hi Vijay,
=A0
thanks for your response. Please allow me to try one more time to expl= ain my point with help of an example. I have attached a call flow for your = reference.
=A0
"A" party is the subscriber of Switch-1 and has taken a serv= ice called "Caller Identity Delivery Supression" (CIDS). "B&= quot; party is the subscriber of Switch-2. Switch-1 and Switch-2 are connec= ted through SIP trunk. Also we need to transport the trunk group parameters= in the contact header of the INVITE message when A places the call to B. T= his is how the INVITE from Switch-1 to Switch-2 looks like:
=A0

INVITE sip:5746064748@192.168.10.10:5060;user=3Dphone SIP/2.0

Via: SIP/2.0/UDP=A0 192.168.10.20:5060;branch=3Dz9h= G4bK_1103250270916482186

From: "Anonymous"<sip:Anonymous@Anonymous.invalid&g= t;;tag=3D1_1103_f25027_yt52_CtkM381990

To: <sip:5746064748@domain-1.com;user=3Dphone>

Call-ID: 0793308353@192.168.10.20

CSeq: 1=A0=A0=A0=A0=A0=A0 INVITE

Max-Forwards: 70

Supported: 100rel,timer,replaces,unknown

Contact: <sip:Anonymous;tgrp=3D1000;trunk- context= =3Dcontext-1;transport=3Dudp>

Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,REGISTER,INFO,PRACK,SUBSCRI= BE,NOTIFY,REFER,UPDATE

Min-SE: 900

Session-Expires: 1800;refresher=3Duac

Privacy: id

Content-Length:=A0=A0=A0 246

Content-Type: application/sdp


The Switch-1 has constructed this INVITE message by refering to RF= C 4904 for encoding trunk group parameters and RFC 3323=A0for hiding the=A0= A party's=A0(Caller's) identity and ecnoded the "Anonymous&quo= t; in the contact header.
=A0
Now, on receiving this INVITE the Switch-2 is rejecting the call=A0bec= ause it is saying that it expects a tel URI in the contact header if it con= tains the tgrp parameters as mentioned in RFC 4904.=A0Switch-2 guys are als= o saying=A0that any locally generated number at=A0Switch-1 can be placed in= contact header if the Caller's identity is to be hidden so that they c= an convert=A0It=A0into a tel uri.
=A0
Now the problem is that both the switches are from different vendors a= nd they have=A0there respective arguments. Switch-1 guys are saying since R= FC 3323=A0says that you can use "Anonymous" in case caller id is = to be hidden which makes it a SIP uri and Switch-2 guys are saying that sin= ce tgrp parameters are present in contact header they expect a tel uri in i= t. Switch-2 guys are basing there argument on the fact that RFC 4904 says t= hat=A0tgrp parameters=A0must be in tel uri.=A0RFC 4904 tallks about tel uri= because it talks about the SS7 trunks.=A0But I am talking about SIP trunks= in my case. That's why I had said that is it possible to include SIP t= runks in rfc 4904 and allow the use of=A0SIP uri along with tgrp parameters= .
=A0
Thanks,
Gautam
=A0

=A0
On Mon, Aug 8, 2011 at 7:10 PM, Vijay K. Gurbani= <vkg@bell-labs.com> wrote:
Please see inline.=20


On 08/08/2011 07:26 AM, Gautam Yadav wrote:
Hi Vijay, Cullen,=20

Sorry for the delayed response as I was busy with some other activ= ities.
My suggestion is with regards to the rfc 4904 and it comes from o= n of
the inter-operational that I faced. I am starting by quoting the ai= m of
the rfc 4904 to begin with followed by problem statement and suggestion.=A0From Section 2:

The aim of this specification is to outline how = to structure and

represent the trunk group parameters as an extensio= n to the tel URI

[4] in a standardized manner.

My Understanding: I believe the rf= c 4904 talks about the extension to
the tel URI only because it specific= ally talks about the
inter-operational issues for the scenarios where SI= P to SS7 gateways
come into picture.

Problem Statement: We have the call scenario of M= GCP to MGCP call where
A and B parties are on different soft-switches. T= opology: A =E0Switch-1
--- SIP Trunk --=E0Switch-2 --=E0B. We need= to transport the trunk group=20

parameters in the Contact Header and called ID needs to be hidden<= br>because of the privacy concerns. Our contact header looks like: Contact:=
SIP:Anonymous;tgrp=3D1000;trunk-context=3Dcontext-1@192.168.10.20
<sip:Anonymous;tgrp=3D1000;trunk-context=3Dcontext-1@192.168.10.20= >. We are=20

facing an inter-operational issue because of this contact header.<= br>Switch-1 is referring to the rfc 3323 and encoding =93Anonymous=94 but t= he
switch-2 is referring the rfc 4904 and expects tel URI and =93557=94 = in its
user part.

As far as I can tell, you appear to be= having the problem because
Switch-1 is encoding an anonymous identifier= whereas Switch-2 is
expecting an identity of some sort (probably a tele= phone extension)
in the Contact header.=20


My Suggestion/Query: Is it possible t= o increase the scope of the rfc
4904 and consider the SIP trunks also an= d not just the SS7 trunks and by
implication allow the SIP URI also and not just tel URI.
I can't see how increasing the scope of rfc4904 will help you h= ere.
You need to impart the identity to Switch-2 by some means, if that = is
what it wants. =A0Doing so will be outside the scope of rfc4904.

Tha= t said, there are ways around this but at the philosophical level,
if th= e sender has decided to stay anonymous and you can still correlate
that = sender to a specific identity, then the assumed anonymity of the
system is not of much help.

You could be wanting to anonymise the ca= ller ID during transit only, and
not to provide a complete anonymity ser= vice. =A0If that is the case, then
you could correlate the identity at S= witch-2, but again, doing so is
outside the scope of rfc4904 as far as I can see it.

Thanks,=20


- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel= -Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)Email: vkg@{bell-labs= .com,acm.org} / vijay.gurb= ani@alcatel-lucent.com
Web: =A0 ht= tp://ect.bell-labs.com/who/vkg/


--00504502ce2aa91cc604bbcfbd0c--