From gautyada@gmail.com Mon Aug 8 05:26:25 2011 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 3155421F8AE1 for ; Mon, 8 Aug 2011 05:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 SkQnyE65fWdY for ; Mon, 8 Aug 2011 05:26:24 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 08EEF21F8ABC for ; Mon, 8 Aug 2011 05:26:23 -0700 (PDT) Received: by gxk19 with SMTP id 19so853852gxk.31 for ; Mon, 08 Aug 2011 05:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qp1MTMX2dcQhvCxldJ0g9rHUi41UH150bPKXjG9UIc4=; b=bjR5NSpXHYEppeWjnSCPV5pMED1d+ALeh/fPtUXDG5uQIn1E5x2ia5jdBFT/7ehiWP jlq0jogx7JDQx7whEKPVCO/PgX+CtBfB2G4qbP10o1qA5tpxvrbywoL3aLUOxhu4pVdF qf9X+Kit+izy/omX+5ftquBoz0gABZeq/i/l0= MIME-Version: 1.0 Received: by 10.143.79.14 with SMTP id g14mr5083334wfl.68.1312806409402; Mon, 08 Aug 2011 05:26:49 -0700 (PDT) Received: by 10.142.81.13 with HTTP; Mon, 8 Aug 2011 05:26:49 -0700 (PDT) In-Reply-To: References: <4E244A60.6020508@bell-labs.com> Date: Mon, 8 Aug 2011 17:56:49 +0530 Message-ID: From: Gautam Yadav To: vkg@bell-labs.com, fluffy@cisco.com Content-Type: multipart/alternative; boundary=000e0ce0accab0fa3b04a9fd8f97 Cc: 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: Mon, 08 Aug 2011 12:28:17 -0000 --000e0ce0accab0fa3b04a9fd8f97 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 =E0 Switch-1 --- = SIP Trunk --=E0 Switch-2 --=E0 B. We need to transport the trunk group paramet= ers 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. 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 by implication allow the SIP URI also and not just tel URI. Thanks & Regards, Gautam Yadav On Mon, Aug 8, 2011 at 5:43 PM, Gautam Yadav wrote: > > > ---------- Forwarded message ---------- > From: Vijay K. Gurbani > Date: Mon, Jul 18, 2011 at 8:29 PM > Subject: Re: How To Give Suggestions > To: Gautam Yadav > Cc: fluffy@cisco.com > > > Gautam Yadav wrote: > >> Hi Vijay, Cullen, >> hope you are doing good. >> I was going through the RFC 4904 and I have few suggestions to make in >> this rfc. I really don't know how to go about it. Please share the proce= dure >> with me. >> > > Gautam: Normally, the procedure is to post a message > to the working group that sponsored the RFC in question. > > For rfc4094, that would be the iptel working group. However, > iptel has been concluded as a working group (having met > its deliverables). That said, the mailing list for iptel is > still alive. > > As a first cut, please post your suggestions to me and Cullen, > with iptel list in the Cc. If you feel that your suggestions > need to be documented as errata to the RFC, please state so. > If your suggestions are more along the lines of "How do I > do this ...", then a better place to post would be the iptel > list and the sip-implementors list. > > The iptel working group page is available at > http://www.ietf.org/wg/**concluded/iptel.html. > More > information about the mailing list, etc. is available > there. > > Cheers, > > - 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 > Web: http://ect.bell-labs.com/who/**vkg/ > > --000e0ce0accab0fa3b04a9fd8f97 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Vijay, Cullen,
=A0
Sorry for the delayed response as I was busy with some other activitie= s.
=A0
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.
=A0
From Section 2:
=A0

The aim of this specification is to outline how to struct= ure and

=A0=A0 represent= the trunk group parameters as an extension to the tel URI

=A0=A0 [4] in a = standardized manner.

=A0

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 p= icture.

=A0

Problem Statement: We have the call scenario of MGCP to M= GCP call where A and B parties are on different soft-switches. Topology: A = =E0 Switch-1 --- SIP Trunk = --=E0 Switch-2 =A0--=E0 B. We need to transport the trunk group parameters in the Con= tact Header and called ID needs to be hidden because of the privacy concern= s. 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 ref= erring to the rfc 3323 and encoding =93Anonymous=94 but the switch-2 is ref= erring the rfc 4904 and expects tel URI and =93557=94 in its user part.

=A0

=A0

My Suggestion/Query: Is it =A0possible to increase the scope of the rfc 4904 and consider t= he SIP trunks also and not just the SS7 trunks and by implication allow the= SIP URI also and not just tel URI.

=A0

=A0

Thanks & Regards,

Gautam Yadav



On Mon, Aug 8, 2011 at 5:43 PM, Gautam Yadav <gautam.singh.yadav@gmail.com> wrote:


---------- Forwarded message ----------
From:= Vijay K. Gurbani <<= a href=3D"mailto:vkg@bell-labs.com" target=3D"_blank">vkg@bell-labs.com= >
Date: Mon, Jul 18, 2011 at 8:29 PM
Subject: Re: How To Give Suggestions<= br>To: Gautam Yadav <gautam.singh.yadav@gmail.com>
Cc: fluffy@cisco.com


Gautam Yadav wrote:
Hi Vijay, Cullen,
=A0hope you= are doing good.
=A0I was going through the RFC 4904 and I have few sugg= estions to make in this rfc. I really don't know how to go about it. Pl= ease share the procedure with me.

Gautam: Normally, the procedure is to post a message=
to the working group that sponsored the RFC in question.

For rfc= 4094, that would be the iptel working group. =A0However,
iptel has been = concluded as a working group (having met
its deliverables). =A0That said, =A0the mailing list for iptel is
still = alive.

As a first cut, please post your suggestions to me and Cullen= ,
with iptel list in the Cc. =A0If you feel that your suggestions
nee= d to be documented as errata to the RFC, please state so.
If your suggestions are more along the lines of "How do I
do this .= ..", then a better place to post would be the iptel
list and the si= p-implementors list.

The iptel working group page is available at h= ttp://www.ietf.org/wg/concluded/iptel.html. =A0More
informati= on about the mailing list, etc. is available
there.

Cheers,
- 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
Web: =A0 ht= tp://ect.bell-labs.com/who/vkg/


--000e0ce0accab0fa3b04a9fd8f97--