Return-Path: <moharana_p@yahoo.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81B013A68D1 for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 04:16:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.455
X-Spam-Level: 
X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[AWL=0.320,  BAYES_05=-1.11, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UskJ2kJVG+Dm for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 04:16:51 -0800 (PST)
Received: from web110502.mail.gq1.yahoo.com (web110502.mail.gq1.yahoo.com [67.195.8.250]) by core3.amsl.com (Postfix) with SMTP id D1CE13A6991 for <sigtran@ietf.org>; Mon,  2 Mar 2009 04:16:51 -0800 (PST)
Received: (qmail 23499 invoked by uid 60001); 2 Mar 2009 12:17:17 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1235996237; bh=IQXYgFO4Cx3s2IAwx4BzQnXRgkD4Gh0goRsEQfk8B8Y=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=nth0ikdPOk0MdlZfBcJOTVVJ/tIfo0y++RfVaMppaQrR+Ng5eTybOE4alrxP6I8eLq0U8W1dQjqRcXitnqeSas7l7RwIL0DcKU/ycZegtMMRQZ5h7hnyyLiCDeZ7sZ2iMUlgCS3cz5j/Y3Ea/TZ81nfL8SxmpfWjLknvTE7PuzI=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=45xGPLZFbKcftVWQ5dhmsNpq+Y6NVlnR8X7A4aAMnx2PDt6+kD1vbaz4ypMksuu8gF/9Gg74iBWWipf0QZ/bhi3vdPLfDPQ2Z9HeGWTtaeb3sowfGFdypFlaJlGlw0S5ZZV7sgUuGI6mMlxBh1z9OTdwTXH9wDKza/6svq44Pxc=;
Message-ID: <745412.23091.qm@web110502.mail.gq1.yahoo.com>
X-YMail-OSG: vPbPTY0VM1kao94K.s19qogPWJNwHHzWH8fIf6Uxyf7nRWcVwoYbHgnQq4QU7mVFpu6oa.XX.BFX01BmZgjfLMu98.DI5iI35zPqgVCLlzvuFsSjvNuTjWAVefMUckkvY2X9XA_.OC52RdD4s1Z0YoQCHWw6EyFW1odDKyT0wu.y989rsCPz7Dmt6Hpz6yaIIyL_PxDTySXj.oASXu1xR5bHcOWO6MtoIqPSysXnF8pcW1njIUjBh61_5XJ89R4-
Received: from [220.227.132.178] by web110502.mail.gq1.yahoo.com via HTTP; Mon, 02 Mar 2009 04:17:17 PST
X-Mailer: YahooMailWebService/0.7.289.1
Date: Mon, 2 Mar 2009 04:17:17 -0800 (PST)
From: moharana_p@yahoo.com
To: sigtran <sigtran@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1099068016-1235996237=:23091"
Cc: bidulock <bidulock@openss7.org>
Subject: [Sigtran] query regarding ASP Identifier in ASP UP ACK .
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: moharana_p@yahoo.com
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2009 12:16:52 -0000

--0-1099068016-1235996237=:23091
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,
=A0
As per the rfc-4666.
=A0
3.5.2.=A0 ASP Up Acknowledgement (ASP Up Ack)
......
=A0=A0 The optional ASP Identifier parameter is specifically useful for IPS=
P
=A0=A0 communication.=A0 In that case, the IPSP answering the ASP Up messag=
e
=A0=A0 MAY include its own ASP Identifier value.
=A0
Since ASP Identifier is used to identify the ASP with in an AS so in ASP UP=
 ACK message ASP Identifier value should be the value that received in ASP =
UP message in stead of=A0its own ASP Identifier value.
=A0
If No then what is the role of ASP identifier in case of IPSP mode?
=A0
Br,
Padmalochan=A0
=A0=0A=0A=0A      
--0-1099068016-1235996237=:23091
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><DIV>Hello,</DIV>
<DIV>&nbsp;</DIV>
<DIV>As per the rfc-4666.</DIV>
<DIV>&nbsp;</DIV>
<DIV>3.5.2.&nbsp; ASP Up Acknowledgement (ASP Up Ack)</DIV>
<DIV>......</DIV>
<DIV>&nbsp;&nbsp; The optional ASP Identifier parameter is specifically use=
ful for IPSP<BR>&nbsp;&nbsp; communication.&nbsp; In that case, the IPSP an=
swering the ASP Up message<BR>&nbsp;&nbsp; MAY include its own ASP Identifi=
er value.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Since ASP Identifier is used to identify the ASP with in an AS so in A=
SP UP ACK message ASP Identifier value should be the value that received in=
 ASP UP message in stead of&nbsp;its own ASP Identifier value.</DIV>
<DIV>&nbsp;</DIV>
<DIV>If No then what is the role of ASP identifier in case of IPSP mode?</D=
IV>
<DIV>&nbsp;</DIV>
<DIV>Br,</DIV>
<DIV>Padmalochan&nbsp;</DIV>
<DIV>&nbsp;</DIV></td></tr></table><br>=0A=0A      
--0-1099068016-1235996237=:23091--


Return-Path: <moharana_p@yahoo.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DE4D3A6C3E for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 05:47:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.562
X-Spam-Level: 
X-Spam-Status: No, score=-0.562 tagged_above=-999 required=5 tests=[AWL=0.213,  BAYES_05=-1.11, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X52gEfmPgjaR for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 05:47:10 -0800 (PST)
Received: from web110505.mail.gq1.yahoo.com (web110505.mail.gq1.yahoo.com [67.195.8.253]) by core3.amsl.com (Postfix) with SMTP id 649223A6B23 for <sigtran@ietf.org>; Mon,  2 Mar 2009 05:47:06 -0800 (PST)
Received: (qmail 56308 invoked by uid 60001); 2 Mar 2009 13:47:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236001652; bh=MTDVVlfbUEEBg9U9aCD3s2+5CJZolGCH4HFIG/RXa1g=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=wrOsFasBiyfUSTxHJqTcFcUObtRZlL1VV29O1A7Gui07WP/ru9Y6QKcuIMGTuXeHaf7B/HBDu2cxuFCmhqgReqcKxk2JmLu2Wv7G4qbnI46ADF9VxyuSC43GxVyYzNZSQ06DumahmsNKll2IBsrA/uK8s3MSs+bmK65ZchCKWI8=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=HhOPyvYwZxia19GzLzyZED3FQvmfLNpnh9eobMj0CutlfX2ObEibFVwVhIVpqlM8g195lsa81lUo4iBID99SgPWZHXpARB6JoXnGbh7sTyaaoGSZFdOrbfw0I63Iu9exZ90b9DzubRGfIy6q3o/1coCOFfYHIyO8ZO+MLX7Mvr4=;
Message-ID: <390585.52841.qm@web110505.mail.gq1.yahoo.com>
X-YMail-OSG: vd69NnMVM1nH7Vaduv.DT0Q4EQOCWe3QQiJaDPelz7km.65xWSxCBX9i6i.KghYNJn3oQowZ.hvPHhEetRIEC.QWajYwLoS5fILA8q.qc5UHUl.Kh.e29HgFLFBZgqN2qf0GCvq.jOI01xPTaAcMIHc5h4TqJRtuRcZvUp.AcGwiM4Fz2xfFmUaVyUYXTMBBHgeWUY5PmrY_zYtYG_IxjaipvdQf6HlRfaXsBuK87xWkGn1.QFOFKTXl4GmazVw-
Received: from [220.227.132.178] by web110505.mail.gq1.yahoo.com via HTTP; Mon, 02 Mar 2009 05:47:32 PST
X-Mailer: YahooMailWebService/0.7.289.1
Date: Mon, 2 Mar 2009 05:47:32 -0800 (PST)
From: moharana_p@yahoo.com
To: sigtran <sigtran@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-2011012932-1236001652=:52841"
Cc: bidulock <bidulock@openss7.org>
Subject: [Sigtran] SCCP connection refusal
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: moharana_p@yahoo.com
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2009 13:47:11 -0000

--0-2011012932-1236001652=:52841
Content-Type: text/plain; charset=us-ascii

Hi,
In what scenario the peer node SCCP reject SCCP Connection with cause "end user originated" ? I had glance in SCCP spec for the scenario when this can happen but I could not find scenario. Please clarify my query. "


Thanks. 



      
--0-2011012932-1236001652=:52841
Content-Type: text/html; charset=us-ascii

<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi,<BR>In what scenario the peer node SCCP reject SCCP Connection with cause "end user originated" ? I had glance in SCCP spec for the scenario when this can happen but I could not find scenario. Please clarify my query. "<BR><BR><BR>Thanks. <BR></td></tr></table><br>



      
--0-2011012932-1236001652=:52841--


Return-Path: <bidulock@openss7.org>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8223A689C for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 05:56:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jt4OV3shWBIR for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 05:56:24 -0800 (PST)
Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 6BB313A67FB for <sigtran@ietf.org>; Mon,  2 Mar 2009 05:56:24 -0800 (PST)
Received: from wilbur.pigworks.openss7.net (IDENT:58BVOuB/w1wJ32zMwM1uB/k9FkpOz+uB@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id n22DunoP010170; Mon, 2 Mar 2009 06:56:49 -0700
Received: from wilbur.pigworks.openss7.net (IDENT:8Me0tWHxWnSQKfWF6KEG8tyJ48wDKiKC@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id n22DunKk016963; Mon, 2 Mar 2009 06:56:49 -0700
Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id n22Dun5n016962; Mon, 2 Mar 2009 06:56:49 -0700
Date: Mon, 2 Mar 2009 06:56:49 -0700
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: moharana_p@yahoo.com
Message-ID: <20090302135649.GC16129@openss7.org>
Mail-Followup-To: moharana_p@yahoo.com, sigtran <sigtran@ietf.org>
References: <390585.52841.qm@web110505.mail.gq1.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <390585.52841.qm@web110505.mail.gq1.yahoo.com>
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-To: <blockme@openss7.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: sigtran <sigtran@ietf.org>
Subject: Re: [Sigtran] SCCP connection refusal
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2009 13:56:25 -0000

moharana_p,

As it implies: when the peer user requests an abort.

--brian

moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009 05:47:32)
> 
>    Hi,
>    In what scenario the peer node SCCP reject SCCP Connection with cause
>    "end user originated" ? I had glance in SCCP spec for the scenario
>    when this can happen but I could not find scenario. Please clarify my
>    query. "
>    Thanks.

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/


Return-Path: <bidulock@openss7.org>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45653A69DA for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 06:01:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level: 
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEsqooAQ2bRu for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 06:01:48 -0800 (PST)
Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id AAC063A6905 for <sigtran@ietf.org>; Mon,  2 Mar 2009 06:01:48 -0800 (PST)
Received: from wilbur.pigworks.openss7.net (IDENT:4JwGK9jyihbCb48x8SS43u0DGCx7t0Kj@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id n22E2EkK010270; Mon, 2 Mar 2009 07:02:14 -0700
Received: from wilbur.pigworks.openss7.net (IDENT:WCkjXaVbtUUFPF1y9J1uy0w0uF3S03kf@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id n22E2E2e017238; Mon, 2 Mar 2009 07:02:14 -0700
Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id n22E2EGe017237; Mon, 2 Mar 2009 07:02:14 -0700
Date: Mon, 2 Mar 2009 07:02:14 -0700
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: moharana_p@yahoo.com
Message-ID: <20090302140214.GD16129@openss7.org>
Mail-Followup-To: moharana_p@yahoo.com, sigtran <sigtran@ietf.org>
References: <745412.23091.qm@web110502.mail.gq1.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <745412.23091.qm@web110502.mail.gq1.yahoo.com>
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-To: <blockme@openss7.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: sigtran <sigtran@ietf.org>
Subject: Re: [Sigtran] query regarding ASP Identifier in ASP UP ACK .
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2009 14:01:49 -0000

moharana_p,

I have no idea what special use there is for IPSP.

Because the sender of the ASP UP forms the SCTP association,
it should know the identity of the ASP to which it is sending it.
It is the receiver of the ASP UP, that accepted the SCTP
association, that may not be able to derived from a dynamically
allocated port number on the connecting peer, the ASP Id of
the sender of the ASP UP.


--brian


moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009 04:17:17)
> 
>    Hello,
> 
>    As per the rfc-4666.
> 
>    3.5.2.  ASP Up Acknowledgement (ASP Up Ack)
>    ......
>       The optional ASP Identifier parameter is specifically useful for
>    IPSP
>       communication.  In that case, the IPSP answering the ASP Up message
>       MAY include its own ASP Identifier value.
> 
>    Since ASP Identifier is used to identify the ASP with in an AS so in
>    ASP UP ACK message ASP Identifier value should be the value that
>    received in ASP UP message in stead of its own ASP Identifier value.
> 
>    If No then what is the role of ASP identifier in case of IPSP mode?
> 
>    Br,
>    Padmalochan

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/


Return-Path: <moharana_p@yahoo.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C63BD3A69CA for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 20:41:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.059
X-Spam-Level: 
X-Spam-Status: No, score=-1.059 tagged_above=-999 required=5 tests=[AWL=0.605,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pepHshwGwqoF for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 20:41:05 -0800 (PST)
Received: from web110515.mail.gq1.yahoo.com (web110515.mail.gq1.yahoo.com [67.195.8.120]) by core3.amsl.com (Postfix) with SMTP id BF9343A67DD for <sigtran@ietf.org>; Mon,  2 Mar 2009 20:41:05 -0800 (PST)
Received: (qmail 32581 invoked by uid 60001); 3 Mar 2009 04:41:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236055292; bh=ntvHQIlIfhZZ7nKnmRJsuJoISmgLNEf5tsbTelonQX8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=6Uyfq81470DnBAghPl5P7jBo18EwtY7v+0NURZbc9AaKRACLNChFMhNEdq9WXgIlyzBxcdjBnolMVLSKrHBLz773H4Qy99yXqfFJPZ88BMJh3PziGF/HIe19qfx+9y1mWfaXfPNVSjj9SOXcQTZIhwbEdhIaF/s9Nom+WQ9xc9s=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=6cUuoKukDrmumoW9N8B9SdLDa05n8sV5+Y+C1+R4BgBUp8SkDwQSEaWEY/RTmL5SlGR4FcfKrX6oYCmaiT0ekHrE9hxK1ZfV3zYkEAHpWl4gQKTbh2DBdI28+608d9AZKkqAMa1o5uCoCfEUBDeWK4y4EvHdLHSEo/fAULTlZaQ=;
Message-ID: <386162.32355.qm@web110515.mail.gq1.yahoo.com>
X-YMail-OSG: pp2qCJIVM1lZBBrYGpGf7E.KtRx0dhmqrIl.4yuK0q3BVODuOfSjwiErphOI9VDAjSrTuYahkepLQ.zi6g0zJX.YZheOtB_Z0vQXCW6vGj1M88Z6zzXCF7aZ6nKiHnWbhkAcRQYQXUCMuP7s2.1ZNuXtSrcxmOfHnpV6poI7G.q8.xQM1IVxhcyxrud.vVSsX5rrhZlsxPNsZ8WqKQaBqYUkFhmQMBiym84CKQPlfFP8ouub3DHpauUJ0nASvm.AkU.0ytL.H9ZU0BwQ6ejMKB9Fx5V7fQ--
Received: from [220.227.132.178] by web110515.mail.gq1.yahoo.com via HTTP; Mon, 02 Mar 2009 20:41:32 PST
X-Mailer: YahooMailWebService/0.7.289.1
Date: Mon, 2 Mar 2009 20:41:32 -0800 (PST)
From: moharana_p@yahoo.com
To: bidulock@openss7.org
In-Reply-To: <20090302140214.GD16129@openss7.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-2064825526-1236055292=:32355"
Cc: sigtran <sigtran@ietf.org>
Subject: Re: [Sigtran] query regarding ASP Identifier in ASP UP ACK .
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: moharana_p@yahoo.com
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2009 04:41:06 -0000

--0-2064825526-1236055292=:32355
Content-Type: text/plain; charset=us-ascii

Brian, 
The SCTP association still UP. We did not notice any ABORT. If there was an ABORT, SCCP connection request would n't have gone till peer node SCCP layer which is above M3UA. 

Thanks 


--- On Mon, 3/2/09, Brian F. G. Bidulock <bidulock@openss7.org> wrote:

From: Brian F. G. Bidulock <bidulock@openss7.org>
Subject: Re: query regarding ASP Identifier in ASP UP ACK .
To: moharana_p@yahoo.com
Cc: "sigtran" <sigtran@ietf.org>
Date: Monday, March 2, 2009, 8:02 AM

moharana_p,

I have no idea what special use there is for IPSP.

Because the sender of the ASP UP forms the SCTP association,
it should know the identity of the ASP to which it is sending it.
It is the receiver of the ASP UP, that accepted the SCTP
association, that may not be able to derived from a dynamically
allocated port number on the connecting peer, the ASP Id of
the sender of the ASP UP.


--brian


moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009 04:17:17)
> 
>    Hello,
> 
>    As per the rfc-4666.
> 
>    3.5.2.  ASP Up Acknowledgement (ASP Up Ack)
>    ......
>       The optional ASP Identifier parameter is specifically useful for
>    IPSP
>       communication.  In that case, the IPSP answering the ASP Up message
>       MAY include its own ASP Identifier value.
> 
>    Since ASP Identifier is used to identify the ASP with in an AS so in
>    ASP UP ACK message ASP Identifier value should be the value that
>    received in ASP UP message in stead of its own ASP Identifier value.
> 
>    If No then what is the role of ASP identifier in case of IPSP mode?
> 
>    Br,
>    Padmalochan

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/



      
--0-2064825526-1236055292=:32355
Content-Type: text/html; charset=us-ascii

<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Brian, <BR>The SCTP association still UP. We did not notice any <SPAN class=yshortcuts id=lw_1236055230_0>ABORT</SPAN>. If there was an ABORT, SCCP connection request would n't have gone till peer node SCCP layer which is above M3UA. <BR><BR>Thanks <BR><BR><BR>--- On <B>Mon, 3/2/09, Brian F. G. Bidulock <I>&lt;bidulock@openss7.org&gt;</I></B> wrote:<BR>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(16,16,255) 2px solid">From: Brian F. G. Bidulock &lt;bidulock@openss7.org&gt;<BR>Subject: Re: query regarding ASP Identifier in ASP UP ACK .<BR>To: moharana_p@yahoo.com<BR>Cc: "sigtran" &lt;sigtran@ietf.org&gt;<BR>Date: Monday, March 2, 2009, 8:02 AM<BR><BR><PRE>moharana_p,

I have no idea what special use there is for IPSP.

Because the sender of the ASP UP forms the SCTP association,
it should know the identity of the ASP to which it is sending it.
It is the receiver of the ASP UP, that accepted the SCTP
association, that may not be able to derived from a dynamically
allocated port number on the connecting peer, the ASP Id of
the sender of the ASP UP.


--brian


moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009 04:17:17)
&gt; 
&gt;    Hello,
&gt; 
&gt;    As per the rfc-4666.
&gt; 
&gt;    3.5.2.  ASP Up Acknowledgement (ASP Up Ack)
&gt;    ......
&gt;       The optional ASP Identifier parameter is specifically useful for
&gt;    IPSP
&gt;       communication.  In that case, the IPSP answering the ASP Up message
&gt;       MAY include its own ASP Identifier value.
&gt; 
&gt;    Since ASP Identifier is used to identify the ASP with in an AS so in
&gt;    ASP UP ACK message ASP Identifier value should be the value that
&gt;    received in ASP UP message in stead of its own ASP Identifier value.
&gt; 
&gt;    If No then what is the role of ASP identifier in case of IPSP mode?
&gt; 
&gt;    Br,
&gt;    Padmalochan

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
</PRE></BLOCKQUOTE></td></tr></table><br>



      
--0-2064825526-1236055292=:32355--


Return-Path: <moharana_p@yahoo.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC55E3A69CA for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 20:41:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.18
X-Spam-Level: 
X-Spam-Status: No, score=-1.18 tagged_above=-999 required=5 tests=[AWL=0.484,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cMFUHBVsxbo for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 20:41:47 -0800 (PST)
Received: from web110512.mail.gq1.yahoo.com (web110512.mail.gq1.yahoo.com [67.195.8.117]) by core3.amsl.com (Postfix) with SMTP id 2480F3A67DD for <sigtran@ietf.org>; Mon,  2 Mar 2009 20:41:47 -0800 (PST)
Received: (qmail 43622 invoked by uid 60001); 3 Mar 2009 04:42:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236055333; bh=GexhDfBhwGmn75NJpk9gpqAiy6ncG+qScvL1KBuw8aQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=aF/20f8b9B9/83RcT0Wvtp5XnrxOeLtjsPD70rqGFV61H63L4ITAQ1JIk7MZV7acVlzURR1aBLmd61cCs85b7FLJS93n3dU7eQEV2jc0D0rn+HXA9kF/8e9E9kFksS11HIdFy4ytlfvdJ1mTzD3b/jc0BOuvi/uc2yQmIm+PZ/0=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0nVClOsX0+Z6+0zMOxNzpFNw38yU+KpDDlhxEGnfQRiloIwQUenAagxlcdA/pZEQD32T+GrYqzgV9aSvHz2LBAlZg8Su6tRXhXhMirafAcog982DtTyn0hx+G1y5Iabx3GtKixg6w1s6SWBHCYEJQbDIh0+QDqWND4hpmVhhg8M=;
Message-ID: <735541.42480.qm@web110512.mail.gq1.yahoo.com>
X-YMail-OSG: gYee0bEVM1nAa8bn1w9RYXNuwz1Ga_0S5sbd3jDd_iPtXYzbLcOKBH_vNRkueQyrxJlHk8smxZilG82efAF3VbMuMNBTTaXlz7qR7TlB0HQsWiQn6d2FO_SZ06KgMlhFRqX6BQ1Mq_RjXSFGbUfNcyNxgaf4YNTBnwCyHL.Fc30s1_.AFlAFFi1ovAXwNzrdx5fRDnT2R2TdRwl8P1xvkYwmkaaGGosS_jjQBq79e6xpNup1wBLanRQikSaTzjKwsalQTGIRgipCWFCOEeEHqH_2PCsh_A--
Received: from [220.227.132.178] by web110512.mail.gq1.yahoo.com via HTTP; Mon, 02 Mar 2009 20:42:13 PST
X-Mailer: YahooMailWebService/0.7.289.1
Date: Mon, 2 Mar 2009 20:42:13 -0800 (PST)
From: moharana_p@yahoo.com
To: bidulock@openss7.org
In-Reply-To: <20090302135649.GC16129@openss7.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1802036907-1236055333=:42480"
Cc: sigtran <sigtran@ietf.org>
Subject: Re: [Sigtran] SCCP connection refusal
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: moharana_p@yahoo.com
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2009 04:41:48 -0000

--0-1802036907-1236055333=:42480
Content-Type: text/plain; charset=us-ascii

Brian, 
The SCTP association still UP. We did not notice any ABORT. If there was an ABORT, SCCP connection request would n't have gone till peer node SCCP layer which is above M3UA. 

Thanks 

--- On Mon, 3/2/09, Brian F. G. Bidulock <bidulock@openss7.org> wrote:

From: Brian F. G. Bidulock <bidulock@openss7.org>
Subject: Re: SCCP connection refusal
To: moharana_p@yahoo.com
Cc: "sigtran" <sigtran@ietf.org>
Date: Monday, March 2, 2009, 7:56 AM

moharana_p,

As it implies: when the peer user requests an abort.

--brian

moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009 05:47:32)
> 
>    Hi,
>    In what scenario the peer node SCCP reject SCCP Connection with cause
>    "end user originated" ? I had glance in SCCP spec for the
scenario
>    when this can happen but I could not find scenario. Please clarify my
>    query. "
>    Thanks.

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/



      
--0-1802036907-1236055333=:42480
Content-Type: text/html; charset=us-ascii

<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Brian, <BR>The SCTP association still UP. We did not notice any <SPAN class=yshortcuts id=lw_1236055230_0>ABORT</SPAN>. If there was an ABORT, SCCP connection request would n't have gone till peer node SCCP layer which is above M3UA. <BR><BR>Thanks <BR><BR>--- On <B>Mon, 3/2/09, Brian F. G. Bidulock <I>&lt;bidulock@openss7.org&gt;</I></B> wrote:<BR>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(16,16,255) 2px solid">From: Brian F. G. Bidulock &lt;bidulock@openss7.org&gt;<BR>Subject: Re: SCCP connection refusal<BR>To: moharana_p@yahoo.com<BR>Cc: "sigtran" &lt;sigtran@ietf.org&gt;<BR>Date: Monday, March 2, 2009, 7:56 AM<BR><BR><PRE>moharana_p,

As it implies: when the peer user requests an abort.

--brian

moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009 05:47:32)
&gt; 
&gt;    Hi,
&gt;    In what scenario the peer node SCCP reject SCCP Connection with cause
&gt;    "end user originated" ? I had glance in SCCP spec for the
scenario
&gt;    when this can happen but I could not find scenario. Please clarify my
&gt;    query. "
&gt;    Thanks.

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
</PRE></BLOCKQUOTE></td></tr></table><br>

      
--0-1802036907-1236055333=:42480--


Return-Path: <moharana_p@yahoo.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84DF3A6B12 for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 22:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Level: 
X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[AWL=0.703,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SGqkTQxgurp for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 22:01:40 -0800 (PST)
Received: from web110501.mail.gq1.yahoo.com (web110501.mail.gq1.yahoo.com [67.195.8.249]) by core3.amsl.com (Postfix) with SMTP id 34FC03A6ABE for <sigtran@ietf.org>; Mon,  2 Mar 2009 22:01:37 -0800 (PST)
Received: (qmail 27636 invoked by uid 60001); 3 Mar 2009 06:02:04 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236060124; bh=5uGiQlU6oPs/MDpJ1AhAFzQUUiuln7zFBQSc/Pa5sSA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=tXhLNiPrBBVxfBWMDX34DJ4P1DfHPPzqPHpTruPib+1Mam65HX/uuGPo7DiTjjahKPDVfgUDP0nw7PwygLSEJyBoZZH8X6KQbnvc83bkmNuJUX1C19l6/sAr2V6rtXvL5t7IC/ilSzLHTc5okMnV26H85LsdIeu41Je6iLtgCrE=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=M/fnz9nLl7PRc2ITh6zVa4u2LjkfrVoh0DQ4xs4rrYWb4s5sy5rEe7LOc0aurkAx51InRJNWQr6Jedy56YlS0wR2p+K+L881TROV+2S03HdsaIywg5gPFxQ8MwYQlmN6z0WGPXZc42rFD3mHgqNW7UCc2gXkwQClb/6Pn2f6qZc=;
Message-ID: <22136.27430.qm@web110501.mail.gq1.yahoo.com>
X-YMail-OSG: w6Qvuz4VM1kel3DkQG2UpcI2ayoXglfqei8Gvht1PnBXWmd85d8_gm7P.VZjgf8HvELp6zIL03SwDf_SVjD1cr.3r.5J8qWcF3LduNQIhqhXvQyEa8LPFrEia8QlmAN6aSBTwEivcGTZAQESBDutu_mPZrSaGQqbD8jEHe9Ey7fHhsKMWCvszo1mG2Wgw0if6oQj.68lxvH0P5aVLhcCbDNzSpEG.SWIrnxIIry3HemW8n.fYJeCRCMMcsF6r4fxLuxoV9POtx7w5GpwWa9cS5sOuT469w--
Received: from [220.227.132.178] by web110501.mail.gq1.yahoo.com via HTTP; Mon, 02 Mar 2009 22:02:03 PST
X-Mailer: YahooMailWebService/0.7.289.1
Date: Mon, 2 Mar 2009 22:02:03 -0800 (PST)
From: moharana_p@yahoo.com
To: bidulock@openss7.org
In-Reply-To: <20090302140214.GD16129@openss7.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1413206199-1236060123=:27430"
Cc: sigtran <sigtran@ietf.org>
Subject: Re: [Sigtran] query regarding ASP Identifier in ASP UP ACK .
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: moharana_p@yahoo.com
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2009 06:01:40 -0000

--0-1413206199-1236060123=:27430
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi ,
=A0
Should the ASP identifier comming in received ASP UP message=A0same as the =
ASP identifire value in ASP UP ACK=A0?
=A0
Br,
Padmalochan


--- On Mon, 3/2/09, Brian F. G. Bidulock <bidulock@openss7.org> wrote:

From: Brian F. G. Bidulock <bidulock@openss7.org>
Subject: Re: query regarding ASP Identifier in ASP UP ACK .
To: moharana_p@yahoo.com
Cc: "sigtran" <sigtran@ietf.org>
Date: Monday, March 2, 2009, 8:02 AM

moharana_p,

I have no idea what special use there is for IPSP.

Because the sender of the ASP UP forms the SCTP association,
it should know the identity of the ASP to which it is sending it.
It is the receiver of the ASP UP, that accepted the SCTP
association, that may not be able to derived from a dynamically
allocated port number on the connecting peer, the ASP Id of
the sender of the ASP UP.


--brian


moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009 04:17:17)
>=20
>    Hello,
>=20
>    As per the rfc-4666.
>=20
>    3.5.2.  ASP Up Acknowledgement (ASP Up Ack)
>    ......
>       The optional ASP Identifier parameter is specifically useful for
>    IPSP
>       communication.  In that case, the IPSP answering the ASP Up message
>       MAY include its own ASP Identifier value.
>=20
>    Since ASP Identifier is used to identify the ASP with in an AS so in
>    ASP UP ACK message ASP Identifier value should be the value that
>    received in ASP UP message in stead of its own ASP Identifier value.
>=20
>    If No then what is the role of ASP identifier in case of IPSP mode?
>=20
>    Br,
>    Padmalochan

--=20
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
=0A=0A=0A      
--0-1413206199-1236060123=:27430
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><DIV>Hi ,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Should the ASP identifier comming in received ASP UP message&nbsp;same=
 as the ASP identifire value in ASP UP ACK&nbsp;?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Br,</DIV>
<DIV>Padmalochan</DIV>
<DIV><BR><BR>--- On <B>Mon, 3/2/09, Brian F. G. Bidulock <I>&lt;bidulock@op=
enss7.org&gt;</I></B> wrote:<BR></DIV>
<BLOCKQUOTE style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(=
16,16,255) 2px solid">From: Brian F. G. Bidulock &lt;bidulock@openss7.org&g=
t;<BR>Subject: Re: query regarding ASP Identifier in ASP UP ACK .<BR>To: mo=
harana_p@yahoo.com<BR>Cc: "sigtran" &lt;sigtran@ietf.org&gt;<BR>Date: Monda=
y, March 2, 2009, 8:02 AM<BR><BR><PRE>moharana_p,

I have no idea what special use there is for IPSP.

Because the sender of the ASP UP forms the SCTP association,
it should know the identity of the ASP to which it is sending it.
It is the receiver of the ASP UP, that accepted the SCTP
association, that may not be able to derived from a dynamically
allocated port number on the connecting peer, the ASP Id of
the sender of the ASP UP.


--brian


moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009 04:17:17)
&gt;=20
&gt;    Hello,
&gt;=20
&gt;    As per the rfc-4666.
&gt;=20
&gt;    3.5.2.  ASP Up Acknowledgement (ASP Up Ack)
&gt;    ......
&gt;       The optional ASP Identifier parameter is specifically useful for
&gt;    IPSP
&gt;       communication.  In that case, the IPSP answering the ASP Up mess=
age
&gt;       MAY include its own ASP Identifier value.
&gt;=20
&gt;    Since ASP Identifier is used to identify the ASP with in an AS so i=
n
&gt;    ASP UP ACK message ASP Identifier value should be the value that
&gt;    received in ASP UP message in stead of its own ASP Identifier value=
.
&gt;=20
&gt;    If No then what is the role of ASP identifier in case of IPSP mode?
&gt;=20
&gt;    Br,
&gt;    Padmalochan

--=20
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
</PRE></BLOCKQUOTE></td></tr></table><br>=0A=0A      
--0-1413206199-1236060123=:27430--


Return-Path: <moharana_p@yahoo.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57BC83A6B12 for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 22:01:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.661
X-Spam-Level: 
X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[AWL=0.603,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS7EHvDqA8jB for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 22:01:51 -0800 (PST)
Received: from web110511.mail.gq1.yahoo.com (web110511.mail.gq1.yahoo.com [67.195.8.116]) by core3.amsl.com (Postfix) with SMTP id 788C63A6ABE for <sigtran@ietf.org>; Mon,  2 Mar 2009 22:01:51 -0800 (PST)
Received: (qmail 46233 invoked by uid 60001); 3 Mar 2009 06:02:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236060138; bh=STiIHeZkmeczbBNX8bzR4Q+z/4GM3K18O5zBpgZ+7jI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fEskdT8LkzuYU7Lek8Ih70BVeiOMeUtvPxMRoLnwRS9+aHwviGQXY00p37dtzBxQiq3B/M42TBN912dwYPh8FLsBauQzdDBOZScZS1vLevMNDKBb7xeXSR9L10XRVI/hfVpKNgtf+/o9JmrVoLUkG8RDyfI/tOXmA7dmLHPbUuE=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Qv2XEn5T7mU/gPs5xdNcDLG/LMn7nMaBm/7qpEZrYzHLtMPlhf+ItZxygTvlKk87upkYns3tI5+Ib4bKf4autbLFSyUBeg0pGo7uRH7YjRSmgqRb11BG8I/ImODhaCI7UBjm6KE2gURWeiZ23PIzk4q8Sg+plkCOMzbNuNi2C0c=;
Message-ID: <116045.45954.qm@web110511.mail.gq1.yahoo.com>
X-YMail-OSG: wbVfpioVM1mUHcYPJEwEGDW9U9WIVioJI_PVZE2bpt16GQi7g33c5gmhdOrkUEeUU0zwvNn7ld1FAPzZJqTs7RGZ4WqYsD0gErKsoTflH8cNv9uPl7S2NSumAlDpk_OVLVnSwWJNYQQ90ObcNY3sfiiWqFol5jbwwraVGyfsGiKvx9BdoTAv6uOhStLok0a7lfV9xUQWjykk48MRHbR6eSNUy8l9QoSU_0kvwfcTHPWuJhIE08QWMbrqpOw6O3myDkDDyoLy6HAXk5F_fQcVJeJxCZXV.w--
Received: from [220.227.132.178] by web110511.mail.gq1.yahoo.com via HTTP; Mon, 02 Mar 2009 22:02:17 PST
X-Mailer: YahooMailWebService/0.7.289.1
Date: Mon, 2 Mar 2009 22:02:17 -0800 (PST)
From: moharana_p@yahoo.com
To: bidulock@openss7.org
In-Reply-To: <20090302140214.GD16129@openss7.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1598044556-1236060137=:45954"
Cc: sigtran <sigtran@ietf.org>
Subject: Re: [Sigtran] query regarding ASP Identifier in ASP UP ACK .
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: moharana_p@yahoo.com
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2009 06:01:52 -0000

--0-1598044556-1236060137=:45954
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi ,
=A0
Should the ASP identifier comming in received ASP UP message=A0same as the =
ASP identifire value in ASP UP ACK=A0?
=A0
Br,
Padmalochan


--- On Mon, 3/2/09, Brian F. G. Bidulock <bidulock@openss7.org> wrote:

From: Brian F. G. Bidulock <bidulock@openss7.org>
Subject: Re: query regarding ASP Identifier in ASP UP ACK .
To: moharana_p@yahoo.com
Cc: "sigtran" <sigtran@ietf.org>
Date: Monday, March 2, 2009, 8:02 AM

moharana_p,

I have no idea what special use there is for IPSP.

Because the sender of the ASP UP forms the SCTP association,
it should know the identity of the ASP to which it is sending it.
It is the receiver of the ASP UP, that accepted the SCTP
association, that may not be able to derived from a dynamically
allocated port number on the connecting peer, the ASP Id of
the sender of the ASP UP.


--brian


moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009 04:17:17)
>=20
>    Hello,
>=20
>    As per the rfc-4666.
>=20
>    3.5.2.  ASP Up Acknowledgement (ASP Up Ack)
>    ......
>       The optional ASP Identifier parameter is specifically useful for
>    IPSP
>       communication.  In that case, the IPSP answering the ASP Up message
>       MAY include its own ASP Identifier value.
>=20
>    Since ASP Identifier is used to identify the ASP with in an AS so in
>    ASP UP ACK message ASP Identifier value should be the value that
>    received in ASP UP message in stead of its own ASP Identifier value.
>=20
>    If No then what is the role of ASP identifier in case of IPSP mode?
>=20
>    Br,
>    Padmalochan

--=20
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
=0A=0A=0A      
--0-1598044556-1236060137=:45954
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><DIV>Hi ,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Should the ASP identifier comming in received ASP UP message&nbsp;same=
 as the ASP identifire value in ASP UP ACK&nbsp;?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Br,</DIV>
<DIV>Padmalochan</DIV>
<DIV><BR><BR>--- On <B>Mon, 3/2/09, Brian F. G. Bidulock <I>&lt;bidulock@op=
enss7.org&gt;</I></B> wrote:<BR></DIV>
<BLOCKQUOTE style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(=
16,16,255) 2px solid">From: Brian F. G. Bidulock &lt;bidulock@openss7.org&g=
t;<BR>Subject: Re: query regarding ASP Identifier in ASP UP ACK .<BR>To: mo=
harana_p@yahoo.com<BR>Cc: "sigtran" &lt;sigtran@ietf.org&gt;<BR>Date: Monda=
y, March 2, 2009, 8:02 AM<BR><BR><PRE>moharana_p,

I have no idea what special use there is for IPSP.

Because the sender of the ASP UP forms the SCTP association,
it should know the identity of the ASP to which it is sending it.
It is the receiver of the ASP UP, that accepted the SCTP
association, that may not be able to derived from a dynamically
allocated port number on the connecting peer, the ASP Id of
the sender of the ASP UP.


--brian


moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009 04:17:17)
&gt;=20
&gt;    Hello,
&gt;=20
&gt;    As per the rfc-4666.
&gt;=20
&gt;    3.5.2.  ASP Up Acknowledgement (ASP Up Ack)
&gt;    ......
&gt;       The optional ASP Identifier parameter is specifically useful for
&gt;    IPSP
&gt;       communication.  In that case, the IPSP answering the ASP Up mess=
age
&gt;       MAY include its own ASP Identifier value.
&gt;=20
&gt;    Since ASP Identifier is used to identify the ASP with in an AS so i=
n
&gt;    ASP UP ACK message ASP Identifier value should be the value that
&gt;    received in ASP UP message in stead of its own ASP Identifier value=
.
&gt;=20
&gt;    If No then what is the role of ASP identifier in case of IPSP mode?
&gt;=20
&gt;    Br,
&gt;    Padmalochan

--=20
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
</PRE></BLOCKQUOTE></td></tr></table><br>=0A=0A      
--0-1598044556-1236060137=:45954--


Return-Path: <bidulock@openss7.org>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFAB428C16D for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 23:17:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level: 
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCl9fNrGmqvM for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 23:17:33 -0800 (PST)
Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 0A5653A69D7 for <sigtran@ietf.org>; Mon,  2 Mar 2009 23:17:32 -0800 (PST)
Received: from wilbur.pigworks.openss7.net (IDENT:lltxb0ipOykbC+OJXpu502gCi1UhHAmA@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id n237Hwgx028208; Tue, 3 Mar 2009 00:17:58 -0700
Received: from wilbur.pigworks.openss7.net (IDENT:tEYjs45jVzZANKsBCvrBBP+MStmoTyWK@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id n237HwWG032304; Tue, 3 Mar 2009 00:17:58 -0700
Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id n237Hw3e032303; Tue, 3 Mar 2009 00:17:58 -0700
Date: Tue, 3 Mar 2009 00:17:57 -0700
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: moharana_p@yahoo.com
Message-ID: <20090303071757.GA31701@openss7.org>
Mail-Followup-To: moharana_p@yahoo.com, sigtran <sigtran@ietf.org>
References: <20090302140214.GD16129@openss7.org> <116045.45954.qm@web110511.mail.gq1.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <116045.45954.qm@web110511.mail.gq1.yahoo.com>
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-To: <blockme@openss7.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: sigtran <sigtran@ietf.org>
Subject: Re: [Sigtran] query regarding ASP Identifier in ASP UP ACK .
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2009 07:17:33 -0000

moharana_p,

moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009 22:02:17)
> 
>    Should the ASP identifier comming in received ASP UP message same as
>    the ASP identifire value in ASP UP ACK ?
> 

For ASP operation it is the same.  For IPSP, "the IPSP answering
the ASP Up message MAY include its own ASP Identifier value."

--brian

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/


Return-Path: <bidulock@openss7.org>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B7AB3A6A7E for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 23:24:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.244
X-Spam-Level: 
X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBvAnsx9w+-k for <sigtran@core3.amsl.com>; Mon,  2 Mar 2009 23:24:10 -0800 (PST)
Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 7E7723A69CC for <sigtran@ietf.org>; Mon,  2 Mar 2009 23:22:49 -0800 (PST)
Received: from wilbur.pigworks.openss7.net (IDENT:TT3pMksUYGEKrE+L9a1NYNixog7eF1Us@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id n237NFmx028309; Tue, 3 Mar 2009 00:23:15 -0700
Received: from wilbur.pigworks.openss7.net (IDENT:1THNgauhLvZyjYwVJGdpezw8GbNd0BfB@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id n237NF6c032612; Tue, 3 Mar 2009 00:23:15 -0700
Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id n237NF9o032611; Tue, 3 Mar 2009 00:23:15 -0700
Date: Tue, 3 Mar 2009 00:23:15 -0700
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: moharana_p@yahoo.com
Message-ID: <20090303072315.GB31701@openss7.org>
Mail-Followup-To: moharana_p@yahoo.com, sigtran <sigtran@ietf.org>
References: <20090302135649.GC16129@openss7.org> <735541.42480.qm@web110512.mail.gq1.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <735541.42480.qm@web110512.mail.gq1.yahoo.com>
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-To: <blockme@openss7.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: sigtran <sigtran@ietf.org>
Subject: Re: [Sigtran] SCCP connection refusal
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2009 07:24:11 -0000

moharana_p,

Sorry, I read your note as SCTP not SCCP.

SCCP refusal cause "end user originated" is when the called
SCCP User (in this case I presume BSSAP or RANAP) refuses
the connection.

--brian

moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009 20:42:13)
> 
>    Brian,
>    The SCTP association still UP. We did not notice any ABORT. If there
>    was an ABORT, SCCP connection request would n't have gone till peer
>    node SCCP layer which is above M3UA.
>    Thanks
>    --- On Mon, 3/2/09, Brian F. G. Bidulock <bidulock@openss7.org> wrote:
> 
>      From: Brian F. G. Bidulock <bidulock@openss7.org>
>      Subject: Re: SCCP connection refusal
>      To: moharana_p@yahoo.com
>      Cc: "sigtran" <sigtran@ietf.org>
>      Date: Monday, March 2, 2009, 7:56 AM
> moharana_p,
> 
> As it implies: when the peer user requests an abort.
> 
> --brian
> 
> moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009 05:47:32)
> >
> >    Hi,
> >    In what scenario the peer node SCCP reject SCCP Connection with cause
> >    "end user originated" ? I had glance in SCCP spec for the
> scenario
> >    when this can happen but I could not find scenario. Please clarify my
> >    query. "
> >    Thanks.
> 
> --
> Brian F. G. Bidulock
> bidulock@openss7.org
> http://www.openss7.org/

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/


Return-Path: <moharana_p@yahoo.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707CF28C1BB for <sigtran@core3.amsl.com>; Tue,  3 Mar 2009 01:37:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.737
X-Spam-Level: 
X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[AWL=0.527,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trJN9MZgs1XD for <sigtran@core3.amsl.com>; Tue,  3 Mar 2009 01:37:16 -0800 (PST)
Received: from web110504.mail.gq1.yahoo.com (web110504.mail.gq1.yahoo.com [67.195.8.252]) by core3.amsl.com (Postfix) with SMTP id 98A8328C211 for <sigtran@ietf.org>; Tue,  3 Mar 2009 01:37:16 -0800 (PST)
Received: (qmail 42031 invoked by uid 60001); 3 Mar 2009 09:37:43 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236073063; bh=tatdePfm2mlhlLc/6upd5DS0kavy8Qw4A76M26fwQcQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GGhCgLkgmYQvYyHTQhiElNlE3oqc4TR5xjgLO9XAbNGx9+Y/W/8vQF986qFV2Z90D9piPA2xJGCFcG/RpCCZX9/fxybVFTyb9OpCKb528MLkQ44flVQ2JJgD3wbaFZL1u46UwKiONGPMA3+DDQtnV6SMZyi/7QgeL+GqwduoZkU=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=sV+ZLLFzWiTQh/cQOzxHZrmoTTYPYKWD/dBpod4m7Pn2bzCihLkunIdeL+sPXEm93Z+FkNilWcAZfeAaKAdqP6htoz+6SjDboS5gQHcRs/cvBVR6zpsZKe9a9e589cR6OgLLaIvP15tYGeFE7xk+GqaMW8bfVzfh3CAsKJt62SU=;
Message-ID: <446684.40710.qm@web110504.mail.gq1.yahoo.com>
X-YMail-OSG: mpLfIeUVM1kxlVqRPQwxFqtehwm.kYMNiu7R6dmXG2pL3OrsO1.TMLquiNFsqAEE7VKmsoULBsRKxXaJ8LBojGBhcD_xp.M0.HpK5sc34Nt6Wl7YukauXE24RlyGqjb18cjcZljMymWuVmE6nF9l4K5lKycSfJeRKqJWzMbgRXvKhV0mwK3surwp5m_eqLoUGQAbAWeA1rHdvQ--
Received: from [220.227.132.178] by web110504.mail.gq1.yahoo.com via HTTP; Tue, 03 Mar 2009 01:37:43 PST
X-Mailer: YahooMailWebService/0.7.289.1
Date: Tue, 3 Mar 2009 01:37:43 -0800 (PST)
From: moharana_p@yahoo.com
To: bidulock@openss7.org
In-Reply-To: <20090303071757.GA31701@openss7.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-96624735-1236073063=:40710"
Cc: sigtran <sigtran@ietf.org>
Subject: Re: [Sigtran] query regarding ASP Identifier in ASP UP ACK .
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: moharana_p@yahoo.com
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2009 09:37:17 -0000

--0-96624735-1236073063=:40710
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,
=A0
What is the ASP identifier value in Notify messsage for IPSP end point?=20
Should IPSP end point sending the NOTIFY message includes its own ASP Ident=
ifier or the value receive in the ASP UP message?
=A0
Br,
Padmalochan

--- On Tue, 3/3/09, Brian F. G. Bidulock <bidulock@openss7.org> wrote:

From: Brian F. G. Bidulock <bidulock@openss7.org>
Subject: Re: query regarding ASP Identifier in ASP UP ACK .
To: moharana_p@yahoo.com
Cc: "sigtran" <sigtran@ietf.org>
Date: Tuesday, March 3, 2009, 1:17 AM

moharana_p,

moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009 22:02:17)
>=20
>    Should the ASP identifier comming in received ASP UP message same as
>    the ASP identifire value in ASP UP ACK ?
>=20

For ASP operation it is the same.  For IPSP, "the IPSP answering
the ASP Up message MAY include its own ASP Identifier value."

--brian

--=20
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
=0A=0A=0A      
--0-96624735-1236073063=:40710
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>What is the ASP identifier value in Notify messsage for IPSP end point=
? </DIV>
<DIV>Should IPSP end point sending the NOTIFY message includes its own ASP =
Identifier or the value receive in the ASP UP message?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Br,</DIV>
<DIV>Padmalochan<BR><BR>--- On <B>Tue, 3/3/09, Brian F. G. Bidulock <I>&lt;=
bidulock@openss7.org&gt;</I></B> wrote:<BR></DIV>
<BLOCKQUOTE style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(=
16,16,255) 2px solid">From: Brian F. G. Bidulock &lt;bidulock@openss7.org&g=
t;<BR>Subject: Re: query regarding ASP Identifier in ASP UP ACK .<BR>To: mo=
harana_p@yahoo.com<BR>Cc: "sigtran" &lt;sigtran@ietf.org&gt;<BR>Date: Tuesd=
ay, March 3, 2009, 1:17 AM<BR><BR><PRE>moharana_p,

moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009 22:02:17)
&gt;=20
&gt;    Should the ASP identifier comming in received ASP UP message same a=
s
&gt;    the ASP identifire value in ASP UP ACK ?
&gt;=20

For ASP operation it is the same.  For IPSP, "the IPSP answering
the ASP Up message MAY include its own ASP Identifier value."

--brian

--=20
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
</PRE></BLOCKQUOTE></td></tr></table><br>=0A=0A      
--0-96624735-1236073063=:40710--


Return-Path: <David.Laight@ACULAB.COM>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 281773A6908 for <sigtran@core3.amsl.com>; Tue,  3 Mar 2009 01:44:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.659
X-Spam-Level: 
X-Spam-Status: No, score=-0.659 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-F-2J-1sExU for <sigtran@core3.amsl.com>; Tue,  3 Mar 2009 01:44:19 -0800 (PST)
Received: from mx0.aculab.com (mx0.aculab.com [213.249.233.131]) by core3.amsl.com (Postfix) with SMTP id E0E0B3A67E7 for <sigtran@ietf.org>; Tue,  3 Mar 2009 01:44:18 -0800 (PST)
Received: (qmail 32221 invoked from network); 3 Mar 2009 09:44:45 -0000
Received: from localhost (127.0.0.1) by mx0.aculab.com with SMTP; 3 Mar 2009 09:44:45 -0000
Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 17920-07 for <sigtran@ietf.org>; Tue,  3 Mar 2009 09:44:43 +0000 (GMT)
Received: (qmail 32214 invoked by uid 599); 3 Mar 2009 09:44:43 -0000
Received: from unknown (HELO saturn2.Aculab.com) (10.202.163.6) by mx0.aculab.com (qpsmtpd/0.28) with ESMTP; Tue, 03 Mar 2009 09:44:43 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Mar 2009 09:42:40 -0000
Message-ID: <00D42150952F70458C66072322F7FE25026E7E7D@saturn2.aculab.com>
In-Reply-To: <446684.40710.qm@web110504.mail.gq1.yahoo.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sigtran] query regarding ASP Identifier in ASP UP ACK .
thread-index: Acmb43Ap6gRPGhp0TCeUVIlYH74xiQAAGshw
From: "David Laight" <David.Laight@ACULAB.COM>
To: "sigtran" <sigtran@ietf.org>
X-ST-MF-Message-Resent: 3/3/2009 09:42
X-Virus-Scanned: by iCritical at mx0.aculab.com
Subject: Re: [Sigtran] query regarding ASP Identifier in ASP UP ACK .
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2009 09:44:20 -0000

 
> What is the ASP identifier value in Notify messsage
> for IPSP end point? 

RTFM !

In particular look what the purpose of the value is.

I'm sure it has been said here before that IPSP DE is
very badly thought out.  IPSP SE is much more like a
normal client-server link.

	David


Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1=
 1PT, UK
Registration No: 1397386 (Wales)  
P Please consider the environment and don't print this e-mail unless you =
really need to


Return-Path: <bidulock@openss7.org>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92B083A6AFF for <sigtran@core3.amsl.com>; Tue,  3 Mar 2009 02:43:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcN76NGoY0JQ for <sigtran@core3.amsl.com>; Tue,  3 Mar 2009 02:43:55 -0800 (PST)
Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id AE40A3A6A88 for <sigtran@ietf.org>; Tue,  3 Mar 2009 02:43:55 -0800 (PST)
Received: from wilbur.pigworks.openss7.net (IDENT:dr8uyGihMlWplrC/nCJ/S555dAjp1bqa@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id n23AiHJP031708; Tue, 3 Mar 2009 03:44:17 -0700
Received: from wilbur.pigworks.openss7.net (IDENT:ESpf5YyRNsVZ8uZcRt2Fws/NRL6lsIIK@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id n23AiGiI009233; Tue, 3 Mar 2009 03:44:16 -0700
Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id n23AiGSb009232; Tue, 3 Mar 2009 03:44:16 -0700
Date: Tue, 3 Mar 2009 03:44:16 -0700
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: moharana_p@yahoo.com
Message-ID: <20090303104416.GA8816@openss7.org>
Mail-Followup-To: moharana_p@yahoo.com, sigtran <sigtran@ietf.org>
References: <20090303071757.GA31701@openss7.org> <446684.40710.qm@web110504.mail.gq1.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <446684.40710.qm@web110504.mail.gq1.yahoo.com>
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-To: <blockme@openss7.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: sigtran <sigtran@ietf.org>
Subject: Re: [Sigtran] query regarding ASP Identifier in ASP UP ACK .
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2009 10:43:56 -0000

moharana_p,

I agree with David to an extent.

See RFC 4666/3.8.2:

      If the Status Type is Other, then the following Status Information
      values are defined:

         1    Insufficient ASP Resources Active in AS
         2    Alternate ASP Active
         3    ASP Failure

      These notifications are not based on the SGP reporting the state
      change of an ASP or AS.  In the Insufficient ASP Resources case,
      the SGP is indicating to an ASP_INACTIVE ASP in the AS that
      another ASP is required to handle the load of the AS (Loadsharing
      or Broadcast mode).  For the Alternate ASP Active case, an ASP is
      informed when an alternate ASP transitions to the ASP-ACTIVE state
      in Override mode.  The ASP Identifier (if available) of the
      Alternate ASP MUST be placed in the message.  For the ASP Failure
      case, the SGP is indicating to ASPs in the AS that one of the
      ASPs has failed.  The ASP Identifier (if available) of the failed
      ASP MUST be placed in the message.

I think that is quite clear.  The ASP Id used is that of the failed
or alternate ASP (not the sending ASP).

--brian

moharana_p@yahoo.com wrote:              (Tue, 03 Mar 2009 01:37:43)
> 
>    Hi,
> 
>    What is the ASP identifier value in Notify messsage for IPSP end
>    point?
>    Should IPSP end point sending the NOTIFY message includes its own ASP
>    Identifier or the value receive in the ASP UP message?
> 

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/


Return-Path: <moharana_p@yahoo.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C74D528C263 for <sigtran@core3.amsl.com>; Tue,  3 Mar 2009 04:47:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.495
X-Spam-Level: 
X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=0.169,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGfMMLHz4aWS for <sigtran@core3.amsl.com>; Tue,  3 Mar 2009 04:47:01 -0800 (PST)
Received: from web110507.mail.gq1.yahoo.com (web110507.mail.gq1.yahoo.com [67.195.8.112]) by core3.amsl.com (Postfix) with SMTP id 246693A6C3F for <sigtran@ietf.org>; Tue,  3 Mar 2009 04:47:01 -0800 (PST)
Received: (qmail 12700 invoked by uid 60001); 3 Mar 2009 12:47:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236084448; bh=rA6K/i1FY0rQptwtQK71KZhULwoX6mys84HCNPX+Z+g=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=cgQkKtXiajBiRqAEBGBsjEc3vOgKFTj6UfhNdWfvCnY8USpfgQKCiOT1cVo9osvAckZda/AxEa8D9+mvjri4VOKKzzDS3YHQ9a3V1XzxfEoy5PKynLNz8oWJPjqE60nIHtZQhTTFExiS2ofJuapJLv9DMkYnQZ888lJ6QEcUF5w=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=N1xxT+R3ESlO/A5JH6irsrUpnkHKLU5BjXOj2e7P/3J4ACsOi6ZcmFFhRQ1FQaou28Nv77otJRqGHSlq+nAMclzt4VZojK8ll/DV/ifTIrxIY6AhMQ9+bT2iKQ4keJtoAN3yKNzLtjASSjE9ROKVyNaw3+/fYCaDLElBw6tDkX0=;
Message-ID: <191783.12427.qm@web110507.mail.gq1.yahoo.com>
X-YMail-OSG: Mw6qvE0VM1kEF2M.FVvCTE8pRRDwiR.4skhtY91Mmat8.HVJl1R8I1nStIjXH32Ym5zom0ggq2GYLLiDff5KGahQCC0bar2BBqBdX3rWI3tqrfxDfG_..pneajRipufkTfAmm42gVuHlSL0Hz0j4MeiKXOv4K3r80Id1GdeDh6Qj5Q--
Received: from [220.227.132.178] by web110507.mail.gq1.yahoo.com via HTTP; Tue, 03 Mar 2009 04:47:28 PST
X-Mailer: YahooMailWebService/0.7.289.1
Date: Tue, 3 Mar 2009 04:47:28 -0800 (PST)
From: moharana_p@yahoo.com
To: sigtran <sigtran@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-661965170-1236084448=:12427"
Cc: bidulock <bidulock@openss7.org>, kmorneau@cisco.com
Subject: [Sigtran] Query regarding re-registration procedure in m3ua.
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: moharana_p@yahoo.com
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2009 12:47:01 -0000

--0-661965170-1236084448=:12427
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


Hi All,
=A0
I have some doubt regarding the RC parameter value in the REG REQ message.=
=20
=A0

As per the RFC4666 the=A0RC is an optional parameter in the REG REQ message=
. Should REG=A0REQ message contain RC parameter=A0during registering=A0a RK=
=A0first time or=A0RC parameter is only needed during re registration proce=
dure?=A0
In which scenario re registration of RK is required?
=A0
Br,
Padmalochan=A0=A0=0A=0A=0A      
--0-661965170-1236084448=:12427
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><DIV id=3Dyiv1155806126>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN style=3D"FONT-SIZE=
: 10pt; FONT-FAMILY: Arial">Hi All,</SPAN></DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN style=3D"FONT-SIZE=
: 10pt; FONT-FAMILY: Arial"></SPAN>&nbsp;</DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN style=3D"FONT-SIZE=
: 10pt; FONT-FAMILY: Arial">I have some doubt regarding the RC parameter va=
lue in the REG REQ message. <?xml:namespace prefix =3D o ns =3D "urn:schema=
s-microsoft-com:office:office" /><o:p></o:p></SPAN></DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN style=3D"FONT-SIZE=
: 10pt; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></DIV>
<OL style=3D"MARGIN-TOP: 0in" type=3D1>
<LI class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo=
1; tab-stops: list .5in"><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial=
">As per the RFC4666 the&nbsp;RC is an optional parameter in the REG REQ me=
ssage. Should REG&nbsp;REQ message contain RC parameter&nbsp;during registe=
ring&nbsp;a RK&nbsp;first time or&nbsp;RC parameter is only needed during r=
e registration procedure?&nbsp;<o:p></o:p></SPAN></LI>
<LI class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo=
1; tab-stops: list .5in"><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial=
">In which scenario re registration of RK is required?<o:p></o:p></SPAN></L=
I></OL>
<DIV>&nbsp;</DIV>
<DIV>Br,</DIV>
<DIV>Padmalochan&nbsp;&nbsp;</DIV></DIV></td></tr></table><br>=0A=0A      
--0-661965170-1236084448=:12427--


Return-Path: <bidulock@openss7.org>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 317DA3A696E for <sigtran@core3.amsl.com>; Tue,  3 Mar 2009 06:21:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.23
X-Spam-Level: 
X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=-0.231,  BAYES_00=-2.599, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bbiu9OPX5fm4 for <sigtran@core3.amsl.com>; Tue,  3 Mar 2009 06:21:02 -0800 (PST)
Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 30A873A6948 for <sigtran@ietf.org>; Tue,  3 Mar 2009 06:21:02 -0800 (PST)
Received: from wilbur.pigworks.openss7.net (IDENT:xba4Opkh79XifDtGMaDqewBGpswVPtN8@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id n23EL1Vj002882; Tue, 3 Mar 2009 07:21:01 -0700
Received: from wilbur.pigworks.openss7.net (IDENT:TG3nrfiFsxcViTmcXKxiqplko5/2y5vC@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id n23EL1YF020017; Tue, 3 Mar 2009 07:21:01 -0700
Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id n23EL1w7020016; Tue, 3 Mar 2009 07:21:01 -0700
Date: Tue, 3 Mar 2009 07:21:01 -0700
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: moharana_p@yahoo.com
Message-ID: <20090303142101.GA19839@openss7.org>
Mail-Followup-To: moharana_p@yahoo.com, sigtran <sigtran@ietf.org>, kmorneau@cisco.com
References: <191783.12427.qm@web110507.mail.gq1.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <191783.12427.qm@web110507.mail.gq1.yahoo.com>
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-To: <blockme@openss7.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: kmorneau@cisco.com, sigtran <sigtran@ietf.org>
Subject: Re: [Sigtran] Query regarding re-registration procedure in m3ua.
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2009 14:21:03 -0000

moharana_p,

It would be better if you read the specification.

See RFC 4666/4.4.1 Registration:

   ...

   An ASP MAY request modification of an existing Routing Key by
   including a Routing Context parameter in a Registration Request
   message.  Upon receipt of a Registration Request message containing a
   Routing Context, if the SGP determines that the Routing Context
   applies to an existing Routing Key, the SGP MAY adjust the existing
   Routing Key to match the new information provided in the Routing Key
   parameter.  A Registration Response "ERR Routing Key Change Refused"
   is returned if the SGP does not support this re-registration
   procedure or RC does not exist.  Otherwise, a Registration Response
   "Successfully Registered" is returned.

   ...

--brian

moharana_p@yahoo.com wrote:              (Tue, 03 Mar 2009 04:47:28)
> 
>    Hi All,
> 
> 
>    I have some doubt regarding the RC parameter value in the REG REQ
>    message.
> 
> 
>     1. As per the RFC4666 the RC is an optional parameter in the REG REQ
>        message. Should REG REQ message contain RC parameter during
>        registering a RK first time or RC parameter is only needed during
>        re registration procedure?
>     2. In which scenario re registration of RK is required?
> 
> 
>    Br,
>    Padmalochan

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/

From moharana_p@yahoo.com  Wed Mar  4 23:25:08 2009
Return-Path: <moharana_p@yahoo.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98BBE3A6B33 for <sigtran@core3.amsl.com>; Wed,  4 Mar 2009 23:25:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.512
X-Spam-Level: 
X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[AWL=0.152,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzIUipuAxUT6 for <sigtran@core3.amsl.com>; Wed,  4 Mar 2009 23:25:07 -0800 (PST)
Received: from web110516.mail.gq1.yahoo.com (web110516.mail.gq1.yahoo.com [67.195.8.121]) by core3.amsl.com (Postfix) with SMTP id 8D7B73A68DE for <sigtran@ietf.org>; Wed,  4 Mar 2009 23:25:06 -0800 (PST)
Received: (qmail 80223 invoked by uid 60001); 5 Mar 2009 07:25:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236237935; bh=TLuFCW7Hy6r5rVWdnGraY7RmYeOqMA9BoLnUi0YByZo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=riGBuT7cWNbXrXIhxi+a8xIzocWU5Sim3BU6RTsxfJZ7K9kaL+DQF410VuARvwo032Tysfky9TE4fl5XDIKXBNKdCmo9Vvw1JE4shL84+I4n2kRSDuK6mzTUGpDUN1paUCVf6RmN5Gr3Mvp9KjjEM3c4yWigUzgIqTX8fgdrhhs=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=QVBhp9ur6wcO2qS5MuFB/JUWZ/RwMbsK7TRvY8j3ayP+mU9LxqEY4g5TxAjDDxLPZzS/hceGPoXnenqJ806FO2gf8+qKXyqKB15OxTHC9kSkataYYyHeTWwKhsVO0ZmkriqZfaimsYSUo4q5MtRSI6sO/RGIPToT8eftvCxFZgk=;
Message-ID: <429697.79489.qm@web110516.mail.gq1.yahoo.com>
X-YMail-OSG: gZTeR1MVM1liLFGsfZBBliN8b1Fd4E2pemVhUe2.p3Ccnr0gZ036GKzGa_RXXLZlYg3dsFngf18KejoKyV3TjnGTA0KcnhZVuYqtOddVOsHM7wTduWMHAtur1gWEfZ.wQUQoGAoIDb7DoTRWbwos4iAfzScLqdcza_pdm3EnU.tj0UkKwW6M4qElThWYKzh73wqhglF1UUy5B41KIY2A1Y8Rcgp0qKu3nMVgnPykuzTviFL8ssfZ0mGq0JIQ_LqlVQsWL9vC.hN_IQwC
Received: from [220.227.132.178] by web110516.mail.gq1.yahoo.com via HTTP; Wed, 04 Mar 2009 23:25:35 PST
X-Mailer: YahooMailClassic/5.1.18 YahooMailWebService/0.7.289.1
Date: Wed, 4 Mar 2009 23:25:35 -0800 (PST)
From: moharana_p@yahoo.com
To: bidulock@openss7.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1208907606-1236237935=:79489"
Cc: kmorneau@cisco.com, sigtran <sigtran@ietf.org>
Subject: Re: [Sigtran] Query regarding re-registration procedure in m3ua.
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2009 07:25:08 -0000

--0-1208907606-1236237935=:79489
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,
=A0
If SGP receive a REG REQ message with a RC and a un-register RK in ASP INAC=
TIVE state should SGP responce any error message or register the RK if poss=
ible?
=A0
Br,
Padmalochan

--- On Tue, 3/3/09, Brian F. G. Bidulock <bidulock@openss7.org> wrote:


From: Brian F. G. Bidulock <bidulock@openss7.org>
Subject: Re: Query regarding re-registration procedure in m3ua.
To: moharana_p@yahoo.com
Cc: "sigtran" <sigtran@ietf.org>, kmorneau@cisco.com
Date: Tuesday, March 3, 2009, 8:21 AM


-----Inline Attachment Follows-----


moharana_p,

It would be better if you read the specification.

See RFC 4666/4.4.1 Registration:

=A0=A0=A0...

=A0=A0=A0An ASP MAY request modification of an existing Routing Key by
=A0=A0=A0including a Routing Context parameter in a Registration Request
=A0=A0=A0message.=A0 Upon receipt of a Registration Request message contain=
ing a
=A0=A0=A0Routing Context, if the SGP determines that the Routing Context
=A0=A0=A0applies to an existing Routing Key, the SGP MAY adjust the existin=
g
=A0=A0=A0Routing Key to match the new information provided in the Routing K=
ey
=A0=A0=A0parameter.=A0 A Registration Response "ERR Routing Key Change Refu=
sed"
=A0=A0=A0is returned if the SGP does not support this re-registration
=A0=A0=A0procedure or RC does not exist.=A0 Otherwise, a Registration Respo=
nse
=A0=A0=A0"Successfully Registered" is returned.

=A0=A0=A0...

--brian

moharana_p@yahoo.com wrote:=A0 =A0 =A0 =A0 =A0 =A0 =A0 (Tue, 03 Mar 2009 04=
:47:28)
>=20
>=A0 =A0 Hi All,
>=20
>=20
>=A0 =A0 I have some doubt regarding the RC parameter value in the REG REQ
>=A0 =A0 message.
>=20
>=20
>=A0 =A0=A0=A01. As per the RFC4666 the RC is an optional parameter in the =
REG REQ
>=A0 =A0 =A0 =A0 message. Should REG REQ message contain RC parameter durin=
g
>=A0 =A0 =A0 =A0 registering a RK first time or RC parameter is only needed=
 during
>=A0 =A0 =A0 =A0 re registration procedure?
>=A0 =A0=A0=A02. In which scenario re registration of RK is required?
>=20
>=20
>=A0 =A0 Br,
>=A0 =A0 Padmalochan

--=20
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
=0A=0A=0A      
--0-1208907606-1236237935=:79489
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>If SGP receive a REG REQ message with a RC and a un-register RK in ASP=
 INACTIVE state should SGP responce any error message or register the RK if=
 possible?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Br,</DIV>
<DIV>Padmalochan<BR><BR>--- On <B>Tue, 3/3/09, Brian F. G. Bidulock <I>&lt;=
bidulock@openss7.org&gt;</I></B> wrote:<BR></DIV>
<BLOCKQUOTE style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(=
16,16,255) 2px solid"><BR>From: Brian F. G. Bidulock &lt;bidulock@openss7.o=
rg&gt;<BR>Subject: Re: Query regarding re-registration procedure in m3ua.<B=
R>To: moharana_p@yahoo.com<BR>Cc: "sigtran" &lt;sigtran@ietf.org&gt;, kmorn=
eau@cisco.com<BR>Date: Tuesday, March 3, 2009, 8:21 AM<BR><BR><BR>-----Inli=
ne Attachment Follows-----<BR><BR>
<DIV class=3DplainMail>moharana_p,<BR><BR>It would be better if you read th=
e specification.<BR><BR>See RFC 4666/4.4.1 Registration:<BR><BR>&nbsp;&nbsp=
;&nbsp;...<BR><BR>&nbsp;&nbsp;&nbsp;An ASP MAY request modification of an e=
xisting Routing Key by<BR>&nbsp;&nbsp;&nbsp;including a Routing Context par=
ameter in a Registration Request<BR>&nbsp;&nbsp;&nbsp;message.&nbsp; Upon r=
eceipt of a Registration Request message containing a<BR>&nbsp;&nbsp;&nbsp;=
Routing Context, if the SGP determines that the Routing Context<BR>&nbsp;&n=
bsp;&nbsp;applies to an existing Routing Key, the SGP MAY adjust the existi=
ng<BR>&nbsp;&nbsp;&nbsp;Routing Key to match the new information provided i=
n the Routing Key<BR>&nbsp;&nbsp;&nbsp;parameter.&nbsp; A Registration Resp=
onse "ERR Routing Key Change Refused"<BR>&nbsp;&nbsp;&nbsp;is returned if t=
he SGP does not support this re-registration<BR>&nbsp;&nbsp;&nbsp;procedure=
 or RC does not exist.&nbsp; Otherwise, a Registration
 Response<BR>&nbsp;&nbsp;&nbsp;"Successfully Registered" is returned.<BR><B=
R>&nbsp;&nbsp;&nbsp;...<BR><BR>--brian<BR><BR><A href=3D"http://us.mc1105.m=
ail.yahoo.com/mc/compose?to=3Dmoharana_p@yahoo.com" ymailto=3D"mailto:mohar=
ana_p@yahoo.com">moharana_p@yahoo.com</A> wrote:&nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; (Tue, 03 Mar 2009 04:47:28)<BR>&gt; <BR>&gt;&nbsp; &n=
bsp; Hi All,<BR>&gt; <BR>&gt; <BR>&gt;&nbsp; &nbsp; I have some doubt regar=
ding the RC parameter value in the REG REQ<BR>&gt;&nbsp; &nbsp; message.<BR=
>&gt; <BR>&gt; <BR>&gt;&nbsp; &nbsp;&nbsp;&nbsp;1. As per the RFC4666 the R=
C is an optional parameter in the REG REQ<BR>&gt;&nbsp; &nbsp; &nbsp; &nbsp=
; message. Should REG REQ message contain RC parameter during<BR>&gt;&nbsp;=
 &nbsp; &nbsp; &nbsp; registering a RK first time or RC parameter is only n=
eeded during<BR>&gt;&nbsp; &nbsp; &nbsp; &nbsp; re registration procedure?<=
BR>&gt;&nbsp; &nbsp;&nbsp;&nbsp;2. In which scenario re registration of RK
 is required?<BR>&gt; <BR>&gt; <BR>&gt;&nbsp; &nbsp; Br,<BR>&gt;&nbsp; &nbs=
p; Padmalochan<BR><BR>-- <BR>Brian F. G. Bidulock<BR><A href=3D"http://us.m=
c1105.mail.yahoo.com/mc/compose?to=3Dbidulock@openss7.org" ymailto=3D"mailt=
o:bidulock@openss7.org">bidulock@openss7.org</A><BR><A href=3D"http://www.o=
penss7.org/" target=3D_blank>http://www.openss7.org/</A><BR></DIV></BLOCKQU=
OTE></td></tr></table><br>=0A=0A      
--0-1208907606-1236237935=:79489--

From moharana_p@yahoo.com  Thu Mar  5 00:58:07 2009
Return-Path: <moharana_p@yahoo.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3B128C17E for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 00:58:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.526
X-Spam-Level: 
X-Spam-Status: No, score=-1.526 tagged_above=-999 required=5 tests=[AWL=0.138,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZI+5fPBaw-t4 for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 00:58:06 -0800 (PST)
Received: from web110514.mail.gq1.yahoo.com (web110514.mail.gq1.yahoo.com [67.195.8.119]) by core3.amsl.com (Postfix) with SMTP id 4EFFB3A67DB for <sigtran@ietf.org>; Thu,  5 Mar 2009 00:58:06 -0800 (PST)
Received: (qmail 37704 invoked by uid 60001); 5 Mar 2009 08:58:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236243515; bh=J8/uh3TyENYmGqymMayhBOwHdYQ/HIg0R62yEt6aFJs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=usesEW/TKCGpEbgv8uA1y3zg8GtQcHD6s1Isofzf0LdEbPOdoJTEsfBlj+LolijvhpeA8sHNQ16RBA0pIEh/k3NUUVwKJGAzY2uTQqe3FnOpvCX8PUNWnyzuflkzum0f3b+0a8Ri29VcKC2LJt4X3MNs3ibKXxOeIanansiG9hk=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=wlib+xYFLp77HlsUv9SGwIn2Oq3QobKFyhjOYuQAaLOQNAYrm4ujMhXB2u09xkJ1JaXRC4X7NAiC+QXUK0VJivkHfUUzxzYWq3oG27BqjzfXuQ8N7VV0s7jCUj+v6+LxCMuC5a5+zZvfdsFWpO0oG5llhbEABVfdPHqGIb/4NCA=;
Message-ID: <380740.34184.qm@web110514.mail.gq1.yahoo.com>
X-YMail-OSG: La8v.FkVM1krq6dcFe1cUMgf5hjR1WwsBObyTU9aNrvmnF3_4mBNgVZjT0QvNeggjugyZDDNRbk_S4UQG6HhTXan2f2CZM7JTDHLjeI3CHFlt8TR8p7nPcCelLzKNq13iZIDgGenqPSiavt.S4eUDJESfERg1EXUtza2tC_fzPO0nPAESA9.pBi3xcRsQ8cgr2uN4gLZsjv1YQ--
Received: from [220.227.132.178] by web110514.mail.gq1.yahoo.com via HTTP; Thu, 05 Mar 2009 00:58:35 PST
X-Mailer: YahooMailClassic/5.1.18 YahooMailWebService/0.7.289.1
Date: Thu, 5 Mar 2009 00:58:35 -0800 (PST)
From: moharana_p@yahoo.com
To: bidulock@openss7.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-671972463-1236243515=:34184"
Cc: kmorneau@cisco.com, sigtran <sigtran@ietf.org>
Subject: Re: [Sigtran] Query regarding re-registration procedure in m3ua.
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2009 08:58:07 -0000

--0-671972463-1236243515=:34184
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,
=A0
Is the below call flow right for re-registration procedure.
=A0
ASP=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 SG
--------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -----=
-----
=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=20

--- On Tue, 3/3/09, Brian F. G. Bidulock <bidulock@openss7.org> wrote:


From: Brian F. G. Bidulock <bidulock@openss7.org>
Subject: Re: Query regarding re-registration procedure in m3ua.
To: moharana_p@yahoo.com
Cc: "sigtran" <sigtran@ietf.org>, kmorneau@cisco.com
Date: Tuesday, March 3, 2009, 8:21 AM


-----Inline Attachment Follows-----


moharana_p,

It would be better if you read the specification.

See RFC 4666/4.4.1 Registration:

=A0=A0=A0...

=A0=A0=A0An ASP MAY request modification of an existing Routing Key by
=A0=A0=A0including a Routing Context parameter in a Registration Request
=A0=A0=A0message.=A0 Upon receipt of a Registration Request message contain=
ing a
=A0=A0=A0Routing Context, if the SGP determines that the Routing Context
=A0=A0=A0applies to an existing Routing Key, the SGP MAY adjust the existin=
g
=A0=A0=A0Routing Key to match the new information provided in the Routing K=
ey
=A0=A0=A0parameter.=A0 A Registration Response "ERR Routing Key Change Refu=
sed"
=A0=A0=A0is returned if the SGP does not support this re-registration
=A0=A0=A0procedure or RC does not exist.=A0 Otherwise, a Registration Respo=
nse
=A0=A0=A0"Successfully Registered" is returned.

=A0=A0=A0...

--brian

moharana_p@yahoo.com wrote:=A0 =A0 =A0 =A0 =A0 =A0 =A0 (Tue, 03 Mar 2009 04=
:47:28)
>=20
>=A0 =A0 Hi All,
>=20
>=20
>=A0 =A0 I have some doubt regarding the RC parameter value in the REG REQ
>=A0 =A0 message.
>=20
>=20
>=A0 =A0=A0=A01. As per the RFC4666 the RC is an optional parameter in the =
REG REQ
>=A0 =A0 =A0 =A0 message. Should REG REQ message contain RC parameter durin=
g
>=A0 =A0 =A0 =A0 registering a RK first time or RC parameter is only needed=
 during
>=A0 =A0 =A0 =A0 re registration procedure?
>=A0 =A0=A0=A02. In which scenario re registration of RK is required?
>=20
>=20
>=A0 =A0 Br,
>=A0 =A0 Padmalochan

--=20
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
=0A=0A=0A      
--0-671972463-1236243515=:34184
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Is the below call flow right for re-registration procedure.</DIV>
<DIV>&nbsp;</DIV>
<DIV>ASP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; SG</DIV>
<DIV>--------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ----------</DIV>
<DIV>&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; <BR><BR>--- On <B>Tue, 3/3/09, Brian F. G. Bidulo=
ck <I>&lt;bidulock@openss7.org&gt;</I></B> wrote:<BR></DIV>
<BLOCKQUOTE style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(=
16,16,255) 2px solid"><BR>From: Brian F. G. Bidulock &lt;bidulock@openss7.o=
rg&gt;<BR>Subject: Re: Query regarding re-registration procedure in m3ua.<B=
R>To: moharana_p@yahoo.com<BR>Cc: "sigtran" &lt;sigtran@ietf.org&gt;, kmorn=
eau@cisco.com<BR>Date: Tuesday, March 3, 2009, 8:21 AM<BR><BR><BR>-----Inli=
ne Attachment Follows-----<BR><BR>
<DIV class=3DplainMail>moharana_p,<BR><BR>It would be better if you read th=
e specification.<BR><BR>See RFC 4666/4.4.1 Registration:<BR><BR>&nbsp;&nbsp=
;&nbsp;...<BR><BR>&nbsp;&nbsp;&nbsp;An ASP MAY request modification of an e=
xisting Routing Key by<BR>&nbsp;&nbsp;&nbsp;including a Routing Context par=
ameter in a Registration Request<BR>&nbsp;&nbsp;&nbsp;message.&nbsp; Upon r=
eceipt of a Registration Request message containing a<BR>&nbsp;&nbsp;&nbsp;=
Routing Context, if the SGP determines that the Routing Context<BR>&nbsp;&n=
bsp;&nbsp;applies to an existing Routing Key, the SGP MAY adjust the existi=
ng<BR>&nbsp;&nbsp;&nbsp;Routing Key to match the new information provided i=
n the Routing Key<BR>&nbsp;&nbsp;&nbsp;parameter.&nbsp; A Registration Resp=
onse "ERR Routing Key Change Refused"<BR>&nbsp;&nbsp;&nbsp;is returned if t=
he SGP does not support this re-registration<BR>&nbsp;&nbsp;&nbsp;procedure=
 or RC does not exist.&nbsp; Otherwise, a Registration
 Response<BR>&nbsp;&nbsp;&nbsp;"Successfully Registered" is returned.<BR><B=
R>&nbsp;&nbsp;&nbsp;...<BR><BR>--brian<BR><BR><A href=3D"http://us.mc1105.m=
ail.yahoo.com/mc/compose?to=3Dmoharana_p@yahoo.com" ymailto=3D"mailto:mohar=
ana_p@yahoo.com">moharana_p@yahoo.com</A> wrote:&nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; (Tue, 03 Mar 2009 04:47:28)<BR>&gt; <BR>&gt;&nbsp; &n=
bsp; Hi All,<BR>&gt; <BR>&gt; <BR>&gt;&nbsp; &nbsp; I have some doubt regar=
ding the RC parameter value in the REG REQ<BR>&gt;&nbsp; &nbsp; message.<BR=
>&gt; <BR>&gt; <BR>&gt;&nbsp; &nbsp;&nbsp;&nbsp;1. As per the RFC4666 the R=
C is an optional parameter in the REG REQ<BR>&gt;&nbsp; &nbsp; &nbsp; &nbsp=
; message. Should REG REQ message contain RC parameter during<BR>&gt;&nbsp;=
 &nbsp; &nbsp; &nbsp; registering a RK first time or RC parameter is only n=
eeded during<BR>&gt;&nbsp; &nbsp; &nbsp; &nbsp; re registration procedure?<=
BR>&gt;&nbsp; &nbsp;&nbsp;&nbsp;2. In which scenario re registration of RK
 is required?<BR>&gt; <BR>&gt; <BR>&gt;&nbsp; &nbsp; Br,<BR>&gt;&nbsp; &nbs=
p; Padmalochan<BR><BR>-- <BR>Brian F. G. Bidulock<BR><A href=3D"http://us.m=
c1105.mail.yahoo.com/mc/compose?to=3Dbidulock@openss7.org" ymailto=3D"mailt=
o:bidulock@openss7.org">bidulock@openss7.org</A><BR><A href=3D"http://www.o=
penss7.org/" target=3D_blank>http://www.openss7.org/</A><BR></DIV></BLOCKQU=
OTE></td></tr></table><br>=0A=0A      
--0-671972463-1236243515=:34184--

From moharana_p@yahoo.com  Thu Mar  5 00:58:07 2009
Return-Path: <moharana_p@yahoo.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA743A67DB for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 00:58:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.537
X-Spam-Level: 
X-Spam-Status: No, score=-1.537 tagged_above=-999 required=5 tests=[AWL=0.127,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2gCmuBPlwXS for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 00:58:07 -0800 (PST)
Received: from web110502.mail.gq1.yahoo.com (web110502.mail.gq1.yahoo.com [67.195.8.250]) by core3.amsl.com (Postfix) with SMTP id DF6B328C169 for <sigtran@ietf.org>; Thu,  5 Mar 2009 00:58:06 -0800 (PST)
Received: (qmail 32837 invoked by uid 60001); 5 Mar 2009 08:58:36 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236243516; bh=nu6410dqy3rgpCdTjl2Ejg8TGjyHyJwYssYx0XzrqL4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=kfop8whB39p0CBJbHyZ7+Y87y+7/phuwlsDj42hqXv41+53LPBD/VKTfVg6bCgIeSFm+fXGJHIAdOEgZD3z6sTVixWGINjv7BHtjbg9J2gSt6F79b85uZ5zLSw8sjmSJzNk3VTCQBhW2Ml2lBetTUdbh5qHbpZT3CiRaQ0SjjvM=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=xzggzBDptvuFe76nRO/VOo1zK74zykSxhO+Nkbraguu+Nzw/3B8IJX383IQwEraE0CWxX+zaQeeJj30431bejVwAD8hrasBSwDAQbqMeZdX8JEkPBrb0turGzrYSKxi4YUtTJfNAKk/QHSc1OCKoPDbmAuux320aMyY9TwNpn9Y=;
Message-ID: <84879.31492.qm@web110502.mail.gq1.yahoo.com>
X-YMail-OSG: pev5U3IVM1mLNguVrlvNBDuTmV9OnQHP9ijuToeG6YHyaAKydKCZ33WEEEdogZb7gRKvdhXGkT0ITq61Q92YspwiYN3QXglzn37_McZFAMVfoTfDU4ck1EtXkzRG.0EzJZ_r9hPVmfaeULbyrjBQKBhYwc7TRjKzyZDwd5lpnSZQkeotp9pBM2vYxzWBBZEQIjTKmqFl9yd8JQ--
Received: from [220.227.132.178] by web110502.mail.gq1.yahoo.com via HTTP; Thu, 05 Mar 2009 00:58:35 PST
X-Mailer: YahooMailClassic/5.1.18 YahooMailWebService/0.7.289.1
Date: Thu, 5 Mar 2009 00:58:35 -0800 (PST)
From: moharana_p@yahoo.com
To: bidulock@openss7.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-2384481-1236243515=:31492"
Cc: kmorneau@cisco.com, sigtran <sigtran@ietf.org>
Subject: Re: [Sigtran] Query regarding re-registration procedure in m3ua.
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2009 08:58:07 -0000

--0-2384481-1236243515=:31492
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,
=A0
Is the below call flow right for re-registration procedure.
=A0
ASP=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 SG
--------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -----=
-----
=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=20

--- On Tue, 3/3/09, Brian F. G. Bidulock <bidulock@openss7.org> wrote:


From: Brian F. G. Bidulock <bidulock@openss7.org>
Subject: Re: Query regarding re-registration procedure in m3ua.
To: moharana_p@yahoo.com
Cc: "sigtran" <sigtran@ietf.org>, kmorneau@cisco.com
Date: Tuesday, March 3, 2009, 8:21 AM


-----Inline Attachment Follows-----


moharana_p,

It would be better if you read the specification.

See RFC 4666/4.4.1 Registration:

=A0=A0=A0...

=A0=A0=A0An ASP MAY request modification of an existing Routing Key by
=A0=A0=A0including a Routing Context parameter in a Registration Request
=A0=A0=A0message.=A0 Upon receipt of a Registration Request message contain=
ing a
=A0=A0=A0Routing Context, if the SGP determines that the Routing Context
=A0=A0=A0applies to an existing Routing Key, the SGP MAY adjust the existin=
g
=A0=A0=A0Routing Key to match the new information provided in the Routing K=
ey
=A0=A0=A0parameter.=A0 A Registration Response "ERR Routing Key Change Refu=
sed"
=A0=A0=A0is returned if the SGP does not support this re-registration
=A0=A0=A0procedure or RC does not exist.=A0 Otherwise, a Registration Respo=
nse
=A0=A0=A0"Successfully Registered" is returned.

=A0=A0=A0...

--brian

moharana_p@yahoo.com wrote:=A0 =A0 =A0 =A0 =A0 =A0 =A0 (Tue, 03 Mar 2009 04=
:47:28)
>=20
>=A0 =A0 Hi All,
>=20
>=20
>=A0 =A0 I have some doubt regarding the RC parameter value in the REG REQ
>=A0 =A0 message.
>=20
>=20
>=A0 =A0=A0=A01. As per the RFC4666 the RC is an optional parameter in the =
REG REQ
>=A0 =A0 =A0 =A0 message. Should REG REQ message contain RC parameter durin=
g
>=A0 =A0 =A0 =A0 registering a RK first time or RC parameter is only needed=
 during
>=A0 =A0 =A0 =A0 re registration procedure?
>=A0 =A0=A0=A02. In which scenario re registration of RK is required?
>=20
>=20
>=A0 =A0 Br,
>=A0 =A0 Padmalochan

--=20
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
=0A=0A=0A      
--0-2384481-1236243515=:31492
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Is the below call flow right for re-registration procedure.</DIV>
<DIV>&nbsp;</DIV>
<DIV>ASP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; SG</DIV>
<DIV>--------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ----------</DIV>
<DIV>&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR><BR>--- On <B>Tue, 3/3/09, Brian F. G. =
Bidulock <I>&lt;bidulock@openss7.org&gt;</I></B> wrote:<BR></DIV>
<BLOCKQUOTE style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(=
16,16,255) 2px solid"><BR>From: Brian F. G. Bidulock &lt;bidulock@openss7.o=
rg&gt;<BR>Subject: Re: Query regarding re-registration procedure in m3ua.<B=
R>To: moharana_p@yahoo.com<BR>Cc: "sigtran" &lt;sigtran@ietf.org&gt;, kmorn=
eau@cisco.com<BR>Date: Tuesday, March 3, 2009, 8:21 AM<BR><BR><BR>-----Inli=
ne Attachment Follows-----<BR><BR>
<DIV class=3DplainMail>moharana_p,<BR><BR>It would be better if you read th=
e specification.<BR><BR>See RFC 4666/4.4.1 Registration:<BR><BR>&nbsp;&nbsp=
;&nbsp;...<BR><BR>&nbsp;&nbsp;&nbsp;An ASP MAY request modification of an e=
xisting Routing Key by<BR>&nbsp;&nbsp;&nbsp;including a Routing Context par=
ameter in a Registration Request<BR>&nbsp;&nbsp;&nbsp;message.&nbsp; Upon r=
eceipt of a Registration Request message containing a<BR>&nbsp;&nbsp;&nbsp;=
Routing Context, if the SGP determines that the Routing Context<BR>&nbsp;&n=
bsp;&nbsp;applies to an existing Routing Key, the SGP MAY adjust the existi=
ng<BR>&nbsp;&nbsp;&nbsp;Routing Key to match the new information provided i=
n the Routing Key<BR>&nbsp;&nbsp;&nbsp;parameter.&nbsp; A Registration Resp=
onse "ERR Routing Key Change Refused"<BR>&nbsp;&nbsp;&nbsp;is returned if t=
he SGP does not support this re-registration<BR>&nbsp;&nbsp;&nbsp;procedure=
 or RC does not exist.&nbsp; Otherwise, a Registration
 Response<BR>&nbsp;&nbsp;&nbsp;"Successfully Registered" is returned.<BR><B=
R>&nbsp;&nbsp;&nbsp;...<BR><BR>--brian<BR><BR><A href=3D"http://us.mc1105.m=
ail.yahoo.com/mc/compose?to=3Dmoharana_p@yahoo.com" ymailto=3D"mailto:mohar=
ana_p@yahoo.com">moharana_p@yahoo.com</A> wrote:&nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; (Tue, 03 Mar 2009 04:47:28)<BR>&gt; <BR>&gt;&nbsp; &n=
bsp; Hi All,<BR>&gt; <BR>&gt; <BR>&gt;&nbsp; &nbsp; I have some doubt regar=
ding the RC parameter value in the REG REQ<BR>&gt;&nbsp; &nbsp; message.<BR=
>&gt; <BR>&gt; <BR>&gt;&nbsp; &nbsp;&nbsp;&nbsp;1. As per the RFC4666 the R=
C is an optional parameter in the REG REQ<BR>&gt;&nbsp; &nbsp; &nbsp; &nbsp=
; message. Should REG REQ message contain RC parameter during<BR>&gt;&nbsp;=
 &nbsp; &nbsp; &nbsp; registering a RK first time or RC parameter is only n=
eeded during<BR>&gt;&nbsp; &nbsp; &nbsp; &nbsp; re registration procedure?<=
BR>&gt;&nbsp; &nbsp;&nbsp;&nbsp;2. In which scenario re registration of RK
 is required?<BR>&gt; <BR>&gt; <BR>&gt;&nbsp; &nbsp; Br,<BR>&gt;&nbsp; &nbs=
p; Padmalochan<BR><BR>-- <BR>Brian F. G. Bidulock<BR><A href=3D"http://us.m=
c1105.mail.yahoo.com/mc/compose?to=3Dbidulock@openss7.org" ymailto=3D"mailt=
o:bidulock@openss7.org">bidulock@openss7.org</A><BR><A href=3D"http://www.o=
penss7.org/" target=3D_blank>http://www.openss7.org/</A><BR></DIV></BLOCKQU=
OTE></td></tr></table><br>=0A=0A      
--0-2384481-1236243515=:31492--

From moharana_p@yahoo.com  Thu Mar  5 00:58:09 2009
Return-Path: <moharana_p@yahoo.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED06628C1F3 for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 00:58:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.547
X-Spam-Level: 
X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=0.117,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geCxtUxYmo4Z for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 00:58:09 -0800 (PST)
Received: from web110513.mail.gq1.yahoo.com (web110513.mail.gq1.yahoo.com [67.195.8.118]) by core3.amsl.com (Postfix) with SMTP id A215128C1E4 for <sigtran@ietf.org>; Thu,  5 Mar 2009 00:58:08 -0800 (PST)
Received: (qmail 32865 invoked by uid 60001); 5 Mar 2009 08:58:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236243517; bh=BsIDhq8MvDxDpHmksgneePZhyRbbiUXXTQWLMgmWji0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=EILr0WRd32obRDeMvbpVu+YZgsFgEB+sd0UK+/GRJp7GhftftN2Z7JqmcHuxmd1sTlfl1pFtUQ4//4eg1f4l3R9ureluMe+Ex20inNlIdfpVUdrU/QXDj+CGNDsp98Jz3y0+ZfWVM3ZfCfrZuQP2d/QIKMEM+JWaTW8kN/Lwat4=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=XxQQImqqX9x4piGis6Xgs9ap/T8pUJa2LPeSx75YO+UE4mphzElgBxyHM9i+FLYXLP9KgW8l+6lq3cjhkPCpMRQ/K6ciPBvSej9DaFcqMQF+0K0ZtOSXm1Dwcd5zPSUd1R9WkxlwmdEO/Y7fOgUY7wtk1UBvv6qTSrUCb2iW+mk=;
Message-ID: <909369.32693.qm@web110513.mail.gq1.yahoo.com>
X-YMail-OSG: JGW4rsEVM1m3sdyrwgzC8.kTJUwZ89DU0dO4DyRuL.MQUkD7Zgx7t2P7rxgACj2HgtD82Esv3O9vIHvGbNvG9PvFbo8PcRBVTVxIztApYbVWeLmw0AlhmU8wfWfjedY866ZqHQA.Fw0vtu9Lh2z4tcGqiBlos.0UdU5wJdLX_7QHHO5UbfdW9ma_i1ba6kaHi_zTD4aIDQVlREOY.xQ6NK9sKcTFnC_qkzIyhMcRZ1SZ0LCwU.1nD2Tvr4eM_BWRPBSyH3_FNV9cTc8F
Received: from [220.227.132.178] by web110513.mail.gq1.yahoo.com via HTTP; Thu, 05 Mar 2009 00:58:36 PST
X-Mailer: YahooMailClassic/5.1.18 YahooMailWebService/0.7.289.1
Date: Thu, 5 Mar 2009 00:58:36 -0800 (PST)
From: moharana_p@yahoo.com
To: bidulock@openss7.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-300186470-1236243516=:32693"
Cc: kmorneau@cisco.com, sigtran <sigtran@ietf.org>
Subject: Re: [Sigtran] Query regarding re-registration procedure in m3ua.
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2009 08:58:10 -0000

--0-300186470-1236243516=:32693
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,
=A0
Is the below call flow right for re-registration procedure.
=A0
ASP=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 SG
--------=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -----=
-----
=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=20

--- On Tue, 3/3/09, Brian F. G. Bidulock <bidulock@openss7.org> wrote:


From: Brian F. G. Bidulock <bidulock@openss7.org>
Subject: Re: Query regarding re-registration procedure in m3ua.
To: moharana_p@yahoo.com
Cc: "sigtran" <sigtran@ietf.org>, kmorneau@cisco.com
Date: Tuesday, March 3, 2009, 8:21 AM


-----Inline Attachment Follows-----


moharana_p,

It would be better if you read the specification.

See RFC 4666/4.4.1 Registration:

=A0=A0=A0...

=A0=A0=A0An ASP MAY request modification of an existing Routing Key by
=A0=A0=A0including a Routing Context parameter in a Registration Request
=A0=A0=A0message.=A0 Upon receipt of a Registration Request message contain=
ing a
=A0=A0=A0Routing Context, if the SGP determines that the Routing Context
=A0=A0=A0applies to an existing Routing Key, the SGP MAY adjust the existin=
g
=A0=A0=A0Routing Key to match the new information provided in the Routing K=
ey
=A0=A0=A0parameter.=A0 A Registration Response "ERR Routing Key Change Refu=
sed"
=A0=A0=A0is returned if the SGP does not support this re-registration
=A0=A0=A0procedure or RC does not exist.=A0 Otherwise, a Registration Respo=
nse
=A0=A0=A0"Successfully Registered" is returned.

=A0=A0=A0...

--brian

moharana_p@yahoo.com wrote:=A0 =A0 =A0 =A0 =A0 =A0 =A0 (Tue, 03 Mar 2009 04=
:47:28)
>=20
>=A0 =A0 Hi All,
>=20
>=20
>=A0 =A0 I have some doubt regarding the RC parameter value in the REG REQ
>=A0 =A0 message.
>=20
>=20
>=A0 =A0=A0=A01. As per the RFC4666 the RC is an optional parameter in the =
REG REQ
>=A0 =A0 =A0 =A0 message. Should REG REQ message contain RC parameter durin=
g
>=A0 =A0 =A0 =A0 registering a RK first time or RC parameter is only needed=
 during
>=A0 =A0 =A0 =A0 re registration procedure?
>=A0 =A0=A0=A02. In which scenario re registration of RK is required?
>=20
>=20
>=A0 =A0 Br,
>=A0 =A0 Padmalochan

--=20
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
=0A=0A=0A      
--0-300186470-1236243516=:32693
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Is the below call flow right for re-registration procedure.</DIV>
<DIV>&nbsp;</DIV>
<DIV>ASP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; SG</DIV>
<DIV>--------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ----------</DIV>
<DIV>&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR><BR>--- On <B>Tue, 3/3/09, Brian =
F. G. Bidulock <I>&lt;bidulock@openss7.org&gt;</I></B> wrote:<BR></DIV>
<BLOCKQUOTE style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(=
16,16,255) 2px solid"><BR>From: Brian F. G. Bidulock &lt;bidulock@openss7.o=
rg&gt;<BR>Subject: Re: Query regarding re-registration procedure in m3ua.<B=
R>To: moharana_p@yahoo.com<BR>Cc: "sigtran" &lt;sigtran@ietf.org&gt;, kmorn=
eau@cisco.com<BR>Date: Tuesday, March 3, 2009, 8:21 AM<BR><BR><BR>-----Inli=
ne Attachment Follows-----<BR><BR>
<DIV class=3DplainMail>moharana_p,<BR><BR>It would be better if you read th=
e specification.<BR><BR>See RFC 4666/4.4.1 Registration:<BR><BR>&nbsp;&nbsp=
;&nbsp;...<BR><BR>&nbsp;&nbsp;&nbsp;An ASP MAY request modification of an e=
xisting Routing Key by<BR>&nbsp;&nbsp;&nbsp;including a Routing Context par=
ameter in a Registration Request<BR>&nbsp;&nbsp;&nbsp;message.&nbsp; Upon r=
eceipt of a Registration Request message containing a<BR>&nbsp;&nbsp;&nbsp;=
Routing Context, if the SGP determines that the Routing Context<BR>&nbsp;&n=
bsp;&nbsp;applies to an existing Routing Key, the SGP MAY adjust the existi=
ng<BR>&nbsp;&nbsp;&nbsp;Routing Key to match the new information provided i=
n the Routing Key<BR>&nbsp;&nbsp;&nbsp;parameter.&nbsp; A Registration Resp=
onse "ERR Routing Key Change Refused"<BR>&nbsp;&nbsp;&nbsp;is returned if t=
he SGP does not support this re-registration<BR>&nbsp;&nbsp;&nbsp;procedure=
 or RC does not exist.&nbsp; Otherwise, a Registration
 Response<BR>&nbsp;&nbsp;&nbsp;"Successfully Registered" is returned.<BR><B=
R>&nbsp;&nbsp;&nbsp;...<BR><BR>--brian<BR><BR><A href=3D"http://us.mc1105.m=
ail.yahoo.com/mc/compose?to=3Dmoharana_p@yahoo.com" ymailto=3D"mailto:mohar=
ana_p@yahoo.com">moharana_p@yahoo.com</A> wrote:&nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; (Tue, 03 Mar 2009 04:47:28)<BR>&gt; <BR>&gt;&nbsp; &n=
bsp; Hi All,<BR>&gt; <BR>&gt; <BR>&gt;&nbsp; &nbsp; I have some doubt regar=
ding the RC parameter value in the REG REQ<BR>&gt;&nbsp; &nbsp; message.<BR=
>&gt; <BR>&gt; <BR>&gt;&nbsp; &nbsp;&nbsp;&nbsp;1. As per the RFC4666 the R=
C is an optional parameter in the REG REQ<BR>&gt;&nbsp; &nbsp; &nbsp; &nbsp=
; message. Should REG REQ message contain RC parameter during<BR>&gt;&nbsp;=
 &nbsp; &nbsp; &nbsp; registering a RK first time or RC parameter is only n=
eeded during<BR>&gt;&nbsp; &nbsp; &nbsp; &nbsp; re registration procedure?<=
BR>&gt;&nbsp; &nbsp;&nbsp;&nbsp;2. In which scenario re registration of RK
 is required?<BR>&gt; <BR>&gt; <BR>&gt;&nbsp; &nbsp; Br,<BR>&gt;&nbsp; &nbs=
p; Padmalochan<BR><BR>-- <BR>Brian F. G. Bidulock<BR><A href=3D"http://us.m=
c1105.mail.yahoo.com/mc/compose?to=3Dbidulock@openss7.org" ymailto=3D"mailt=
o:bidulock@openss7.org">bidulock@openss7.org</A><BR><A href=3D"http://www.o=
penss7.org/" target=3D_blank>http://www.openss7.org/</A><BR></DIV></BLOCKQU=
OTE></td></tr></table><br>=0A=0A=0A=0A      
--0-300186470-1236243516=:32693--

From geoff.hunt@bt.com  Thu Mar  5 01:24:34 2009
Return-Path: <geoff.hunt@bt.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616DD28C1BE for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 01:24:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.801
X-Spam-Level: 
X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=1.198,  BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSIcOqc2uhYZ for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 01:24:33 -0800 (PST)
Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id E167328C132 for <sigtran@ietf.org>; Thu,  5 Mar 2009 01:24:32 -0800 (PST)
Received: from E03MVY2-UKDY.domain1.systemhost.net ([193.113.30.60]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 5 Mar 2009 09:24:59 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 5 Mar 2009 09:24:58 -0000
Message-ID: <B71E03B6EDEAA9438A12F0D64BC08C7906D8C8A8@E03MVY2-UKDY.domain1.systemhost.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New ID draft-hunt-sigtran-iua-rate-message-00
thread-index: AcmddEDpRKnuAWfmQJ+prUtKb2PX3Q==
From: <geoff.hunt@bt.com>
To: <sigtran@ietf.org>
X-OriginalArrivalTime: 05 Mar 2009 09:24:59.0597 (UTC) FILETIME=[41697FD0:01C99D74]
Cc: Lyong@Ciena.com
Subject: [Sigtran] New ID draft-hunt-sigtran-iua-rate-message-00
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2009 09:24:34 -0000

All

The new ID draft-hunt-sigtran-iua-rate-message-00 has recently been
submitted, with title "IUA Extension for Rate Control Message". The
abstract is:

"This document describes a new message, its associated acknowledgement
message, and a new parameter to extend the ISDN Q.921-User Adaptation
(IUA) protocol (RFC4233).  The protocol extension is to support the use
of an Overload Control Agent in a Signaling Gateway (SG).  The Overload
Control Agent is able to restrict the admission of new originating ISDN
calls (sessions) messages from the ISDN End Point to each Application
Server Process (ASP).  Both messages defined here contain a single
mandatory parameter, the Call (Session) Admission Rate.  An ASP is able
to use this protocol extension to control the rate of new calls admitted
towards that ASP by the Overload Control Agent.

"The new message and its acknowledgement message are added to the
Application Server Process Traffic Maintenance (ASPTM) message class.

"As the DPNSS1/DASS2 Extension to IUA (DUA, RFC4129) also uses the ASPTM
message class, the IUA protocol extension described in this document
also applies to DUA.

"For backward compatibility, a Signaling Gateway which does not support
the new message is expected to follow standard IUA behaviour by
discarding the message, and returning an error code of "Unsupported
Message Type" to the sender."

We hope to progress this as an individual draft, with review from the
sigtran community. Review and comments will be much appreciated.

Geoff Hunt=20
BT Design

Tel: 01473 608325
Email: geoff.hunt@bt.com
Web: www.bt.com
This email contains BT information, which may be privileged or
confidential.
It is meant only for the individual(s) or entity named above. If you are
not the intended
recipient, note that disclosing, copying, distributing or using this
information
is prohibited. If you have received this email in error, please let me
know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000



From moharana_p@yahoo.com  Thu Mar  5 01:49:49 2009
Return-Path: <moharana_p@yahoo.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E5128C331 for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 01:49:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.556
X-Spam-Level: 
X-Spam-Status: No, score=-1.556 tagged_above=-999 required=5 tests=[AWL=0.108,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8iAZRDMGmZE for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 01:49:48 -0800 (PST)
Received: from web110508.mail.gq1.yahoo.com (web110508.mail.gq1.yahoo.com [67.195.8.113]) by core3.amsl.com (Postfix) with SMTP id A6D1F28C34C for <sigtran@ietf.org>; Thu,  5 Mar 2009 01:49:48 -0800 (PST)
Received: (qmail 86334 invoked by uid 60001); 5 Mar 2009 09:50:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236246617; bh=o/fcnaV7NEBXxYaJROU6xDp8o/wXG27ZuUmBWvOrAqQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=W8qzlNHu7YVNLXLiUQLxrLflAY6ZsNBKk10MLAuI4B4LZO4XLFraD0/QalWuqr/IMkF1Ss+4HbuCJCQ6lZIcYwf48tIXfKWpaGxJ0e7R+9m0rS4y9++lzh2murU/AkZsgQLw1iewQyIG0GcyDr5doleG8BUkQ66/25gDra4KjeI=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=Nj5w3hI0a/7UmgCeuD4e7M4OuoPja3sgN1ISQNoiZhSFiENeS903arvBq9cw/+syHugRS+cuMTRJ/RwtUJqxy8aSCIb2ASGHjq1zd1mQBbwl94jCDZb49mhfQNFoQKTxbQP89P9DCF0Lv415UDMhIjuCYeOAVbCQN4Q/lTt4uAE=;
Message-ID: <929198.85026.qm@web110508.mail.gq1.yahoo.com>
X-YMail-OSG: gVYMEUMVM1naJj875Qb0lcJ1S6h2ggBtAQyEk8kSN0qz_FHovSY6kNM9VE9XEMazG2nCkxFWqVT7uNZ0wBwRTRoh_GjPI8rYfV_6NhbEh.Xv72uLTviMJsZPub2rOLvYxfZRTpTTWIgJWRZDlRa61uACCFNpmFXNy4yvFiFjAfVAUW.kpZXcYjYxWUWvuN9iRi0DlS1LINsPcQ--
Received: from [220.227.132.178] by web110508.mail.gq1.yahoo.com via HTTP; Thu, 05 Mar 2009 01:50:17 PST
X-Mailer: YahooMailClassic/5.1.18 YahooMailWebService/0.7.289.1
Date: Thu, 5 Mar 2009 01:50:17 -0800 (PST)
From: moharana_p@yahoo.com
To: bidulock@openss7.org, sigtran <sigtran@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-564790804-1236246617=:85026"
Cc: kmorneau@cisco.com
Subject: Re: [Sigtran] Query regarding re-registration procedure in m3ua.
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2009 09:49:49 -0000

--0-564790804-1236246617=:85026
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi ,
=A0
Is the below call flow Okay for the re-registartion procedure?
=A0
ASP=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SG
-----=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -----=A0
=A0 |=A0REG REQ(LK1,RK1)=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0|
=A0 |---------------------------------------->|
=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0|
=A0 |=A0=A0=A0=A0=A0 REG RSP(LK1,RC1)=A0=A0=A0=A0=A0=A0|=A0
=A0 |<----------------------------------------|
=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0 |=A0=A0=A0 ASP ACTIVE (RC1)=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0 |----------------------------------------->|
=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0|=A0
=A0 |=A0=A0=A0=A0 ASP ACTIVE ACK=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|
=A0 |<-----------------------------------------|
=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0 |=A0REG REQ(RC1,LK2,RK2)=A0=A0=A0=A0 |
=A0 |----------------------------------------->|
=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0 |=A0=A0=A0=A0 REG RSP(LK2,RC2)=A0=A0=A0=A0=A0=A0 =A0|=A0
=A0 |<-----------------------------------------|
=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
Br,
Padmalochan


--- On Tue, 3/3/09, Brian F. G. Bidulock <bidulock@openss7.org> wrote:


From: Brian F. G. Bidulock <bidulock@openss7.org>
Subject: Re: Query regarding re-registration procedure in m3ua.
To: moharana_p@yahoo.com
Cc: "sigtran" <sigtran@ietf.org>, kmorneau@cisco.com
Date: Tuesday, March 3, 2009, 8:21 AM


-----Inline Attachment Follows-----


moharana_p,

It would be better if you read the specification.

See RFC 4666/4.4.1 Registration:

=A0=A0=A0...

=A0=A0=A0An ASP MAY request modification of an existing Routing Key by
=A0=A0=A0including a Routing Context parameter in a Registration Request
=A0=A0=A0message.=A0 Upon receipt of a Registration Request message contain=
ing a
=A0=A0=A0Routing Context, if the SGP determines that the Routing Context
=A0=A0=A0applies to an existing Routing Key, the SGP MAY adjust the existin=
g
=A0=A0=A0Routing Key to match the new information provided in the Routing K=
ey
=A0=A0=A0parameter.=A0 A Registration Response "ERR Routing Key Change Refu=
sed"
=A0=A0=A0is returned if the SGP does not support this re-registration
=A0=A0=A0procedure or RC does not exist.=A0 Otherwise, a Registration Respo=
nse
=A0=A0=A0"Successfully Registered" is returned.

=A0=A0=A0...

--brian

moharana_p@yahoo.com wrote:=A0 =A0 =A0 =A0 =A0 =A0 =A0 (Tue, 03 Mar 2009 04=
:47:28)
>=20
>=A0 =A0 Hi All,
>=20
>=20
>=A0 =A0 I have some doubt regarding the RC parameter value in the REG REQ
>=A0 =A0 message.
>=20
>=20
>=A0 =A0=A0=A01. As per the RFC4666 the RC is an optional parameter in the =
REG REQ
>=A0 =A0 =A0 =A0 message. Should REG REQ message contain RC parameter durin=
g
>=A0 =A0 =A0 =A0 registering a RK first time or RC parameter is only needed=
 during
>=A0 =A0 =A0 =A0 re registration procedure?
>=A0 =A0=A0=A02. In which scenario re registration of RK is required?
>=20
>=20
>=A0 =A0 Br,
>=A0 =A0 Padmalochan

--=20
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
=0A=0A=0A      
--0-564790804-1236246617=:85026
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><DIV>Hi ,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Is the below call flow Okay for the re-registartion procedure?</DIV>
<DIV>&nbsp;</DIV>
<DIV>ASP&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 SG<BR>-----&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; -----&nbsp;<BR>&nbsp; |&nbsp;REG REQ(LK1,RK1)&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;|<BR>&nbsp; |---------------=
-------------------------&gt;|<BR>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;|<BR>&nbsp;=
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; REG
 RSP(LK1,RC1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;<BR>&nbsp; |&lt;---=
-------------------------------------|<BR>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<B=
R>&nbsp; |&nbsp;&nbsp;&nbsp; ASP ACTIVE (RC1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; |-------------------------------------=
----&gt;|<BR>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;|&nbsp;<BR>&nbsp; |&nbsp;&=
nbsp;&nbsp;&nbsp; ASP ACTIVE ACK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;|<BR>&nbsp;
 |&lt;-----------------------------------------|<BR>&nbsp; |&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; |<BR>&nbsp; |&nbsp;REG REQ(RC1,LK2,RK2)&nbsp;&nbsp;&nbsp;&nbsp=
; |<BR>&nbsp; |-----------------------------------------&gt;|<BR>&nbsp; |&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; REG RSP(LK2=
,RC2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;|&nbsp;<BR>&nbsp; |&lt;----=
-------------------------------------|<BR>&nbsp;
 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<BR>Br,</DIV>
<DIV>Padmalochan<BR><BR><BR>--- On <B>Tue, 3/3/09, Brian F. G. Bidulock <I>=
&lt;bidulock@openss7.org&gt;</I></B> wrote:<BR></DIV>
<BLOCKQUOTE style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(=
16,16,255) 2px solid"><BR>From: Brian F. G. Bidulock &lt;bidulock@openss7.o=
rg&gt;<BR>Subject: Re: Query regarding re-registration procedure in m3ua.<B=
R>To: moharana_p@yahoo.com<BR>Cc: "sigtran" &lt;sigtran@ietf.org&gt;, kmorn=
eau@cisco.com<BR>Date: Tuesday, March 3, 2009, 8:21 AM<BR><BR><BR>-----Inli=
ne Attachment Follows-----<BR><BR>
<DIV class=3DplainMail>moharana_p,<BR><BR>It would be better if you read th=
e specification.<BR><BR>See RFC 4666/4.4.1 Registration:<BR><BR>&nbsp;&nbsp=
;&nbsp;...<BR><BR>&nbsp;&nbsp;&nbsp;An ASP MAY request modification of an e=
xisting Routing Key by<BR>&nbsp;&nbsp;&nbsp;including a Routing Context par=
ameter in a Registration Request<BR>&nbsp;&nbsp;&nbsp;message.&nbsp; Upon r=
eceipt of a Registration Request message containing a<BR>&nbsp;&nbsp;&nbsp;=
Routing Context, if the SGP determines that the Routing Context<BR>&nbsp;&n=
bsp;&nbsp;applies to an existing Routing Key, the SGP MAY adjust the existi=
ng<BR>&nbsp;&nbsp;&nbsp;Routing Key to match the new information provided i=
n the Routing Key<BR>&nbsp;&nbsp;&nbsp;parameter.&nbsp; A Registration Resp=
onse "ERR Routing Key Change Refused"<BR>&nbsp;&nbsp;&nbsp;is returned if t=
he SGP does not support this re-registration<BR>&nbsp;&nbsp;&nbsp;procedure=
 or RC does not exist.&nbsp; Otherwise, a Registration
 Response<BR>&nbsp;&nbsp;&nbsp;"Successfully Registered" is returned.<BR><B=
R>&nbsp;&nbsp;&nbsp;...<BR><BR>--brian<BR><BR><A href=3D"http://us.mc1105.m=
ail.yahoo.com/mc/compose?to=3Dmoharana_p@yahoo.com" ymailto=3D"mailto:mohar=
ana_p@yahoo.com">moharana_p@yahoo.com</A> wrote:&nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; (Tue, 03 Mar 2009 04:47:28)<BR>&gt; <BR>&gt;&nbsp; &n=
bsp; Hi All,<BR>&gt; <BR>&gt; <BR>&gt;&nbsp; &nbsp; I have some doubt regar=
ding the RC parameter value in the REG REQ<BR>&gt;&nbsp; &nbsp; message.<BR=
>&gt; <BR>&gt; <BR>&gt;&nbsp; &nbsp;&nbsp;&nbsp;1. As per the RFC4666 the R=
C is an optional parameter in the REG REQ<BR>&gt;&nbsp; &nbsp; &nbsp; &nbsp=
; message. Should REG REQ message contain RC parameter during<BR>&gt;&nbsp;=
 &nbsp; &nbsp; &nbsp; registering a RK first time or RC parameter is only n=
eeded during<BR>&gt;&nbsp; &nbsp; &nbsp; &nbsp; re registration procedure?<=
BR>&gt;&nbsp; &nbsp;&nbsp;&nbsp;2. In which scenario re registration of RK
 is required?<BR>&gt; <BR>&gt; <BR>&gt;&nbsp; &nbsp; Br,<BR>&gt;&nbsp; &nbs=
p; Padmalochan<BR><BR>-- <BR>Brian F. G. Bidulock<BR><A href=3D"http://us.m=
c1105.mail.yahoo.com/mc/compose?to=3Dbidulock@openss7.org" ymailto=3D"mailt=
o:bidulock@openss7.org">bidulock@openss7.org</A><BR><A href=3D"http://www.o=
penss7.org/" target=3D_blank>http://www.openss7.org/</A><BR></DIV></BLOCKQU=
OTE></td></tr></table><br>=0A=0A=0A=0A      
--0-564790804-1236246617=:85026--

From bidulock@openss7.org  Thu Mar  5 02:12:36 2009
Return-Path: <bidulock@openss7.org>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0F5428C427 for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 02:12:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.199
X-Spam-Level: 
X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2szKiNKUb8W for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 02:12:35 -0800 (PST)
Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 8836828C413 for <sigtran@ietf.org>; Thu,  5 Mar 2009 02:12:35 -0800 (PST)
Received: from ns.pigworks.openss7.net (IDENT:63xo4W+SJmFnW07tYAa7Fn/Vq+xEmEhp@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id n25AD4T07514; Thu, 5 Mar 2009 03:13:04 -0700
Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id n25AD4a32585; Thu, 5 Mar 2009 03:13:04 -0700
Date: Thu, 5 Mar 2009 03:13:04 -0700
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: moharana_p@yahoo.com, sigtran@ietf.org
Message-ID: <20090305031304.A32576@openss7.org>
Mail-Followup-To: moharana_p@yahoo.com, sigtran@ietf.org
References: <700012.24253.qm@web110512.mail.gq1.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <700012.24253.qm@web110512.mail.gq1.yahoo.com>
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-To: <blockme@openss7.com>
Subject: Re: [Sigtran] Query regarding re-registration procedure in m3ua.
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2009 10:12:36 -0000

moharana_p,

No.  There should be RC1 in the last REG RSP not RC2.

--brian

On Thu, 05 Mar 2009, moharana_p@yahoo.com wrote:

> 
>    Hi ,
> 
>    Is the below call flow Okay for the re-registartion procedure?
> 
>    ASP                                      SG
>    -----                                       -----
>      | REG REQ(LK1,RK1)           |
>      |---------------------------------------->|
>      |                                          |
>      |      REG RSP(LK1,RC1)      |
>      |<----------------------------------------|
>      |                                          |
>      |    ASP ACTIVE (RC1)          |
>      |----------------------------------------->|
>      |                                           |
>      |     ASP ACTIVE ACK           |
>      |<-----------------------------------------|
>      |                                           |
>      | REG REQ(RC1,LK2,RK2)     |
>      |----------------------------------------->|
>      |                                           |
>      |     REG RSP(LK2,RC2)        |
>      |<-----------------------------------------|
>      |                                           |
>    Br,
>    Padmalochan
>    --- On Tue, 3/3/09, Brian F. G. Bidulock <bidulock@openss7.org> wrote:
> 
>      From: Brian F. G. Bidulock <bidulock@openss7.org>
>      Subject: Re: Query regarding re-registration procedure in m3ua.
>      To: moharana_p@yahoo.com
>      Cc: "sigtran" <sigtran@ietf.org>, kmorneau@cisco.com
>      Date: Tuesday, March 3, 2009, 8:21 AM
>      -----Inline Attachment Follows-----
> 
>    moharana_p,
>    It would be better if you read the specification.
>    See RFC 4666/4.4.1 Registration:
>       ...
>       An ASP MAY request modification of an existing Routing Key by
>       including a Routing Context parameter in a Registration Request
>       message.  Upon receipt of a Registration Request message containing
>    a
>       Routing Context, if the SGP determines that the Routing Context
>       applies to an existing Routing Key, the SGP MAY adjust the existing
>       Routing Key to match the new information provided in the Routing
>    Key
>       parameter.  A Registration Response "ERR Routing Key Change
>    Refused"
>       is returned if the SGP does not support this re-registration
>       procedure or RC does not exist.  Otherwise, a Registration Response
>       "Successfully Registered" is returned.
>       ...
>    --brian
>    [1]moharana_p@yahoo.com wrote:              (Tue, 03 Mar 2009
>    04:47:28)
>    >
>    >    Hi All,
>    >
>    >
>    >    I have some doubt regarding the RC parameter value in the REG REQ
>    >    message.
>    >
>    >
>    >     1. As per the RFC4666 the RC is an optional parameter in the REG
>    REQ
>    >        message. Should REG REQ message contain RC parameter during
>    >        registering a RK first time or RC parameter is only needed
>    during
>    >        re registration procedure?
>    >     2. In which scenario re registration of RK is required?
>    >
>    >
>    >    Br,
>    >    Padmalochan
>    --
>    Brian F. G. Bidulock
>    [2]bidulock@openss7.org
>    [3]http://www.openss7.org/
> 
> References
> 
>    1. http://us.mc1105.mail.yahoo.com/mc/compose?to=moharana_p@yahoo.com
>    2. http://us.mc1105.mail.yahoo.com/mc/compose?to=bidulock@openss7.org
>    3. http://www.openss7.org/

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦


From bidulock@openss7.org  Thu Mar  5 02:15:56 2009
Return-Path: <bidulock@openss7.org>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E44028C37E for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 02:15:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.187
X-Spam-Level: 
X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDk34xL2tkZG for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 02:15:55 -0800 (PST)
Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 42D6228C36B for <sigtran@ietf.org>; Thu,  5 Mar 2009 02:15:55 -0800 (PST)
Received: from ns.pigworks.openss7.net (IDENT:rIs5QyA1hP3nfVbTlUY/Pdmo0pAZ4K+N@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id n25AGOT07590; Thu, 5 Mar 2009 03:16:24 -0700
Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id n25AGOr32612; Thu, 5 Mar 2009 03:16:24 -0700
Date: Thu, 5 Mar 2009 03:16:23 -0700
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: moharana_p@yahoo.com, sigtran@ietf.org
Message-ID: <20090305031623.A32599@openss7.org>
Mail-Followup-To: moharana_p@yahoo.com, sigtran@ietf.org
References: <213767.60579.qm@web110511.mail.gq1.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <213767.60579.qm@web110511.mail.gq1.yahoo.com>; from moharana_p@yahoo.com on Thu, Mar 05, 2009 at 02:12:41AM -0800
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-To: <blockme@openss7.com>
Subject: Re: [Sigtran] Query regarding re-registration procedure in m3ua.
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2009 10:15:56 -0000

moharana_p,

Reread the section on registration again.

Adding an RC to the REG REQ asks the SG to modify an existing
routing key, not register a new one.

--brian

On Thu, 05 Mar 2009, moharana_p@yahoo.com wrote:

> 
>    Hi Sir,
> 
>    RC should be uniqe at SG end so how SGP send RC1 for RK2 also?
> 
>    Br,
>    Padmalochan
>    --- On Thu, 3/5/09, Brian F. G. Bidulock <bidulock@openss7.org> wrote:
> 
>      From: Brian F. G. Bidulock <bidulock@openss7.org>
>      Subject: Re: Query regarding re-registration procedure in m3ua.
>      To: moharana_p@yahoo.com
>      Date: Thursday, March 5, 2009, 4:04 AM
>      -----Inline Attachment Follows-----
> 
>    moharana_p,
>    No.  There should be RC1 in the last REG RSP not RC2.
>    --brian
>    On Thu, 05 Mar 2009, [1]moharana_p@yahoo.com wrote:
>    >
>    >    Hi ,
>    >
>    >    Is the below call flow Okay for the re-registartion procedure?
>    >
>    >    ASP                                      SG
>    >    -----                                       -----
>    >      | REG REQ(LK1,RK1)           |
>    >      |---------------------------------------->|
>    >      |                                          |
>    >      |      REG RSP(LK1,RC1)      |
>    >      |<----------------------------------------|
>    >      |                                          |
>    >      |    ASP ACTIVE (RC1)          |
>    >      |----------------------------------------->|
>    >      |                                           |
>    >      |     ASP ACTIVE ACK           |
>    >      |<-----------------------------------------|
>    >      |                                           |
>    >      | REG REQ(RC1,LK2,RK2)     |
>    >      |----------------------------------------->|
>    >      |                                           |
>    >      |     REG RSP(LK2,RC2)        |
>    >      |<-----------------------------------------|
>    >      |                                           |
>    >    Br,
>    >    Padmalochan
>    >    --- On Tue, 3/3/09, Brian F. G. Bidulock
>    <[2]bidulock@openss7.org> wrote:
>    >
>    >      From: Brian F. G. Bidulock <[3]bidulock@openss7.org>
>    >      Subject: Re: Query regarding re-registration procedure in m3ua.
>    >      To: [4]moharana_p@yahoo.com
>    >      Cc: "sigtran" <[5]sigtran@ietf.org>, [6]kmorneau@cisco.com
>    >      Date: Tuesday, March 3, 2009, 8:21 AM
>    >      -----Inline Attachment Follows-----
>    >
>    >    moharana_p,
>    >    It would be better if you read the specification.
>    >    See RFC 4666/4.4.1 Registration:
>    >       ...
>    >       An ASP MAY request modification of an existing Routing Key by
>    >       including a Routing Context parameter in a Registration
>    Request
>    >       message.  Upon receipt of a Registration Request message
>    containing
>    >    a
>    >       Routing Context, if the SGP determines that the Routing
>    Context
>    >       applies to an existing Routing Key, the SGP MAY adjust the
>    existing
>    >       Routing Key to match the new information provided in the
>    Routing
>    >    Key
>    >       parameter.  A Registration Response "ERR Routing Key Change
>    >    Refused"
>    >       is returned if the SGP does not support this re-registration
>    >       procedure or RC does not exist.  Otherwise, a Registration
>    Response
>    >       "Successfully Registered" is returned.
>    >       ...
>    >    --brian
>    >    [1][7]moharana_p@yahoo.com wrote:              (Tue, 03 Mar 2009
>    >    04:47:28)
>    >    >
>    >    >    Hi All,
>    >    >
>    >    >
>    >    >    I have some doubt regarding the RC parameter value in the
>    REG REQ
>    >    >    message.
>    >    >
>    >    >
>    >    >     1. As per the RFC4666 the RC is an optional parameter in
>    the REG
>    >    REQ
>    >    >        message. Should REG REQ message contain RC parameter
>    during
>    >    >        registering a RK first time or RC parameter is only
>    needed
>    >    during
>    >    >        re registration procedure?
>    >    >     2. In which scenario re registration of RK is required?
>    >    >
>    >    >
>    >    >    Br,
>    >    >    Padmalochan
>    >    --
>    >    Brian F. G. Bidulock
>    >    [2][8]bidulock@openss7.org
>    >    [3][9]http://www.openss7.org/
>    >
>    > References
>    >
>    >    1.
>    [10]http://us.mc1105.mail.yahoo.com/mc/compose?to=moharana_p@yahoo.com
>    >    2.
>    [11]http://us.mc1105.mail.yahoo.com/mc/compose?to=bidulock@openss7.org
>    >    3. [12]http://www.openss7.org/
>    --
>    Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
>    [13]bidulock@openss7.org    ¦ world; the unreasonable one persists in
>    ¦
>    [14]http://www.openss7.org/ ¦ trying  to adapt the  world  to himself.
>    ¦
>                            ¦ Therefore  all  progress  depends on the ¦
>                            ¦ unreasonable man. -- George Bernard Shaw ¦
> 
> References
> 
>    1. http://us.mc1105.mail.yahoo.com/mc/compose?to=moharana_p@yahoo.com
>    2. http://us.mc1105.mail.yahoo.com/mc/compose?to=bidulock@openss7.org
>    3. http://us.mc1105.mail.yahoo.com/mc/compose?to=bidulock@openss7.org
>    4. http://us.mc1105.mail.yahoo.com/mc/compose?to=moharana_p@yahoo.com
>    5. http://us.mc1105.mail.yahoo.com/mc/compose?to=sigtran@ietf.org
>    6. http://us.mc1105.mail.yahoo.com/mc/compose?to=kmorneau@cisco.com
>    7. http://us.mc1105.mail.yahoo.com/mc/compose?to=moharana_p@yahoo.com
>    8. http://us.mc1105.mail.yahoo.com/mc/compose?to=bidulock@openss7.org
>    9. http://www.openss7.org/
>   10. http://us.mc1105.mail.yahoo.com/mc/compose?to=moharana_p@yahoo.com
>   11. http://us.mc1105.mail.yahoo.com/mc/compose?to=bidulock@openss7.org
>   12. http://www.openss7.org/
>   13. http://us.mc1105.mail.yahoo.com/mc/compose?to=bidulock@openss7.org
>   14. http://www.openss7.org/

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

From moharana_p@yahoo.com  Thu Mar  5 05:09:49 2009
Return-Path: <moharana_p@yahoo.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C5933A6BB0 for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 05:09:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.563
X-Spam-Level: 
X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=0.101,  BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3vqcAv+OwFK for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 05:09:48 -0800 (PST)
Received: from web110515.mail.gq1.yahoo.com (web110515.mail.gq1.yahoo.com [67.195.8.120]) by core3.amsl.com (Postfix) with SMTP id 2400C3A6850 for <sigtran@ietf.org>; Thu,  5 Mar 2009 05:09:48 -0800 (PST)
Received: (qmail 33509 invoked by uid 60001); 5 Mar 2009 13:10:17 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1236258617; bh=eStUwusx0F1rBDL7LDCuBboueBzNAcwjclxd3uYZd1s=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=G6sPF8/GmnrZke+8/5GbAYFQs+20gUh5/66K02RY14zx3fiVVrhhAN2uMtu5nQEUqpRcMFRIImuHti0PBwdoAKDN8YvAytKB87jbowm+K10VUAauQSpgjeAHZI+Ttdi422u1Yyy+EXzXH800RhMYbggkv4axFT7KneChpYDdRDo=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=wTyX1YXtzrg6PWzyfP7AID7oP0A8YRsHOm53ahpLBKJ3YV5FpSw+6yvPlQKyFYBkb+WxdpYtgKnh9QqCAVkBP6Yi8vrJk14xoRaSg8lAnUpDybQSUo7JrUt5qTWHbdZ/l8SnbmrBKx/0P9yGcYNlxJAdM9mLYcb4zD9WmJOgidI=;
Message-ID: <348451.32707.qm@web110515.mail.gq1.yahoo.com>
X-YMail-OSG: wptiuboVM1lbSSGgLdygRj71rePH.fZtjZn6y9nEB.ptKwwZtvcS5iHD0a2Q7KPniaHuwub_4Q19uJuNlC2rrEJFPTkRNXMonL_JTMuycN8FCGyYKPjwIXLUjkVeTA99FzAyKEiOuFL_8MKk7Wx1BiIzKg0IfK1jfrOJ9dlK45ujYBLA3pmgQQgK4oJm0g7mtWxOvc0Hfa2r38qQ3YUSE48gIxlmCiRgLrFKgBZ2SOwsqYHR5rXTNIIlPsJ0WwAW8tOe4EpVLDFE5VDrZTH5mC0ytsdHgQ--
Received: from [220.227.132.178] by web110515.mail.gq1.yahoo.com via HTTP; Thu, 05 Mar 2009 05:10:17 PST
X-Mailer: YahooMailClassic/5.1.18 YahooMailWebService/0.7.289.1
Date: Thu, 5 Mar 2009 05:10:17 -0800 (PST)
From: moharana_p@yahoo.com
To: sigtran <sigtran@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-467490690-1236258617=:32707"
Subject: Re: [Sigtran] SCCP connection refusal
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: moharana_p@yahoo.com
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2009 13:09:49 -0000

--0-467490690-1236258617=:32707
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


Hi,=A0
I knew peer SCCP is refusing connection, but why ?=A0 Cause " end user orig=
inated" meant what ? In which situation the peer can refuse connection with=
 this cause.
=A0
Thanks.


--- On Tue, 3/3/09, Brian F. G. Bidulock <bidulock@openss7.org> wrote:


From: Brian F. G. Bidulock <bidulock@openss7.org>
Subject: Re: SCCP connection refusal
To: moharana_p@yahoo.com
Cc: "sigtran" <sigtran@ietf.org>
Date: Tuesday, March 3, 2009, 1:23 AM


-----Inline Attachment Follows-----


moharana_p,

Sorry, I read your note as SCTP not SCCP.

SCCP refusal cause "end user originated" is when the called
SCCP User (in this case I presume BSSAP or RANAP) refuses
the connection.

--brian

moharana_p@yahoo.com wrote:=A0 =A0 =A0 =A0 =A0 =A0 =A0 (Mon, 02 Mar 2009 20=
:42:13)
>=20
>=A0 =A0 Brian,
>=A0 =A0 The SCTP association still UP. We did not notice any ABORT. If the=
re
>=A0 =A0 was an ABORT, SCCP connection request would n't have gone till pee=
r
>=A0 =A0 node SCCP layer which is above M3UA.
>=A0 =A0 Thanks
>=A0 =A0 --- On Mon, 3/2/09, Brian F. G. Bidulock <bidulock@openss7.org> wr=
ote:
>=20
>=A0 =A0 =A0 From: Brian F. G. Bidulock <bidulock@openss7.org>
>=A0 =A0 =A0 Subject: Re: SCCP connection refusal
>=A0 =A0 =A0 To: moharana_p@yahoo.com
>=A0 =A0 =A0 Cc: "sigtran" <sigtran@ietf.org>
>=A0 =A0 =A0 Date: Monday, March 2, 2009, 7:56 AM
> moharana_p,
>=20
> As it implies: when the peer user requests an abort.
>=20
> --brian
>=20
> moharana_p@yahoo.com wrote:=A0 =A0 =A0 =A0 =A0 =A0 =A0 (Mon, 02 Mar 2009 =
05:47:32)
> >
> >=A0 =A0 Hi,
> >=A0 =A0 In what scenario the peer node SCCP reject SCCP Connection with =
cause
> >=A0 =A0 "end user originated" ? I had glance in SCCP spec for the
> scenario
> >=A0 =A0 when this can happen but I could not find scenario. Please clari=
fy my
> >=A0 =A0 query. "
> >=A0 =A0 Thanks.
>=20
> --
> Brian F. G. Bidulock
> bidulock@openss7.org
> http://www.openss7.org/

--=20
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/
=0A=0A=0A      
--0-467490690-1236258617=:32707
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><DIV id=3Dyiv381081043>
<DIV>Hi,&nbsp;</DIV>
<DIV>I knew peer SCCP is refusing connection, but why ?&nbsp; Cause " <SPAN=
 class=3Dyshortcuts id=3Dlw_1236258563_0>end user</SPAN> originated" meant =
what ? In which situation the peer can refuse connection with this cause.</=
DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks.<BR><BR><BR>--- On <B>Tue, 3/3/09, Brian F. G. Bidulock <I>&lt;=
bidulock@openss7.org&gt;</I></B> wrote:<BR></DIV>
<BLOCKQUOTE style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(=
16,16,255) 2px solid"><BR>From: Brian F. G. Bidulock &lt;bidulock@openss7.o=
rg&gt;<BR>Subject: Re: SCCP connection refusal<BR>To: moharana_p@yahoo.com<=
BR>Cc: "sigtran" &lt;sigtran@ietf.org&gt;<BR>Date: Tuesday, March 3, 2009, =
1:23 AM<BR><BR><BR>-----Inline Attachment Follows-----<BR><BR>
<DIV class=3DplainMail>moharana_p,<BR><BR>Sorry, I read your note as SCTP n=
ot SCCP.<BR><BR>SCCP refusal cause "end user originated" is when the called=
<BR>SCCP User (in this case I presume BSSAP or RANAP) refuses<BR>the connec=
tion.<BR><BR>--brian<BR><BR><A href=3D"http://us.mc1105.mail.yahoo.com/mc/c=
ompose?to=3Dmoharana_p@yahoo.com" target=3D_blank rel=3Dnofollow>moharana_p=
@yahoo.com</A> wrote:&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (Mon,=
 02 Mar 2009 20:42:13)<BR>&gt; <BR>&gt;&nbsp; &nbsp; Brian,<BR>&gt;&nbsp; &=
nbsp; The SCTP association still UP. We did not notice any ABORT. If there<=
BR>&gt;&nbsp; &nbsp; was an ABORT, SCCP connection request would n't have g=
one till peer<BR>&gt;&nbsp; &nbsp; node SCCP layer which is above M3UA.<BR>=
&gt;&nbsp; &nbsp; Thanks<BR>&gt;&nbsp; &nbsp; --- On Mon, 3/2/09, Brian F. =
G. Bidulock &lt;<A href=3D"http://us.mc1105.mail.yahoo.com/mc/compose?to=3D=
bidulock@openss7.org" target=3D_blank rel=3Dnofollow>bidulock@openss7.org</=
A>&gt;
 wrote:<BR>&gt; <BR>&gt;&nbsp; &nbsp; &nbsp; From: Brian F. G. Bidulock &lt=
;<A href=3D"http://us.mc1105.mail.yahoo.com/mc/compose?to=3Dbidulock@openss=
7.org" target=3D_blank rel=3Dnofollow>bidulock@openss7.org</A>&gt;<BR>&gt;&=
nbsp; &nbsp; &nbsp; Subject: Re: SCCP connection refusal<BR>&gt;&nbsp; &nbs=
p; &nbsp; To: <A href=3D"http://us.mc1105.mail.yahoo.com/mc/compose?to=3Dmo=
harana_p@yahoo.com" target=3D_blank rel=3Dnofollow>moharana_p@yahoo.com</A>=
<BR>&gt;&nbsp; &nbsp; &nbsp; Cc: "sigtran" &lt;<A href=3D"http://us.mc1105.=
mail.yahoo.com/mc/compose?to=3Dsigtran@ietf.org" target=3D_blank rel=3Dnofo=
llow>sigtran@ietf.org</A>&gt;<BR>&gt;&nbsp; &nbsp; &nbsp; Date: Monday, Mar=
ch 2, 2009, 7:56 AM<BR>&gt; moharana_p,<BR>&gt; <BR>&gt; As it implies: whe=
n the peer user requests an abort.<BR>&gt; <BR>&gt; --brian<BR>&gt; <BR>&gt=
; <A href=3D"http://us.mc1105.mail.yahoo.com/mc/compose?to=3Dmoharana_p@yah=
oo.com" target=3D_blank rel=3Dnofollow>moharana_p@yahoo.com</A> wrote:&nbsp=
; &nbsp; &nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; (Mon, 02 Mar 2009 05:47:32)<BR>&gt; &gt;<BR>&gt; &gt;=
&nbsp; &nbsp; Hi,<BR>&gt; &gt;&nbsp; &nbsp; In what scenario the peer node =
SCCP reject SCCP Connection with cause<BR>&gt; &gt;&nbsp; &nbsp; "end user =
originated" ? I had glance in SCCP spec for the<BR>&gt; scenario<BR>&gt; &g=
t;&nbsp; &nbsp; when this can happen but I could not find scenario. Please =
clarify my<BR>&gt; &gt;&nbsp; &nbsp; query. "<BR>&gt; &gt;&nbsp; &nbsp; Tha=
nks.<BR>&gt; <BR>&gt; --<BR>&gt; Brian F. G. Bidulock<BR>&gt; <A href=3D"ht=
tp://us.mc1105.mail.yahoo.com/mc/compose?to=3Dbidulock@openss7.org" target=
=3D_blank rel=3Dnofollow>bidulock@openss7.org</A><BR>&gt; <A href=3D"http:/=
/www.openss7.org/" target=3D_blank rel=3Dnofollow>http://www.openss7.org/</=
A><BR><BR>-- <BR>Brian F. G. Bidulock<BR><A href=3D"http://us.mc1105.mail.y=
ahoo.com/mc/compose?to=3Dbidulock@openss7.org" target=3D_blank rel=3Dnofoll=
ow>bidulock@openss7.org</A><BR><A href=3D"http://www.openss7.org/" target=
=3D_blank
 rel=3Dnofollow>http://www.openss7.org/</A><BR></DIV></BLOCKQUOTE></DIV></t=
d></tr></table><br>=0A=0A=0A=0A      
--0-467490690-1236258617=:32707--

From bidulock@openss7.org  Thu Mar  5 05:18:14 2009
Return-Path: <bidulock@openss7.org>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDD243A6AF8 for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 05:18:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.175
X-Spam-Level: 
X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8l5L2AFTxLtM for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 05:18:13 -0800 (PST)
Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 258A928C1AE for <sigtran@ietf.org>; Thu,  5 Mar 2009 05:18:11 -0800 (PST)
Received: from wilbur.pigworks.openss7.net (IDENT:S/EphDnW5HDdArb/Uh6lKV4faIDyfQqN@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id n25DIc1s019388; Thu, 5 Mar 2009 06:18:38 -0700
Received: from wilbur.pigworks.openss7.net (IDENT:ZbajSnmysrIQc8duNnRZcY/1HOg76pv+@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id n25DIcX9016917; Thu, 5 Mar 2009 06:18:38 -0700
Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id n25DIcRI016916; Thu, 5 Mar 2009 06:18:38 -0700
Date: Thu, 5 Mar 2009 06:18:38 -0700
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: moharana_p@yahoo.com
Message-ID: <20090305131838.GB16188@openss7.org>
Mail-Followup-To: moharana_p@yahoo.com, sigtran <sigtran@ietf.org>
References: <348451.32707.qm@web110515.mail.gq1.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <348451.32707.qm@web110515.mail.gq1.yahoo.com>
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-To: <blockme@openss7.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: sigtran <sigtran@ietf.org>
Subject: Re: [Sigtran] SCCP connection refusal
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2009 13:18:14 -0000

moharana_p,

No. Not peer SCCP: peer SCCP-User.  What is _using_ SCCP?
That is what is refusing the connection.

--brian

moharana_p@yahoo.com wrote:              (Thu, 05 Mar 2009 05:10:17)
> 
>    Hi,
>    I knew peer SCCP is refusing connection, but why ?  Cause " end user
>    originated" meant what ? In which situation the peer can refuse
>    connection with this cause.
> 
>    Thanks.
>    --- On Tue, 3/3/09, Brian F. G. Bidulock <bidulock@openss7.org> wrote:
> 
>      From: Brian F. G. Bidulock <bidulock@openss7.org>
>      Subject: Re: SCCP connection refusal
>      To: moharana_p@yahoo.com
>      Cc: "sigtran" <sigtran@ietf.org>
>      Date: Tuesday, March 3, 2009, 1:23 AM
>      -----Inline Attachment Follows-----
> 
>    moharana_p,
>    Sorry, I read your note as SCTP not SCCP.
>    SCCP refusal cause "end user originated" is when the called
>    SCCP User (in this case I presume BSSAP or RANAP) refuses
>    the connection.
>    --brian
>    [1]moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009
>    20:42:13)
>    >
>    >    Brian,
>    >    The SCTP association still UP. We did not notice any ABORT. If
>    there
>    >    was an ABORT, SCCP connection request would n't have gone till
>    peer
>    >    node SCCP layer which is above M3UA.
>    >    Thanks
>    >    --- On Mon, 3/2/09, Brian F. G. Bidulock
>    <[2]bidulock@openss7.org> wrote:
>    >
>    >      From: Brian F. G. Bidulock <[3]bidulock@openss7.org>
>    >      Subject: Re: SCCP connection refusal
>    >      To: [4]moharana_p@yahoo.com
>    >      Cc: "sigtran" <[5]sigtran@ietf.org>
>    >      Date: Monday, March 2, 2009, 7:56 AM
>    > moharana_p,
>    >
>    > As it implies: when the peer user requests an abort.
>    >
>    > --brian
>    >
>    > [6]moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009
>    05:47:32)
>    > >
>    > >    Hi,
>    > >    In what scenario the peer node SCCP reject SCCP Connection with
>    cause
>    > >    "end user originated" ? I had glance in SCCP spec for the
>    > scenario
>    > >    when this can happen but I could not find scenario. Please
>    clarify my
>    > >    query. "
>    > >    Thanks.
>    >
>    > --
>    > Brian F. G. Bidulock
>    > [7]bidulock@openss7.org
>    > [8]http://www.openss7.org/
>    --
>    Brian F. G. Bidulock
>    [9]bidulock@openss7.org
>    [10]http://www.openss7.org/
> 
> References
> 
>    1. http://us.mc1105.mail.yahoo.com/mc/compose?to=moharana_p@yahoo.com
>    2. http://us.mc1105.mail.yahoo.com/mc/compose?to=bidulock@openss7.org
>    3. http://us.mc1105.mail.yahoo.com/mc/compose?to=bidulock@openss7.org
>    4. http://us.mc1105.mail.yahoo.com/mc/compose?to=moharana_p@yahoo.com
>    5. http://us.mc1105.mail.yahoo.com/mc/compose?to=sigtran@ietf.org
>    6. http://us.mc1105.mail.yahoo.com/mc/compose?to=moharana_p@yahoo.com
>    7. http://us.mc1105.mail.yahoo.com/mc/compose?to=bidulock@openss7.org
>    8. http://www.openss7.org/
>    9. http://us.mc1105.mail.yahoo.com/mc/compose?to=bidulock@openss7.org
>   10. http://www.openss7.org/

> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www.ietf.org/mailman/listinfo/sigtran


-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/

From adi_abuali@yahoo.com  Thu Mar  5 14:38:25 2009
Return-Path: <adi_abuali@yahoo.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906133A6941 for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 14:38:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jl+V81T6h24u for <sigtran@core3.amsl.com>; Thu,  5 Mar 2009 14:38:24 -0800 (PST)
Received: from smtp104.prem.mail.ac4.yahoo.com (smtp104.prem.mail.ac4.yahoo.com [76.13.13.43]) by core3.amsl.com (Postfix) with SMTP id 224823A6821 for <sigtran@ietf.org>; Thu,  5 Mar 2009 14:38:24 -0800 (PST)
Received: (qmail 76183 invoked from network); 5 Mar 2009 22:38:53 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:Disposition-Notification-To; b=TFy7065kKV0HIriSkYKpsqMEnvkAoADWbdXNOA6svGD06pNQQ8D/NIP5Wqt7E0InrC/CigGAw9k2LzGXkiyY73pOpHsVILUHA0vwLyRe1cTduezBNsPxqMQFqxaTlqAKvi+pkW7rZbSFMox7/8p5+sIiwopY9kCb+/jFEeY5J1w= ; 
Received: from unknown (HELO AdiAbuAli) (adi_abuali@86.99.16.17 with login) by smtp104.prem.mail.ac4.yahoo.com with SMTP; 5 Mar 2009 22:38:51 -0000
X-YMail-OSG: Y5jR3YEVM1nuDPeBJtg_V8sFt3BTH3Z7b3OCNzbLmLUjx1nE20hbKHROJ4Mw7m7Ik.2phVidarUuYo12Yl.bsc_SfZgu8o1hDP9scxDrb439vCK08TKsxkvDn77YFvp8UkQ9B5TUxgfZZgC3AbE3VJ1RWjV.s7hfPI_EY8fxZ9jhmoHoHtgSE.S7727X.hTk8KjtqzbElEjYPcowToPYJxiM18U-
X-Yahoo-Newman-Property: ymail-3
From: "Adi AbuAli" <adi_abuali@yahoo.com>
To: <moharana_p@yahoo.com>
References: <mailman.38.1236283202.25324.sigtran@ietf.org>
In-Reply-To: <mailman.38.1236283202.25324.sigtran@ietf.org>
Date: Fri, 6 Mar 2009 02:38:44 +0400
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAF4cZDdoaD9Eo9N5mAPkLePCgAAAEAAAAEzSrNSjVUFFi1vhNmRU9ggBAAAAAA==@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmdzR5cB6NyAGluRd25Var3k5GaDgAFJIig
Content-Language: en-us
Cc: sigtran@ietf.org
Subject: Re: [Sigtran] SCCP connection refusal (Adi AbuAli)
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2009 22:38:25 -0000

Hi Moharana,

It depend on subsystem configurations, i.e. in BSSAP, to include acceptance
of IMSI detach in CREF from MSS, for a previous CR from the BSS (instead of
sending back CC for the CR, and initiate another transaction for IMSI detach
request).
Mainly this option to reduce signaling load by sending back subsystem reply
and close the SCCP connection in one CREF message.

BR,
Adi AbuAli

-----Original Message-----
From: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org] On Behalf
Of sigtran-request@ietf.org
Sent: Friday, March 06, 2009 12:00 AM
To: sigtran@ietf.org
Subject: Sigtran Digest, Vol 59, Issue 6

Send Sigtran mailing list submissions to
	sigtran@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/sigtran
or, via email, send a message with subject or body 'help' to
	sigtran-request@ietf.org

You can reach the person managing the list at
	sigtran-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Sigtran digest..."


Today's Topics:

   1. Re: SCCP connection refusal (moharana_p@yahoo.com)
   2. Re: SCCP connection refusal (Brian F. G. Bidulock)


----------------------------------------------------------------------

Message: 1
Date: Thu, 5 Mar 2009 05:10:17 -0800 (PST)
From: moharana_p@yahoo.com
Subject: Re: [Sigtran] SCCP connection refusal
To: sigtran <sigtran@ietf.org>
Message-ID: <348451.32707.qm@web110515.mail.gq1.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"


Hi,?
I knew peer SCCP is refusing connection, but why ?? Cause " end user
originated" meant what ? In which situation the peer can refuse connection
with this cause.
?
Thanks.


--- On Tue, 3/3/09, Brian F. G. Bidulock <bidulock@openss7.org> wrote:


From: Brian F. G. Bidulock <bidulock@openss7.org>
Subject: Re: SCCP connection refusal
To: moharana_p@yahoo.com
Cc: "sigtran" <sigtran@ietf.org>
Date: Tuesday, March 3, 2009, 1:23 AM


-----Inline Attachment Follows-----


moharana_p,

Sorry, I read your note as SCTP not SCCP.

SCCP refusal cause "end user originated" is when the called
SCCP User (in this case I presume BSSAP or RANAP) refuses
the connection.

--brian

moharana_p@yahoo.com wrote:? ? ? ? ? ? ? (Mon, 02 Mar 2009 20:42:13)
> 
>? ? Brian,
>? ? The SCTP association still UP. We did not notice any ABORT. If there
>? ? was an ABORT, SCCP connection request would n't have gone till peer
>? ? node SCCP layer which is above M3UA.
>? ? Thanks
>? ? --- On Mon, 3/2/09, Brian F. G. Bidulock <bidulock@openss7.org> wrote:
> 
>? ? ? From: Brian F. G. Bidulock <bidulock@openss7.org>
>? ? ? Subject: Re: SCCP connection refusal
>? ? ? To: moharana_p@yahoo.com
>? ? ? Cc: "sigtran" <sigtran@ietf.org>
>? ? ? Date: Monday, March 2, 2009, 7:56 AM
> moharana_p,
> 
> As it implies: when the peer user requests an abort.
> 
> --brian
> 
> moharana_p@yahoo.com wrote:? ? ? ? ? ? ? (Mon, 02 Mar 2009 05:47:32)
> >
> >? ? Hi,
> >? ? In what scenario the peer node SCCP reject SCCP Connection with cause
> >? ? "end user originated" ? I had glance in SCCP spec for the
> scenario
> >? ? when this can happen but I could not find scenario. Please clarify my
> >? ? query. "
> >? ? Thanks.
> 
> --
> Brian F. G. Bidulock
> bidulock@openss7.org
> http://www.openss7.org/

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/sigtran/attachments/20090305/e9474f33/
attachment.htm>

------------------------------

Message: 2
Date: Thu, 5 Mar 2009 06:18:38 -0700
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
Subject: Re: [Sigtran] SCCP connection refusal
To: moharana_p@yahoo.com
Cc: sigtran <sigtran@ietf.org>
Message-ID: <20090305131838.GB16188@openss7.org>
Content-Type: text/plain; charset=us-ascii

moharana_p,

No. Not peer SCCP: peer SCCP-User.  What is _using_ SCCP?
That is what is refusing the connection.

--brian

moharana_p@yahoo.com wrote:              (Thu, 05 Mar 2009 05:10:17)
> 
>    Hi,
>    I knew peer SCCP is refusing connection, but why ?  Cause " end user
>    originated" meant what ? In which situation the peer can refuse
>    connection with this cause.
> 
>    Thanks.
>    --- On Tue, 3/3/09, Brian F. G. Bidulock <bidulock@openss7.org> wrote:
> 
>      From: Brian F. G. Bidulock <bidulock@openss7.org>
>      Subject: Re: SCCP connection refusal
>      To: moharana_p@yahoo.com
>      Cc: "sigtran" <sigtran@ietf.org>
>      Date: Tuesday, March 3, 2009, 1:23 AM
>      -----Inline Attachment Follows-----
> 
>    moharana_p,
>    Sorry, I read your note as SCTP not SCCP.
>    SCCP refusal cause "end user originated" is when the called
>    SCCP User (in this case I presume BSSAP or RANAP) refuses
>    the connection.
>    --brian
>    [1]moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009
>    20:42:13)
>    >
>    >    Brian,
>    >    The SCTP association still UP. We did not notice any ABORT. If
>    there
>    >    was an ABORT, SCCP connection request would n't have gone till
>    peer
>    >    node SCCP layer which is above M3UA.
>    >    Thanks
>    >    --- On Mon, 3/2/09, Brian F. G. Bidulock
>    <[2]bidulock@openss7.org> wrote:
>    >
>    >      From: Brian F. G. Bidulock <[3]bidulock@openss7.org>
>    >      Subject: Re: SCCP connection refusal
>    >      To: [4]moharana_p@yahoo.com
>    >      Cc: "sigtran" <[5]sigtran@ietf.org>
>    >      Date: Monday, March 2, 2009, 7:56 AM
>    > moharana_p,
>    >
>    > As it implies: when the peer user requests an abort.
>    >
>    > --brian
>    >
>    > [6]moharana_p@yahoo.com wrote:              (Mon, 02 Mar 2009
>    05:47:32)
>    > >
>    > >    Hi,
>    > >    In what scenario the peer node SCCP reject SCCP Connection with
>    cause
>    > >    "end user originated" ? I had glance in SCCP spec for the
>    > scenario
>    > >    when this can happen but I could not find scenario. Please
>    clarify my
>    > >    query. "
>    > >    Thanks.
>    >
>    > --
>    > Brian F. G. Bidulock
>    > [7]bidulock@openss7.org
>    > [8]http://www.openss7.org/
>    --
>    Brian F. G. Bidulock
>    [9]bidulock@openss7.org
>    [10]http://www.openss7.org/
> 
> References
> 
>    1. http://us.mc1105.mail.yahoo.com/mc/compose?to=moharana_p@yahoo.com
>    2. http://us.mc1105.mail.yahoo.com/mc/compose?to=bidulock@openss7.org
>    3. http://us.mc1105.mail.yahoo.com/mc/compose?to=bidulock@openss7.org
>    4. http://us.mc1105.mail.yahoo.com/mc/compose?to=moharana_p@yahoo.com
>    5. http://us.mc1105.mail.yahoo.com/mc/compose?to=sigtran@ietf.org
>    6. http://us.mc1105.mail.yahoo.com/mc/compose?to=moharana_p@yahoo.com
>    7. http://us.mc1105.mail.yahoo.com/mc/compose?to=bidulock@openss7.org
>    8. http://www.openss7.org/
>    9. http://us.mc1105.mail.yahoo.com/mc/compose?to=bidulock@openss7.org
>   10. http://www.openss7.org/

> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www.ietf.org/mailman/listinfo/sigtran


-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/


------------------------------

_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www.ietf.org/mailman/listinfo/sigtran


End of Sigtran Digest, Vol 59, Issue 6
**************************************


From root@core3.amsl.com  Thu Mar 19 12:30:04 2009
Return-Path: <root@core3.amsl.com>
X-Original-To: sigtran@ietf.org
Delivered-To: sigtran@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 3DEA528C121; Thu, 19 Mar 2009 12:30:04 -0700 (PDT)
From: IESG Secretary <iesg-secretary@ietf.org>
To: ietf-announce@ietf.org
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <20090319193004.3DEA528C121@core3.amsl.com>
Date: Thu, 19 Mar 2009 12:30:04 -0700 (PDT)
Cc: lyong@ciena.com, sigtran@ietf.org
Subject: [Sigtran] WG Action: Conclusion of Signaling Transport (sigtran)
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2009 19:30:04 -0000

The Signaling Transport (sigtran) working group in the Real-time
Applications and Infrastructure Area has concluded.

The IESG contact persons are Jon Peterson and Cullen Jennings.

The mailing list will remain active.

The  SIGTRAN WG has completed its chartered tasks, which primarily
regarded carrying telephone network signaling over the Internet. The WG
has produced documents that:

- Described a new transport protocol (the Stream Control Transport
Protocol, SCTP)

- Developed adaptation layers for existing tunneling lower-layer
telephone network protocols

- Provided an architecture for migrating telephony signaling into an
Internet Protocol environment

This concludes the working group. The Area Directors would like to thank
Lyndon Ong, the WG chair, and the authors and WG participants. The mailing
list will be kept open indefinitely.

Jon Peterson
Cullen Jennings
RAI Co-ADs

From Samuel_Durairaj.Jeyaseelan@alcatel-lucent.com  Sat Mar 21 14:01:33 2009
Return-Path: <Samuel_Durairaj.Jeyaseelan@alcatel-lucent.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C28753A67E1 for <sigtran@core3.amsl.com>; Sat, 21 Mar 2009 14:01:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnleY9VQgBa1 for <sigtran@core3.amsl.com>; Sat, 21 Mar 2009 14:01:33 -0700 (PDT)
Received: from audl751.usa.alcatel.com (audl751.usa.alcatel.com [143.209.238.164]) by core3.amsl.com (Postfix) with ESMTP id 10A113A6A8E for <sigtran@ietf.org>; Sat, 21 Mar 2009 14:01:32 -0700 (PDT)
Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl751.usa.alcatel.com (ALCANET) with ESMTP id n2LL2JBo014148 for <sigtran@ietf.org>; Sat, 21 Mar 2009 15:02:19 -0600
Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.8]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Sat, 21 Mar 2009 16:02:19 -0500
Received: from USDALSMBS06.ad3.ad.alcatel.com ([172.22.216.33]) by USDALSMBS03.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Sat, 21 Mar 2009 16:02:10 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AA68.4D714841"
Date: Sat, 21 Mar 2009 16:02:10 -0500
Message-ID: <2EB0946A2ECCC34EAEF1CD9A513FEC300110203A@USDALSMBS06.ad3.ad.alcatel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: query on SUA RFC 3868 : Sequence Control
Thread-Index: AcmqaE1ltuTkKGW4TS6V51XQHPdYfg==
From: "JEYASEELAN Samuel Durairaj" <Samuel_Durairaj.Jeyaseelan@alcatel-lucent.com>
To: <sigtran@ietf.org>
X-OriginalArrivalTime: 21 Mar 2009 21:02:10.0915 (UTC) FILETIME=[4D6E1330:01C9AA68]
X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34
X-Mailman-Approved-At: Sun, 22 Mar 2009 09:03:22 -0700
Subject: [Sigtran] query on SUA RFC 3868 : Sequence Control
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Mar 2009 21:01:33 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9AA68.4D714841
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
The CLDT msg mentions the parameter 'Sequence Control' as a  mandatory =
in the rfc, but as per the Q.711, section 6.2.2.2.2 it is an optional =
parameter for the protocol class 0.

So the qtn is, what shall be the value to be stored in the sequence =
control while sending the CLDT to ASP?


Thanks & Regards
Samuel


------_=_NextPart_001_01C9AA68.4D714841
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7651.59">
<TITLE>query on SUA RFC 3868 : Sequence Control</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hi,<BR>
The CLDT msg mentions the parameter 'Sequence Control' as a&nbsp; =
mandatory in the rfc, but as per the Q.711, section 6.2.2.2.2 it is an =
optional parameter for the protocol class 0.<BR>
<BR>
So the qtn is, what shall be the value to be stored in the sequence =
control while sending the CLDT to ASP?<BR>
<BR>
<BR>
Thanks &amp; Regards<BR>
Samuel<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9AA68.4D714841--

From bidulock@openss7.org  Mon Mar 23 05:17:32 2009
Return-Path: <bidulock@openss7.org>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 120203A6AD3 for <sigtran@core3.amsl.com>; Mon, 23 Mar 2009 05:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.466
X-Spam-Level: 
X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIfmZLzH8eFD for <sigtran@core3.amsl.com>; Mon, 23 Mar 2009 05:17:31 -0700 (PDT)
Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 2B4423A6A94 for <sigtran@ietf.org>; Mon, 23 Mar 2009 05:17:30 -0700 (PDT)
Received: from wilbur.pigworks.openss7.net (IDENT:GfbdNrZg/wAnwL2c6PcCZpJ+y44+YvXx@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id n2NCIDJl008936; Mon, 23 Mar 2009 06:18:13 -0600
Received: from wilbur.pigworks.openss7.net (IDENT:E7kDFBJhRw7HUNXDaE7+H6TNxCQH4ZkW@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id n2NCIDkh018244; Mon, 23 Mar 2009 06:18:13 -0600
Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id n2NCIC0B018243; Mon, 23 Mar 2009 06:18:12 -0600
Date: Mon, 23 Mar 2009 06:18:12 -0600
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: JEYASEELAN Samuel Durairaj <Samuel_Durairaj.Jeyaseelan@alcatel-lucent.com>
Message-ID: <20090323121812.GA18031@openss7.org>
Mail-Followup-To: JEYASEELAN Samuel Durairaj <Samuel_Durairaj.Jeyaseelan@alcatel-lucent.com>,  sigtran@ietf.org
References: <2EB0946A2ECCC34EAEF1CD9A513FEC300110203A@USDALSMBS06.ad3.ad.alcatel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2EB0946A2ECCC34EAEF1CD9A513FEC300110203A@USDALSMBS06.ad3.ad.alcatel.com>
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-To: <blockme@openss7.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: sigtran@ietf.org
Subject: Re: [Sigtran] query on SUA RFC 3868 : Sequence Control
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2009 12:17:32 -0000

JEYASEELAN,

RFC 3868 Section 3.10.22 Sequence Control:

3.10.22.  Sequence Control

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag = 0x0116          |             Length = 8        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence  Control         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Sequence Control (6.2.2.2.2/Q.711)

   The field is coded with the value of the sequence control parameter
   associated with a group of messages and are chosen so as to ensure
   proper loadsharing of message groups over SLS values while ensuring
   that sequence control values within message groups have the sequence
   control value coded with the same value as the initial message of the
   message group.


So, pick a value that ensures proper loadsharing over SLS for your
protocol class 0 messages.

--brian


JEYASEELAN Samuel Durairaj wrote:                                               (Sat, 21 Mar 2009 16:02:10)
> 
>    Hi,
>    The CLDT msg mentions the parameter 'Sequence Control' as a  mandatory
>    in the rfc, but as per the Q.711, section 6.2.2.2.2 it is an optional
>    parameter for the protocol class 0.
>    So the qtn is, what shall be the value to be stored in the sequence
>    control while sending the CLDT to ASP?
>    Thanks & Regards
>    Samuel

> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www.ietf.org/mailman/listinfo/sigtran


-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/

From bidulock@openss7.org  Mon Mar 23 08:37:13 2009
Return-Path: <bidulock@openss7.org>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9A5C3A6B22 for <sigtran@core3.amsl.com>; Mon, 23 Mar 2009 08:37:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.473
X-Spam-Level: 
X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDhjbQ-8xf1c for <sigtran@core3.amsl.com>; Mon, 23 Mar 2009 08:37:13 -0700 (PDT)
Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id CE3603A676A for <sigtran@ietf.org>; Mon, 23 Mar 2009 08:37:12 -0700 (PDT)
Received: from wilbur.pigworks.openss7.net (IDENT:d5Jw+Wlk/3RtVjoj+ttQ/1yYdEhK9h+0@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id n2NFbule012633; Mon, 23 Mar 2009 09:37:56 -0600
Received: from wilbur.pigworks.openss7.net (IDENT:CTjwKrcGlVsFq5tO5sggop0SKcC7Mpoq@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id n2NFbuB9026161; Mon, 23 Mar 2009 09:37:56 -0600
Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id n2NFbuqM026160; Mon, 23 Mar 2009 09:37:56 -0600
Date: Mon, 23 Mar 2009 09:37:56 -0600
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: JEYASEELAN Samuel Durairaj <Samuel_Durairaj.Jeyaseelan@alcatel-lucent.com>
Message-ID: <20090323153756.GA26002@openss7.org>
Mail-Followup-To: JEYASEELAN Samuel Durairaj <Samuel_Durairaj.Jeyaseelan@alcatel-lucent.com>,  sigtran@ietf.org
References: <2EB0946A2ECCC34EAEF1CD9A513FEC300110203A@USDALSMBS06.ad3.ad.alcatel.com> <20090323121812.GA18031@openss7.org> <2EB0946A2ECCC34EAEF1CD9A513FEC300110203D@USDALSMBS06.ad3.ad.alcatel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2EB0946A2ECCC34EAEF1CD9A513FEC300110203D@USDALSMBS06.ad3.ad.alcatel.com>
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-To: <blockme@openss7.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: sigtran@ietf.org
Subject: Re: [Sigtran] query on SUA RFC 3868 : Sequence Control
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2009 15:37:13 -0000

JEYASEELAN,

See the thread: SUA v16: sequence control parameter in CLDT msg
from Feb 5, 2004 on the sigtran mailing list archive.

--brian

JEYASEELAN Samuel Durairaj wrote:        (Mon, 23 Mar 2009 09:51:04)
> 
>    Sequence Control is not a valid parameter to protocol class '0' as per
>    the Q.711, section 6.2.2.2.2.
>    But RFC makes this as mandatory parameter for protocol class '0'.
>    Does anyone have a reason why this is a mandatory param in RFC?
>    Thanks & Regards
>    Samuel
>    -----Original Message-----
>    From: Brian F. G. Bidulock [[1]mailto:bidulock@openss7.org]
>    Sent: Mon 3/23/2009 7:18 AM
>    To: JEYASEELAN Samuel Durairaj
>    Cc: sigtran@ietf.org
>    Subject: Re: [Sigtran] query on SUA RFC 3868 : Sequence Control
>    JEYASEELAN,
>    RFC 3868 Section 3.10.22 Sequence Control:
>    3.10.22.  Sequence Control
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |         Tag = 0x0116          |             Length = 8        |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                        Sequence  Control         |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       Sequence Control (6.2.2.2.2/Q.711)
>       The field is coded with the value of the sequence control parameter
>       associated with a group of messages and are chosen so as to ensure
>       proper loadsharing of message groups over SLS values while ensuring
>       that sequence control values within message groups have the
>    sequence
>       control value coded with the same value as the initial message of
>    the
>       message group.
>    So, pick a value that ensures proper loadsharing over SLS for your
>    protocol class 0 messages.
>    --brian
>    JEYASEELAN Samuel Durairaj
>    wrote:                                               (Sat, 21 Mar 2009
>    16:02:10)
>    >
>    >    Hi,
>    >    The CLDT msg mentions the parameter 'Sequence Control' as a
>    mandatory
>    >    in the rfc, but as per the Q.711, section 6.2.2.2.2 it is an
>    optional
>    >    parameter for the protocol class 0.
>    >    So the qtn is, what shall be the value to be stored in the
>    sequence
>    >    control while sending the CLDT to ASP?
>    >    Thanks & Regards
>    >    Samuel
>    > _______________________________________________
>    > Sigtran mailing list
>    > Sigtran@ietf.org
>    > [2]https://www.ietf.org/mailman/listinfo/sigtran
>    --
>    Brian F. G. Bidulock
>    bidulock@openss7.org
>    [3]http://www.openss7.org/
> 
> References
> 
>    1. mailto:bidulock@openss7.org
>    2. https://www.ietf.org/mailman/listinfo/sigtran
>    3. http://www.openss7.org/

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/

From Samuel_Durairaj.Jeyaseelan@alcatel-lucent.com  Mon Mar 23 07:53:19 2009
Return-Path: <Samuel_Durairaj.Jeyaseelan@alcatel-lucent.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5AF13A6835 for <sigtran@core3.amsl.com>; Mon, 23 Mar 2009 07:53:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.298
X-Spam-Level: 
X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwN1IpArmYkX for <sigtran@core3.amsl.com>; Mon, 23 Mar 2009 07:53:18 -0700 (PDT)
Received: from audl951.usa.alcatel.com (audl951.usa.alcatel.com [143.209.238.161]) by core3.amsl.com (Postfix) with ESMTP id 6C32C3A6828 for <sigtran@ietf.org>; Mon, 23 Mar 2009 07:53:17 -0700 (PDT)
Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id n2NEs2gC026558; Mon, 23 Mar 2009 08:54:03 -0600
Received: from USDALSMBS02.ad3.ad.alcatel.com ([172.22.216.9]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 23 Mar 2009 09:54:02 -0500
Received: from USDALSMBS06.ad3.ad.alcatel.com ([172.22.216.33]) by USDALSMBS02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 23 Mar 2009 09:54:02 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9ABC7.3430A501"
Date: Mon, 23 Mar 2009 09:51:04 -0500
Message-ID: <2EB0946A2ECCC34EAEF1CD9A513FEC300110203D@USDALSMBS06.ad3.ad.alcatel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sigtran] query on SUA RFC 3868 : Sequence Control
Thread-Index: AcmrsXTTcbz271KaRxa1PJfOVBDdGQAFVWlW
References: <2EB0946A2ECCC34EAEF1CD9A513FEC300110203A@USDALSMBS06.ad3.ad.alcatel.com> <20090323121812.GA18031@openss7.org>
From: "JEYASEELAN Samuel Durairaj" <Samuel_Durairaj.Jeyaseelan@alcatel-lucent.com>
To: <bidulock@openss7.org>
X-OriginalArrivalTime: 23 Mar 2009 14:54:02.0474 (UTC) FILETIME=[3484F4A0:01C9ABC7]
X-Scanned-By: MIMEDefang 2.64 on 143.209.238.34
X-Mailman-Approved-At: Tue, 24 Mar 2009 17:37:52 -0700
Cc: sigtran@ietf.org
Subject: Re: [Sigtran] query on SUA RFC 3868 : Sequence Control
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2009 14:53:19 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9ABC7.3430A501
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Sequence Control is not a valid parameter to protocol class '0' as per =
the Q.711, section 6.2.2.2.2.
But RFC makes this as mandatory parameter for protocol class '0'.

Does anyone have a reason why this is a mandatory param in RFC?



Thanks & Regards
Samuel



-----Original Message-----
From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]
Sent: Mon 3/23/2009 7:18 AM
To: JEYASEELAN Samuel Durairaj
Cc: sigtran@ietf.org
Subject: Re: [Sigtran] query on SUA RFC 3868 : Sequence Control
=20
JEYASEELAN,

RFC 3868 Section 3.10.22 Sequence Control:

3.10.22.  Sequence Control

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Tag =3D 0x0116          |             Length =3D 8        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence  Control         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Sequence Control (6.2.2.2.2/Q.711)

   The field is coded with the value of the sequence control parameter
   associated with a group of messages and are chosen so as to ensure
   proper loadsharing of message groups over SLS values while ensuring
   that sequence control values within message groups have the sequence
   control value coded with the same value as the initial message of the
   message group.


So, pick a value that ensures proper loadsharing over SLS for your
protocol class 0 messages.

--brian


JEYASEELAN Samuel Durairaj wrote:                                        =
       (Sat, 21 Mar 2009 16:02:10)
>=20
>    Hi,
>    The CLDT msg mentions the parameter 'Sequence Control' as a  =
mandatory
>    in the rfc, but as per the Q.711, section 6.2.2.2.2 it is an =
optional
>    parameter for the protocol class 0.
>    So the qtn is, what shall be the value to be stored in the sequence
>    control while sending the CLDT to ASP?
>    Thanks & Regards
>    Samuel

> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www.ietf.org/mailman/listinfo/sigtran


--=20
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/


------_=_NextPart_001_01C9ABC7.3430A501
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7651.59">
<TITLE>RE: [Sigtran] query on SUA RFC 3868 : Sequence Control</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Sequence Control is not a valid parameter to protocol =
class '0' as per the Q.711, section 6.2.2.2.2.<BR>
But RFC makes this as mandatory parameter for protocol class '0'.<BR>
<BR>
Does anyone have a reason why this is a mandatory param in RFC?<BR>
<BR>
<BR>
<BR>
Thanks &amp; Regards<BR>
Samuel<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Brian F. G. Bidulock [<A =
HREF=3D"mailto:bidulock@openss7.org">mailto:bidulock@openss7.org</A>]<BR>=

Sent: Mon 3/23/2009 7:18 AM<BR>
To: JEYASEELAN Samuel Durairaj<BR>
Cc: sigtran@ietf.org<BR>
Subject: Re: [Sigtran] query on SUA RFC 3868 : Sequence Control<BR>
<BR>
JEYASEELAN,<BR>
<BR>
RFC 3868 Section 3.10.22 Sequence Control:<BR>
<BR>
3.10.22.&nbsp; Sequence Control<BR>
<BR>
&nbsp;&nbsp;&nbsp; =
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3<BR>
&nbsp;&nbsp;&nbsp; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 =
7 8 9 0 1<BR>
&nbsp;&nbsp; =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tag =3D =
0x0116&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Length =3D 8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<BR>
&nbsp;&nbsp; =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>
&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Sequence&nbsp; Control&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|<BR>
&nbsp;&nbsp; =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<BR>
<BR>
&nbsp;&nbsp; Sequence Control (6.2.2.2.2/Q.711)<BR>
<BR>
&nbsp;&nbsp; The field is coded with the value of the sequence control =
parameter<BR>
&nbsp;&nbsp; associated with a group of messages and are chosen so as to =
ensure<BR>
&nbsp;&nbsp; proper loadsharing of message groups over SLS values while =
ensuring<BR>
&nbsp;&nbsp; that sequence control values within message groups have the =
sequence<BR>
&nbsp;&nbsp; control value coded with the same value as the initial =
message of the<BR>
&nbsp;&nbsp; message group.<BR>
<BR>
<BR>
So, pick a value that ensures proper loadsharing over SLS for your<BR>
protocol class 0 messages.<BR>
<BR>
--brian<BR>
<BR>
<BR>
JEYASEELAN Samuel Durairaj =
wrote:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (Sat, 21 =
Mar 2009 16:02:10)<BR>
&gt;<BR>
&gt;&nbsp;&nbsp;&nbsp; Hi,<BR>
&gt;&nbsp;&nbsp;&nbsp; The CLDT msg mentions the parameter 'Sequence =
Control' as a&nbsp; mandatory<BR>
&gt;&nbsp;&nbsp;&nbsp; in the rfc, but as per the Q.711, section =
6.2.2.2.2 it is an optional<BR>
&gt;&nbsp;&nbsp;&nbsp; parameter for the protocol class 0.<BR>
&gt;&nbsp;&nbsp;&nbsp; So the qtn is, what shall be the value to be =
stored in the sequence<BR>
&gt;&nbsp;&nbsp;&nbsp; control while sending the CLDT to ASP?<BR>
&gt;&nbsp;&nbsp;&nbsp; Thanks &amp; Regards<BR>
&gt;&nbsp;&nbsp;&nbsp; Samuel<BR>
<BR>
&gt; _______________________________________________<BR>
&gt; Sigtran mailing list<BR>
&gt; Sigtran@ietf.org<BR>
&gt; <A =
HREF=3D"https://www.ietf.org/mailman/listinfo/sigtran">https://www.ietf.o=
rg/mailman/listinfo/sigtran</A><BR>
<BR>
<BR>
--<BR>
Brian F. G. Bidulock<BR>
bidulock@openss7.org<BR>
<A HREF=3D"http://www.openss7.org/">http://www.openss7.org/</A><BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9ABC7.3430A501--

From moharana_p@yahoo.com  Fri Mar 27 00:06:06 2009
Return-Path: <moharana_p@yahoo.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E384B3A6B8C for <sigtran@core3.amsl.com>; Fri, 27 Mar 2009 00:06:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.662
X-Spam-Level: 
X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_40=-0.185, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXBzAYV66vEL for <sigtran@core3.amsl.com>; Fri, 27 Mar 2009 00:06:06 -0700 (PDT)
Received: from web110515.mail.gq1.yahoo.com (web110515.mail.gq1.yahoo.com [67.195.8.120]) by core3.amsl.com (Postfix) with SMTP id 3EB2B3A6B51 for <sigtran@ietf.org>; Fri, 27 Mar 2009 00:06:06 -0700 (PDT)
Received: (qmail 75320 invoked by uid 60001); 27 Mar 2009 07:07:00 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238137620; bh=Jm6L57UJApChVp+Tu+Fp2KdK1Zv4g3eZkuphQuBy93E=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=DrpdPm3oRoL+SHTA/vccd4cllAYPZ4EydkBbesiU74snw9I2juAb3cw6yEdUxVy3IS2TrD4JNI7QuZpb7oQf792GMQY2ziG/BLkPfuPi0bNp1q5zSlAt+aWmB6nXbpPHWg6jSj+RNl0qMfpcntE3fd18FnvjLamcFqhWKTltIkQ=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=PkioDwKgLvdfi+1gp6bwhVC1GvYknNBvxWvaTd0swZBKiH0CaPrzZ7VbV/G21vJSPSxFdmmSDo06m2Ke5608fQRUy9u3gCW/BVFnyJV4DlR7S5bG6KzzVsR93b1uewbLnyaXhrVuZoeKOsEUMXLnET7kwX868VMw+bhjtXHIYGA=;
Message-ID: <488296.74660.qm@web110515.mail.gq1.yahoo.com>
X-YMail-OSG: fnoPzRAVM1nycpU9ZTCh.jKdOCOZISl47treRd5m6x8Nyv1a8P..XEAi8OYYL_z9UyApsTnf1KpTPxhUggHGoXeZjDnikhLIYAiYd8ztiUVxBvhk8aLjK.3PArhY_JjLLqWaEme3_2jkWpZJUhpYXIlDAPqJQpfNgIpuYaNhPC6cDA--
Received: from [220.227.132.178] by web110515.mail.gq1.yahoo.com via HTTP; Fri, 27 Mar 2009 00:07:00 PDT
X-Mailer: YahooMailClassic/5.1.20 YahooMailWebService/0.7.289.1
Date: Fri, 27 Mar 2009 00:07:00 -0700 (PDT)
From: moharana_p@yahoo.com
To: sigtran <sigtran@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1568446258-1238137620=:74660"
Cc: bidulock <bidulock@openss7.org>
Subject: [Sigtran] Can SCTP client accept INIT ACK from different port.
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 07:06:07 -0000

--0-1568446258-1238137620=:74660
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,
=A0
Is the following call flow is valid one. i mean can client accept INIT ACK =
from different port?
=A0
ENDPOINT A=A0=A0 ---=A0 ENDPOINT B
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- INIT=A0=A0=A0=A0=A0=A0 -->=A0=A0 src port=3D61002=A0=A0 dest port=3D610=
02
<-- INIT ACK=A0=A0 ---=A0=A0 src port=3D7861=A0=A0=A0 dest port=3D61002
--- COOKIE=A0=A0=A0=A0 --->=A0 src port=3D61002=A0=A0 dest port=3D7861
<-- COOKIE ACK ---=A0=A0 src port=3D7861=A0=A0=A0 dest port=3D61002
<-- data=A0=A0=A0=A0=A0=A0 ----=A0 src port=3D7861=A0=A0=A0 dest port=3D610=
02
--- Data=A0=A0=A0=A0=A0=A0 --->=A0 src port=3D61002=A0=A0 dest port=3D7861
=A0
Br,
Padmalochan
=A0=0A=0A=0A      
--0-1568446258-1238137620=:74660
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><DIV>Hello,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Is the following call flow is valid one. i mean can client accept INIT=
 ACK from different port?</DIV>
<DIV>&nbsp;</DIV>
<DIV><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Courier">ENDPOINT A&nbsp;=
&nbsp; ---&nbsp; ENDPOINT B<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D<BR>--- INIT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --&gt;&nbsp;&n=
bsp; src port=3D61002&nbsp;&nbsp; dest port=3D61002<BR>&lt;-- INIT ACK&nbsp=
;&nbsp; ---&nbsp;&nbsp; src port=3D7861&nbsp;&nbsp;&nbsp; dest port=3D61002=
<BR>--- COOKIE&nbsp;&nbsp;&nbsp;&nbsp; ---&gt;&nbsp; src port=3D61002&nbsp;=
&nbsp; dest port=3D7861<BR>&lt;-- COOKIE ACK ---&nbsp;&nbsp; src port=3D786=
1&nbsp;&nbsp;&nbsp; dest port=3D61002<BR>&lt;-- data&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; ----&nbsp; src port=3D7861&nbsp;&nbsp;&nbsp; dest port=3D6100=
2<BR>--- Data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ---&gt;&nbsp; src port=3D=
61002&nbsp;&nbsp; dest port=3D7861</SPAN><o:p></o:p></DIV>
<DIV>&nbsp;</DIV>
<DIV>Br,</DIV>
<DIV>Padmalochan</DIV>
<DIV>&nbsp;</DIV></td></tr></table><br>=0A=0A=0A=0A      
--0-1568446258-1238137620=:74660--

From bidulock@openss7.org  Fri Mar 27 00:15:20 2009
Return-Path: <bidulock@openss7.org>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0F563A6C33; Fri, 27 Mar 2009 00:15:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.479
X-Spam-Level: 
X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1t7qDgAZfcy; Fri, 27 Mar 2009 00:15:20 -0700 (PDT)
Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id E008D3A6C2E; Fri, 27 Mar 2009 00:15:19 -0700 (PDT)
Received: from wilbur.pigworks.openss7.net (IDENT:PubDunFxVOR3YA4j/o5V5w4/pCWWVHqO@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id n2R7GC1c003660; Fri, 27 Mar 2009 01:16:12 -0600
Received: from wilbur.pigworks.openss7.net (IDENT:yycvVIIoy4TQNr0rlu0GJXb04EiVOCxT@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id n2R7GCp0025988; Fri, 27 Mar 2009 01:16:12 -0600
Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id n2R7GCaN025986; Fri, 27 Mar 2009 01:16:12 -0600
Date: Fri, 27 Mar 2009 01:16:12 -0600
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: moharana_p@yahoo.com
Message-ID: <20090327071612.GA25728@openss7.org>
Mail-Followup-To: moharana_p@yahoo.com, sigtran <sigtran@ietf.org>, tsv <tsvwg@ietf.org>
References: <488296.74660.qm@web110515.mail.gq1.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <488296.74660.qm@web110515.mail.gq1.yahoo.com>
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-To: <blockme@openss7.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: sigtran <sigtran@ietf.org>, tsv <tsvwg@ietf.org>
Subject: Re: [Sigtran] Can SCTP client accept INIT ACK from different port.
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 07:15:21 -0000

moharana_p,

Please ask SCTP questions on tsvwg@ietf.org

--brian

moharana_p@yahoo.com wrote:              (Fri, 27 Mar 2009 00:07:00)
> 
>    Hello,
> 
>    Is the following call flow is valid one. i mean can client accept INIT
>    ACK from different port?
> 
>    ENDPOINT A   ---  ENDPOINT B
>    ===========================================
>    --- INIT       -->   src port=61002   dest port=61002
>    <-- INIT ACK   ---   src port=7861    dest port=61002
>    --- COOKIE     --->  src port=61002   dest port=7861
>    <-- COOKIE ACK ---   src port=7861    dest port=61002
>    <-- data       ----  src port=7861    dest port=61002
>    --- Data       --->  src port=61002   dest port=7861
> 
>    Br,
>    Padmalochan

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/

From srinu5659@gmail.com  Fri Mar 27 05:13:39 2009
Return-Path: <srinu5659@gmail.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37E683A6922 for <sigtran@core3.amsl.com>; Fri, 27 Mar 2009 05:13:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuAaoTWKrBNh for <sigtran@core3.amsl.com>; Fri, 27 Mar 2009 05:13:38 -0700 (PDT)
Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by core3.amsl.com (Postfix) with ESMTP id 350CF3A68F5 for <Sigtran@ietf.org>; Fri, 27 Mar 2009 05:13:37 -0700 (PDT)
Received: by ti-out-0910.google.com with SMTP id j3so687522tid.25 for <Sigtran@ietf.org>; Fri, 27 Mar 2009 05:14:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=8WmEXhrSPwGNfVWkooaJUNBg3erIsVDCEBeSjVlW1Io=; b=P0vPt2vuXZmSemdSnJkDazzacXX7Y9Mmfcti6kFZ8eBdAKOEi1p04bcMeGH2986eFS bMHg9CUojJjSHYYA7GTV6SFfh1aaci4fGPD3Qc++Ha+l2xi++63MAsLbUBuYIjcaeW+n QrbsndrqtSzGcVnXeBqC52O20Gr98rTHAXOGQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=yG9icv62vWQDLlKSAqJrmQTh+F+Fb2LA2Cn/27atYUY7Gj1Rma0wIglONJXQT2TEJU WcbqBYDpv5fXH7DCaNMVJfSzU1LTcoiquiA6N/RuNegFN4be070BBtF5DWaq/icl/c2H xatHKsMkAysc3G7VezgPWJh0aD+Bj29LLArO0=
MIME-Version: 1.0
Received: by 10.110.53.19 with SMTP id b19mr571657tia.16.1238156070909; Fri,  27 Mar 2009 05:14:30 -0700 (PDT)
In-Reply-To: <8a9964270903270235y3855c2daj941f75f560490206@mail.gmail.com>
References: <8a9964270903270235y3855c2daj941f75f560490206@mail.gmail.com>
Date: Fri, 27 Mar 2009 17:44:30 +0530
Message-ID: <8a9964270903270514r847ca0bn2adf02b342671e9a@mail.gmail.com>
From: srinivas varakala <srinu5659@gmail.com>
To: Sigtran@ietf.org
Content-Type: multipart/alternative; boundary=001485f02570c9d365046618acde
Subject: [Sigtran] Sigtran Links
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 12:13:39 -0000

--001485f02570c9d365046618acde
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi,

   As i have small problem we have applied M3ua, TCAP, MAP SCCP licenses we
are able to see ASSUP and Link is active in our server and we can run our
application and by defining SSNs we can are able to quesy HLR but as problem
i am facing is that Switch engineers are saying that they are getting some
aarams at there switch side as M3UA DESTINATION INACCESSIBLE but when we
check in our server we are seeing that links are up by tracing the routes by
wireshark we see that HeartBeat and HartBeat ACKNOWLDMENT.

For your reference please find the attachment sent by the switch engineers.

Request you to pleae reply soon
.


Thanks & Regards
Srinivas Varakala
Pyro Networks.



-- 
Thanks & Regards
Srinivas Varakala
Pyro Networks.

--001485f02570c9d365046618acde
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote"><span dir=3D"ltr"></span><br><br><br><br cle=
ar=3D"all">Hi,<br><br>=A0=A0 As i have small problem we have applied M3ua, =
TCAP, MAP SCCP licenses we are able to see ASSUP and Link is active in our =
server and we can run our application and by defining SSNs we can are able =
to quesy HLR but as problem i am facing is that Switch engineers are saying=
 that they are getting some aarams at there switch side as M3UA DESTINATION=
 INACCESSIBLE but when we check in our server we are seeing that links are =
up by tracing the routes by wireshark we see that HeartBeat and HartBeat AC=
KNOWLDMENT.<br>

<br>For your reference please find the attachment sent by the switch engine=
ers.<br><br>Request you to pleae reply soon<br>.<br><br><br>Thanks &amp; Re=
gards<br><font color=3D"#888888">Srinivas Varakala<br>Pyro Networks.<br>

</font></div><br><br clear=3D"all"><br>-- <br>Thanks &amp; Regards<br>Srini=
vas Varakala<br>Pyro Networks.<br>

--001485f02570c9d365046618acde--

From srinu5659@gmail.com  Fri Mar 27 05:18:14 2009
Return-Path: <srinu5659@gmail.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B72FC28C118 for <sigtran@core3.amsl.com>; Fri, 27 Mar 2009 05:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.073
X-Spam-Level: 
X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1lFvZrvk5rf for <sigtran@core3.amsl.com>; Fri, 27 Mar 2009 05:18:14 -0700 (PDT)
Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by core3.amsl.com (Postfix) with ESMTP id 9F4F73A6A4B for <Sigtran@ietf.org>; Fri, 27 Mar 2009 05:18:13 -0700 (PDT)
Received: by ti-out-0910.google.com with SMTP id j3so688971tid.25 for <Sigtran@ietf.org>; Fri, 27 Mar 2009 05:19:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=KLPNcQBf5PZ0WDo83/dDj6tK3QX/J8UYXohWS78Nx5I=; b=bvt5SDBHki6CvkaN9QN6dYZrS2ru02wFSqe9wF6uzIsJ6j6/IxwVflzwObiIULVnxK vXVmRH0dS+4s4EXPTVEUbwfvgXpEvLVd3cJz+hYMu0kZ9IWAuriC3ge6cBBVepvA6lkN 2CMXZKS8CnvJqhkKIINdjS0Wkab47roTKRWfE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=AuaW7TaQX12uz9KKJenVXgjp4BMJF6D1wUu3D/JIv0vjAZdhE13YLGwHXXfpSvFa7a tButXA+gaT4H507P1U87PHa55wSBMUbvU/LrZwoc1tIBNkikv+jADeYMsfBs0LAkpDDO gQHO0kUrn3k665T7zVUUwvGqLPAhe09QeVYGQ=
MIME-Version: 1.0
Received: by 10.110.46.3 with SMTP id t3mr2843480tit.20.1238156347280; Fri, 27  Mar 2009 05:19:07 -0700 (PDT)
In-Reply-To: <8a9964270903270235y3855c2daj941f75f560490206@mail.gmail.com>
References: <8a9964270903270235y3855c2daj941f75f560490206@mail.gmail.com>
Date: Fri, 27 Mar 2009 17:49:07 +0530
Message-ID: <8a9964270903270519i4e529bfcrecb7e9d5e0bfa99d@mail.gmail.com>
From: srinivas varakala <srinu5659@gmail.com>
To: Sigtran@ietf.org
Content-Type: multipart/alternative; boundary=0016e652fe30418c76046618bd6f
Subject: [Sigtran] Fwd: Sigtran Links
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 12:18:14 -0000

--0016e652fe30418c76046618bd6f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

---------- Forwarded message ----------
From: srinivas varakala <srinu5659@gmail.com>
Date: Fri, Mar 27, 2009 at 3:05 PM
Subject: Sigtran Links
To: Sigtran@ietf.org



Hi,

   As i have small problem we have applied M3ua, TCAP, MAP SCCP licenses we
are able to see ASSUP and Link is active in our server and we can run our
application and by defining SSNs we can are able to quesy HLR but as problem
i am facing is that Switch engineers are saying that they are getting some
aarams at there switch side as M3UA DESTINATION INACCESSIBLE but when we
check in our server we are seeing that links are up by tracing the routes by
wireshark we see that HeartBeat and HartBeat ACKNOWLDMENT.

For your reference please find the attachment sent by the switch engineers.

Request you to pleae reply soon
.


Thanks & Regards
Srinivas Varakala
Pyro Networks.



-- 
Thanks & Regards
Srinivas Varakala
Pyro Networks.

--0016e652fe30418c76046618bd6f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">---------- Forwarded message ----------<=
br>From: <b class=3D"gmail_sendername">srinivas varakala</b> <span dir=3D"l=
tr">&lt;<a href=3D"mailto:srinu5659@gmail.com">srinu5659@gmail.com</a>&gt;<=
/span><br>
Date: Fri, Mar 27, 2009 at 3:05 PM<br>Subject: Sigtran Links<br>To: <a href=
=3D"mailto:Sigtran@ietf.org">Sigtran@ietf.org</a><br><br><br><br clear=3D"a=
ll">Hi,<br><br>=A0=A0 As i have small problem we have applied M3ua, TCAP, M=
AP SCCP licenses we are able to see ASSUP and Link is active in our server =
and we can run our application and by defining SSNs we can are able to ques=
y HLR but as problem i am facing is that Switch engineers are saying that t=
hey are getting some aarams at there switch side as M3UA DESTINATION INACCE=
SSIBLE but when we check in our server we are seeing that links are up by t=
racing the routes by wireshark we see that HeartBeat and HartBeat ACKNOWLDM=
ENT.<br>

<br>For your reference please find the attachment sent by the switch engine=
ers.<br><br>Request you to pleae reply soon<br>.<br><br><br>Thanks &amp; Re=
gards<br><font color=3D"#888888">Srinivas Varakala<br>Pyro Networks.<br>

</font></div><br><br clear=3D"all"><br>-- <br>Thanks &amp; Regards<br>Srini=
vas Varakala<br>Pyro Networks.<br>

--0016e652fe30418c76046618bd6f--

From adi.aquarian@gmail.com  Fri Mar 27 07:21:01 2009
Return-Path: <adi.aquarian@gmail.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635A728C167 for <sigtran@core3.amsl.com>; Fri, 27 Mar 2009 07:21:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OftyObE5KXaj for <sigtran@core3.amsl.com>; Fri, 27 Mar 2009 07:21:00 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 8898B3A6BA3 for <Sigtran@ietf.org>; Fri, 27 Mar 2009 07:21:00 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 24so1338534wfg.31 for <Sigtran@ietf.org>; Fri, 27 Mar 2009 07:21:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/uMPHf+nTbIjplO/MJoNnKm+HmNrIh97hg0YKDOu5uY=; b=QnmuwP3tfzprmnk0/i/+1rkJe+yuFGZ54rWrxHvgf7GgKVQusfh6hcvmWcoGrzWTsD PdElXDWXOqlFfxIsI/3tLBPF4rpkjA8nKGV5s168Mm1WOj0Jx+npjTQdQ8Ixfoujmr1p yCPSl5tsnRlFV8t6mam+8kNdsk/IlMEIyZS5A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WaFJzZFMWzLIBDMUH905rt5sD6x8PV+/og4yHj46vxPuQgLhCl8aApcwh1mA7QB93Y 3wWRihsnlGt6GrCQLauf7PVYJOfYPJZXnoltMcJ5wa4apnoX8J6JyjHrskFVFlfL1DGl +maYeA8hXOCHlK/EaiLqf2/XGHHmRzDJiVsVg=
MIME-Version: 1.0
Received: by 10.142.12.14 with SMTP id 14mr929880wfl.54.1238163715224; Fri, 27  Mar 2009 07:21:55 -0700 (PDT)
In-Reply-To: <8a9964270903270514r847ca0bn2adf02b342671e9a@mail.gmail.com>
References: <8a9964270903270235y3855c2daj941f75f560490206@mail.gmail.com> <8a9964270903270514r847ca0bn2adf02b342671e9a@mail.gmail.com>
Date: Fri, 27 Mar 2009 19:51:55 +0530
Message-ID: <1ac609990903270721t17fce41fs972ddd54dd7c341e@mail.gmail.com>
From: Aditya Sehgal <adi.aquarian@gmail.com>
To: srinivas varakala <srinu5659@gmail.com>
Content-Type: multipart/alternative; boundary=000e0cd2e2d26b769104661a74dc
Cc: Sigtran@ietf.org
Subject: Re: [Sigtran] Sigtran Links
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 14:21:01 -0000

--000e0cd2e2d26b769104661a74dc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Srinivas,
Its not possible to answer your query without more information (type of
configuration for starters, a wireshark trace etc). However, ASPUP does not
specify that the destination is up. Kindly check on the wireshark trace
whether a subsequent ASPAC (ASP Active) messages were exchanged between the
two nodes.
HeartBEAT/HEARTBEAT-ACK just denotes that the Association is up (at SCTP
level) and not necessairly that the "destination" is up and active.

Thanks & Regards,
Aditya Sehgal

2009/3/27 srinivas varakala <srinu5659@gmail.com>

>
>
>
>
>
> Hi,
>
>    As i have small problem we have applied M3ua, TCAP, MAP SCCP licenses we
> are able to see ASSUP and Link is active in our server and we can run our
> application and by defining SSNs we can are able to quesy HLR but as problem
> i am facing is that Switch engineers are saying that they are getting some
> aarams at there switch side as M3UA DESTINATION INACCESSIBLE but when we
> check in our server we are seeing that links are up by tracing the routes by
> wireshark we see that HeartBeat and HartBeat ACKNOWLDMENT.
>
> For your reference please find the attachment sent by the switch engineers.
>
> Request you to pleae reply soon
> .
>
>
> Thanks & Regards
> Srinivas Varakala
> Pyro Networks.
>
>
>
> --
> Thanks & Regards
> Srinivas Varakala
> Pyro Networks.
>
> _______________________________________________
> Sigtran mailing list
> Sigtran@ietf.org
> https://www.ietf.org/mailman/listinfo/sigtran
>
>


-- 
There are only 10 type of people in this World...Those who understand binary
and those who dont

--000e0cd2e2d26b769104661a74dc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Srinivas,<br>Its not possible to answer your query without more informat=
ion (type of configuration for starters, a wireshark trace etc). However, A=
SPUP does not specify that the destination is up. Kindly check on the wires=
hark trace whether a subsequent ASPAC (ASP Active) messages were exchanged =
between the two nodes. <br>
HeartBEAT/HEARTBEAT-ACK just denotes that the Association is up (at SCTP le=
vel) and not necessairly that the &quot;destination&quot; is up and active.=
<br><br>Thanks &amp; Regards,<br>Aditya Sehgal <br><br><div class=3D"gmail_=
quote">
2009/3/27 srinivas varakala <span dir=3D"ltr">&lt;<a href=3D"mailto:srinu56=
59@gmail.com">srinu5659@gmail.com</a>&gt;</span><br><blockquote class=3D"gm=
ail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt =
0pt 0pt 0.8ex; padding-left: 1ex;">
<br><div class=3D"gmail_quote"><span dir=3D"ltr"></span><br><br><br><br cle=
ar=3D"all">Hi,<br><br>=A0=A0 As i have small problem we have applied M3ua, =
TCAP, MAP SCCP licenses we are able to see ASSUP and Link is active in our =
server and we can run our application and by defining SSNs we can are able =
to quesy HLR but as problem i am facing is that Switch engineers are saying=
 that they are getting some aarams at there switch side as M3UA DESTINATION=
 INACCESSIBLE but when we check in our server we are seeing that links are =
up by tracing the routes by wireshark we see that HeartBeat and HartBeat AC=
KNOWLDMENT.<br>


<br>For your reference please find the attachment sent by the switch engine=
ers.<br><br>Request you to pleae reply soon<br>.<br><br><br>Thanks &amp; Re=
gards<br><font color=3D"#888888">Srinivas Varakala<br>Pyro Networks.<br>


</font></div><br><br clear=3D"all"><br>-- <br>Thanks &amp; Regards<br>Srini=
vas Varakala<br>Pyro Networks.<br>
<br>_______________________________________________<br>
Sigtran mailing list<br>
<a href=3D"mailto:Sigtran@ietf.org">Sigtran@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sigtran" target=3D"_blank"=
>https://www.ietf.org/mailman/listinfo/sigtran</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br>There are only 10 t=
ype of people in this World...Those who understand binary and those who don=
t<br>

--000e0cd2e2d26b769104661a74dc--

From srinu5659@gmail.com  Fri Mar 27 02:35:02 2009
Return-Path: <srinu5659@gmail.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C39F3A69AF for <sigtran@core3.amsl.com>; Fri, 27 Mar 2009 02:35:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5EHyo64qb3N for <sigtran@core3.amsl.com>; Fri, 27 Mar 2009 02:35:01 -0700 (PDT)
Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by core3.amsl.com (Postfix) with ESMTP id 0C6853A6825 for <Sigtran@ietf.org>; Fri, 27 Mar 2009 02:34:57 -0700 (PDT)
Received: by ti-out-0910.google.com with SMTP id j3so620246tid.25 for <Sigtran@ietf.org>; Fri, 27 Mar 2009 02:35:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Exvyi2JtissN9UGg/gCh/bxBBpgEWmP3RoGOMykuqlE=; b=R2HDK/YzaatJSKY/QKEHm/CUETdG4f6clNgKQgTgphL4kOC/yDrOfIxZliM5XgU3di DKIKNIJy1xI5tuQdX0+EAt0ZCO4S+lIBBwQL3qKOcYftIjgcU+ueku/flfOrhOg7u3kd qoFkFV50kG+jHhDjmXB3CpVs9Z2E9oDI47MW8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=u2ciUVfCAlF71IwFghwEsK2cfRzVEVvYetkuF63+z0zCaTo/DGF9IkE8jy6zxX0Xxs Z+tl3La8z81u9GRqj5uUFbce7G6j0PSwIvVTjimHFVy8YocDIzfafz1ZEHV85QwxyTO4 +cBAFPprURnAQ6nIGzz67a8SFG8XlGZIw+kUk=
MIME-Version: 1.0
Received: by 10.110.16.15 with SMTP id 15mr2589172tip.53.1238146551489; Fri,  27 Mar 2009 02:35:51 -0700 (PDT)
Date: Fri, 27 Mar 2009 15:05:51 +0530
Message-ID: <8a9964270903270235y3855c2daj941f75f560490206@mail.gmail.com>
From: srinivas varakala <srinu5659@gmail.com>
To: Sigtran@ietf.org
Content-Type: multipart/alternative; boundary=0016e6513cb061a4eb0466167512
X-Mailman-Approved-At: Fri, 27 Mar 2009 08:29:44 -0700
Subject: [Sigtran] Sigtran Links
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2009 09:39:16 -0000

--0016e6513cb061a4eb0466167512
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi,

   As i have small problem we have applied M3ua, TCAP, MAP SCCP licenses we
are able to see ASSUP and Link is active in our server and we can run our
application and by defining SSNs we can are able to quesy HLR but as problem
i am facing is that Switch engineers are saying that they are getting some
aarams at there switch side as M3UA DESTINATION INACCESSIBLE but when we
check in our server we are seeing that links are up by tracing the routes by
wireshark we see that HeartBeat and HartBeat ACKNOWLDMENT.

For your reference please find the attachment sent by the switch engineers.

Request you to pleae reply soon
.


Thanks & Regards
Srinivas Varakala
Pyro Networks.

--0016e6513cb061a4eb0466167512
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br clear=3D"all">Hi,<br><br>=A0=A0 As i have small problem we have applied=
 M3ua, TCAP, MAP SCCP licenses we are able to see ASSUP and Link is active =
in our server and we can run our application and by defining SSNs we can ar=
e able to quesy HLR but as problem i am facing is that Switch engineers are=
 saying that they are getting some aarams at there switch side as M3UA DEST=
INATION INACCESSIBLE but when we check in our server we are seeing that lin=
ks are up by tracing the routes by wireshark we see that HeartBeat and Hart=
Beat ACKNOWLDMENT.<br>
<br>For your reference please find the attachment sent by the switch engine=
ers.<br><br>Request you to pleae reply soon<br>.<br><br><br>Thanks &amp; Re=
gards<br>Srinivas Varakala<br>Pyro Networks.<br>

--0016e6513cb061a4eb0466167512--

From adi.aquarian@gmail.com  Sat Mar 28 19:58:10 2009
Return-Path: <adi.aquarian@gmail.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53963A68D4 for <sigtran@core3.amsl.com>; Sat, 28 Mar 2009 19:58:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbAgeqx8jsZj for <sigtran@core3.amsl.com>; Sat, 28 Mar 2009 19:58:09 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id ABEC63A67F5 for <Sigtran@ietf.org>; Sat, 28 Mar 2009 19:58:09 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id k40so1595472rvb.49 for <Sigtran@ietf.org>; Sat, 28 Mar 2009 19:59:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=C+13kvj5l5rW1t+VZbYRAuB1GpHgULBMrDFqmj1DWbw=; b=lZDbpIh5q7k98Rsfi+sVrZageaiG0D8NvDMpNbZFPJIljE+ynt8TxVrz23OoAlZw+r ZjeMLDTy2DQIIZrljwDYEbKIh6OGcwdZcL3x62Ucj39cgWX0JE3D0OG+G5Ees5dcJxr2 si5g4T8ox3EWQtb6F0nUflTWkH8xXoacXR9UM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Qcnr+eyytyIBG/8HXe2KmOFjI6CeXke6Tpdm9jkmGnNvhCXxsZhFru4jfSoawb3/wN a5y/GGU+JsqLgL6wAG4rS8ZQGeWrMP23HV4Yqq54bwnnsXtju7wAZ+zsLKJVhRV0VHU6 NYIlpp86dqmAcO9/q860IIj9jU/05XoKofreA=
MIME-Version: 1.0
Received: by 10.143.42.6 with SMTP id u6mr1552920wfj.121.1238295546105; Sat,  28 Mar 2009 19:59:06 -0700 (PDT)
In-Reply-To: <8a9964270903270842u3b1107fbn290bd24ac77cf192@mail.gmail.com>
References: <8a9964270903270235y3855c2daj941f75f560490206@mail.gmail.com> <8a9964270903270514r847ca0bn2adf02b342671e9a@mail.gmail.com> <1ac609990903270721t17fce41fs972ddd54dd7c341e@mail.gmail.com> <8a9964270903270842u3b1107fbn290bd24ac77cf192@mail.gmail.com>
Date: Sun, 29 Mar 2009 08:29:06 +0530
Message-ID: <1ac609990903281959i495209cbh4757188121521040@mail.gmail.com>
From: Aditya Sehgal <adi.aquarian@gmail.com>
To: srinivas varakala <srinu5659@gmail.com>
Content-Type: multipart/alternative; boundary=001636e8fef427109e04663926da
Cc: Sigtran@ietf.org
Subject: Re: [Sigtran] Sigtran Links
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Mar 2009 02:58:11 -0000

--001636e8fef427109e04663926da
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Srinivas,
I see no problem in the Wireshark trace that you have given me. Although,
the trace does not have M3UA Activation messages (ASPUP/ASPAC), I can see
GSM Invokes initiated from PC 131 (IP .90) to PC 400 (IP .66) which gets
replied to from .66. This basically means that the Destination is Active on
both sides.

The Alarm logs that you have sent have the last alarm logged at 2009-03-26,
13:05:00 whereas the wireshark trace shows messages from the next day (it
could be possible that we are in different time zones and that is why
wireshark shows different times). In any case, all the alarms seemed to be
in state "ceased". Is the switch engineer complaining about lost traffic or
just the alarms.

Thanks & Regards,
Aditya Sehgal

The ala

On Fri, Mar 27, 2009 at 9:12 PM, srinivas varakala <srinu5659@gmail.com>wrote:

> Hi Aditya
>
>    Please  find the attached file containing the GCT load out put and trace
> for the same and the alarm sheet sent by switch engineer.
> Please look in to this and help me out as i am fresher.
>
> Thanks & Regards
>  Srinivas Varakala
>
> On Fri, Mar 27, 2009 at 7:51 PM, Aditya Sehgal <adi.aquarian@gmail.com>wrote:
>
>> Hi Srinivas,
>> Its not possible to answer your query without more information (type of
>> configuration for starters, a wireshark trace etc). However, ASPUP does not
>> specify that the destination is up. Kindly check on the wireshark trace
>> whether a subsequent ASPAC (ASP Active) messages were exchanged between the
>> two nodes.
>> HeartBEAT/HEARTBEAT-ACK just denotes that the Association is up (at SCTP
>> level) and not necessairly that the "destination" is up and active.
>>
>> Thanks & Regards,
>> Aditya Sehgal
>>
>> 2009/3/27 srinivas varakala <srinu5659@gmail.com>
>>
>>>
>>>
>>>
>>>
>>>
>>> Hi,
>>>
>>>    As i have small problem we have applied M3ua, TCAP, MAP SCCP licenses
>>> we are able to see ASSUP and Link is active in our server and we can run our
>>> application and by defining SSNs we can are able to quesy HLR but as problem
>>> i am facing is that Switch engineers are saying that they are getting some
>>> aarams at there switch side as M3UA DESTINATION INACCESSIBLE but when we
>>> check in our server we are seeing that links are up by tracing the routes by
>>> wireshark we see that HeartBeat and HartBeat ACKNOWLDMENT.
>>>
>>> For your reference please find the attachment sent by the switch
>>> engineers.
>>>
>>> Request you to pleae reply soon
>>> .
>>>
>>>
>>> Thanks & Regards
>>> Srinivas Varakala
>>> Pyro Networks.
>>>
>>>
>>>
>>> --
>>> Thanks & Regards
>>> Srinivas Varakala
>>> Pyro Networks.
>>>
>>> _______________________________________________
>>> Sigtran mailing list
>>> Sigtran@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sigtran
>>>
>>>
>>
>>
>> --
>> There are only 10 type of people in this World...Those who understand
>> binary and those who dont
>>
>
>
>
> --
> Thanks & Regards
> Srinivas Varakala
> Pyro Networks.
>



-- 
There are only 10 type of people in this World...Those who understand binary
and those who dont
Sent from: Bangalore KA India.

--001636e8fef427109e04663926da
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Srinivas,<br>I see no problem in the Wireshark trace that you have given=
 me. Although, the trace does not have M3UA Activation messages (ASPUP/ASPA=
C), I can see GSM Invokes initiated from PC 131 (IP .90) to PC 400 (IP .66)=
 which gets replied to from .66. This basically means that the Destination =
is Active on both sides.<br>
<br>The Alarm logs that you have sent have the last alarm logged at 2009-03=
-26, 13:05:00 whereas the wireshark trace shows messages from the next day =
(it could be possible that we are in different time zones and that is why w=
ireshark shows different times). In any case, all the alarms seemed to be i=
n state &quot;ceased&quot;. Is the switch engineer complaining about lost t=
raffic or just the alarms. <br>
<br>Thanks &amp; Regards,<br>Aditya Sehgal<br>
<br>The ala <br><br><div class=3D"gmail_quote">On Fri, Mar 27, 2009 at 9:12=
 PM, srinivas varakala <span dir=3D"ltr">&lt;<a href=3D"mailto:srinu5659@gm=
ail.com" target=3D"_blank">srinu5659@gmail.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204=
, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Hi Aditya<br><br>=A0=A0 Please=A0 find the attached file containing the GCT=
 load out put and trace for the same and the alarm sheet sent by switch eng=
ineer.<br>Please look in to this and help me out as i am fresher.<br><br>Th=
anks &amp; Regards<br>

<font color=3D"#888888">
Srinivas Varakala <br></font><div><div></div><div><br><div class=3D"gmail_q=
uote">On Fri, Mar 27, 2009 at 7:51 PM, Aditya Sehgal <span dir=3D"ltr">&lt;=
<a href=3D"mailto:adi.aquarian@gmail.com" target=3D"_blank">adi.aquarian@gm=
ail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Srinivas,<br>Its not possible to answer your query without more informat=
ion (type of configuration for starters, a wireshark trace etc). However, A=
SPUP does not specify that the destination is up. Kindly check on the wires=
hark trace whether a subsequent ASPAC (ASP Active) messages were exchanged =
between the two nodes. <br>



HeartBEAT/HEARTBEAT-ACK just denotes that the Association is up (at SCTP le=
vel) and not necessairly that the &quot;destination&quot; is up and active.=
<br><br>Thanks &amp; Regards,<br>Aditya Sehgal <br><br><div class=3D"gmail_=
quote">



2009/3/27 srinivas varakala <span dir=3D"ltr">&lt;<a href=3D"mailto:srinu56=
59@gmail.com" target=3D"_blank">srinu5659@gmail.com</a>&gt;</span><br><bloc=
kquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, =
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


<div><div></div><div>
<br><div class=3D"gmail_quote"><span dir=3D"ltr"></span><br><br><br><br cle=
ar=3D"all">Hi,<br><br>=A0=A0 As i have small problem we have applied M3ua, =
TCAP, MAP SCCP licenses we are able to see ASSUP and Link is active in our =
server and we can run our application and by defining SSNs we can are able =
to quesy HLR but as problem i am facing is that Switch engineers are saying=
 that they are getting some aarams at there switch side as M3UA DESTINATION=
 INACCESSIBLE but when we check in our server we are seeing that links are =
up by tracing the routes by wireshark we see that HeartBeat and HartBeat AC=
KNOWLDMENT.<br>





<br>For your reference please find the attachment sent by the switch engine=
ers.<br><br>Request you to pleae reply soon<br>.<br><br><br>Thanks &amp; Re=
gards<br><font color=3D"#888888">Srinivas Varakala<br>Pyro Networks.<br>





</font></div><br><br clear=3D"all"><br>-- <br>Thanks &amp; Regards<br>Srini=
vas Varakala<br>Pyro Networks.<br>
<br></div></div>_______________________________________________<br>
Sigtran mailing list<br>
<a href=3D"mailto:Sigtran@ietf.org" target=3D"_blank">Sigtran@ietf.org</a><=
br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sigtran" target=3D"_blank"=
>https://www.ietf.org/mailman/listinfo/sigtran</a><br>
<br></blockquote></div><font color=3D"#888888"><br><br clear=3D"all"><br>--=
 <br>There are only 10 type of people in this World...Those who understand =
binary and those who dont<br>
</font></blockquote></div><br><br clear=3D"all"><br></div></div>-- <br><div=
><div></div><div>Thanks &amp; Regards<br>Srinivas Varakala<br>Pyro Networks=
.<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>There are o=
nly 10 type of people in this World...Those who understand binary and those=
 who dont<br>Sent from: Bangalore KA India.

--001636e8fef427109e04663926da--

From srinu5659@gmail.com  Sun Mar 29 01:15:35 2009
Return-Path: <srinu5659@gmail.com>
X-Original-To: sigtran@core3.amsl.com
Delivered-To: sigtran@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6573A680C for <sigtran@core3.amsl.com>; Sun, 29 Mar 2009 01:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.058
X-Spam-Level: 
X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZVp2To1O8rN for <sigtran@core3.amsl.com>; Sun, 29 Mar 2009 01:15:34 -0700 (PDT)
Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by core3.amsl.com (Postfix) with ESMTP id AC4743A677C for <Sigtran@ietf.org>; Sun, 29 Mar 2009 01:15:33 -0700 (PDT)
Received: by ti-out-0910.google.com with SMTP id j3so1160760tid.25 for <Sigtran@ietf.org>; Sun, 29 Mar 2009 01:16:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ZI85O+EYGUC/CraIcII6KIK14+tFLMjS06EkTcJFqSg=; b=lVN5n/a5Kd+hmcpE/5GSE2V50lhay8PDZCfShPtCM5HGn08+/yo27XaFsP286P7nzE 2Bb7WpEufZbJ/ycnJdf0ubez3jfOdFVNX0KJ6BY/ZjpIFyzFDRmXPku6jKjAnHWTEIQh jc2Na2sB0xfDVzXDCOK5caGUryn0JaWAFmC2c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=X7yPfPExmIHbK6aFD82l3B7mq8Xk1oxJwADGs5b5YoGOmf0bYYhybzHj4KlX+TErcx 4ZTP+nG1sOyXJk7CKfXN9tvtP0v7qMHVFVJhLIPmkwEU+1Y82Jd5LiyXYKNtZ/0Ibdwo Fek04K/B2OrRZOqmFkpw4ffIY0s63OUwvRuyQ=
MIME-Version: 1.0
Received: by 10.110.14.12 with SMTP id 12mr6237035tin.15.1238314589669; Sun,  29 Mar 2009 01:16:29 -0700 (PDT)
In-Reply-To: <1ac609990903281959i495209cbh4757188121521040@mail.gmail.com>
References: <8a9964270903270235y3855c2daj941f75f560490206@mail.gmail.com> <8a9964270903270514r847ca0bn2adf02b342671e9a@mail.gmail.com> <1ac609990903270721t17fce41fs972ddd54dd7c341e@mail.gmail.com> <8a9964270903270842u3b1107fbn290bd24ac77cf192@mail.gmail.com> <1ac609990903281959i495209cbh4757188121521040@mail.gmail.com>
Date: Sun, 29 Mar 2009 13:46:29 +0530
Message-ID: <8a9964270903290116h7d72bb88se0166757623f5ab7@mail.gmail.com>
From: srinivas varakala <srinu5659@gmail.com>
To: Aditya Sehgal <adi.aquarian@gmail.com>
Content-Type: multipart/alternative; boundary=0016e652ff9a3ccbaa04663d95d2
Cc: Sigtran@ietf.org
Subject: Re: [Sigtran] Sigtran Links
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sigtran>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Mar 2009 08:15:35 -0000

--0016e652ff9a3ccbaa04663d95d2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Aditya,

 Thanks for reply.

I have taken this trace next day after starting gctload at time of starting
gctload i have not taken tarce.Once the switch engineer sent this alarms i
have started taken trace.I have restarted the server at 1:48 PM on 24/03/09
but i see some alarams at 3:29PM and 4:58PM on 24/03/09 as M3UA DESITINATION
INACCESSIBLE but when i check in gctload i have not seen any information
regarding link down.

In trace i have seen that ASPUP and ASPAC when i have restarted the gctload
but i have not saved that trace.

Coming to traffic still they have not routed any traffic to our server still
waiting for traffic as once this alarams stops they are planning to send
traffic to server.They are complaing only for alarms.

Request you to please explain me why this alarms are genarating in switch as
there is no traffic to server and as we are not using SG and m3ua for long
time for this reason we are getting this alarms or any other reason.

Can you please explain what is "ceased" state.


Thanks & Regards
Srinivas Varakala
Pyro Networks





On Sun, Mar 29, 2009 at 8:29 AM, Aditya Sehgal <adi.aquarian@gmail.com>wrote:

> Hi Srinivas,
> I see no problem in the Wireshark trace that you have given me. Although,
> the trace does not have M3UA Activation messages (ASPUP/ASPAC), I can see
> GSM Invokes initiated from PC 131 (IP .90) to PC 400 (IP .66) which gets
> replied to from .66. This basically means that the Destination is Active on
> both sides.
>
> The Alarm logs that you have sent have the last alarm logged at 2009-03-26,
> 13:05:00 whereas the wireshark trace shows messages from the next day (it
> could be possible that we are in different time zones and that is why
> wireshark shows different times). In any case, all the alarms seemed to be
> in state "ceased". Is the switch engineer complaining about lost traffic or
> just the alarms.
>
> Thanks & Regards,
> Aditya Sehgal
>
> The ala
>
> On Fri, Mar 27, 2009 at 9:12 PM, srinivas varakala <srinu5659@gmail.com>wrote:
>
>> Hi Aditya
>>
>>    Please  find the attached file containing the GCT load out put and
>> trace for the same and the alarm sheet sent by switch engineer.
>> Please look in to this and help me out as i am fresher.
>>
>> Thanks & Regards
>>  Srinivas Varakala
>>
>> On Fri, Mar 27, 2009 at 7:51 PM, Aditya Sehgal <adi.aquarian@gmail.com>wrote:
>>
>>> Hi Srinivas,
>>> Its not possible to answer your query without more information (type of
>>> configuration for starters, a wireshark trace etc). However, ASPUP does not
>>> specify that the destination is up. Kindly check on the wireshark trace
>>> whether a subsequent ASPAC (ASP Active) messages were exchanged between the
>>> two nodes.
>>> HeartBEAT/HEARTBEAT-ACK just denotes that the Association is up (at SCTP
>>> level) and not necessairly that the "destination" is up and active.
>>>
>>> Thanks & Regards,
>>> Aditya Sehgal
>>>
>>> 2009/3/27 srinivas varakala <srinu5659@gmail.com>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Hi,
>>>>
>>>>    As i have small problem we have applied M3ua, TCAP, MAP SCCP licenses
>>>> we are able to see ASSUP and Link is active in our server and we can run our
>>>> application and by defining SSNs we can are able to quesy HLR but as problem
>>>> i am facing is that Switch engineers are saying that they are getting some
>>>> aarams at there switch side as M3UA DESTINATION INACCESSIBLE but when we
>>>> check in our server we are seeing that links are up by tracing the routes by
>>>> wireshark we see that HeartBeat and HartBeat ACKNOWLDMENT.
>>>>
>>>> For your reference please find the attachment sent by the switch
>>>> engineers.
>>>>
>>>> Request you to pleae reply soon
>>>> .
>>>>
>>>>
>>>> Thanks & Regards
>>>> Srinivas Varakala
>>>> Pyro Networks.
>>>>
>>>>
>>>>
>>>> --
>>>> Thanks & Regards
>>>> Srinivas Varakala
>>>> Pyro Networks.
>>>>
>>>> _______________________________________________
>>>> Sigtran mailing list
>>>> Sigtran@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sigtran
>>>>
>>>>
>>>
>>>
>>> --
>>> There are only 10 type of people in this World...Those who understand
>>> binary and those who dont
>>>
>>
>>
>>
>> --
>> Thanks & Regards
>> Srinivas Varakala
>> Pyro Networks.
>>
>
>
>
> --
> There are only 10 type of people in this World...Those who understand
> binary and those who dont
> Sent from: Bangalore KA India.




-- 
Thanks & Regards
Srinivas Varakala
Pyro Networks.

--0016e652ff9a3ccbaa04663d95d2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Aditya,<br><br>=A0Thanks for reply.<br><br>I have taken this trace next =
day after starting gctload at time of starting gctload i have not taken tar=
ce.Once the switch engineer sent this alarms i have started taken trace.I h=
ave restarted the server at 1:48 PM on 24/03/09 but i see some alarams at 3=
:29PM and 4:58PM on 24/03/09 as M3UA DESITINATION INACCESSIBLE but when i c=
heck in gctload i have not seen any information regarding link down.<br>
<br>In trace i have seen that ASPUP and ASPAC when i have restarted the gct=
load but i have not saved that trace.=A0 <br>
<br>Coming to traffic still they have not routed any traffic to our server =
still waiting for traffic as once this alarams stops they are planning to s=
end traffic to server.They are complaing only for alarms.<br><br>Request yo=
u to please explain me why this alarms are genarating in switch as there is=
 no traffic to server and as we are not using SG and m3ua for long time for=
 this reason we are getting this alarms or any other reason.<br>
<br>Can you please explain what is &quot;ceased&quot; state.<br><br><br>Tha=
nks &amp; Regards<br>Srinivas Varakala<br>Pyro Networks<br><br><br><br><br>=
<br><div class=3D"gmail_quote">On Sun, Mar 29, 2009 at 8:29 AM, Aditya Sehg=
al <span dir=3D"ltr">&lt;<a href=3D"mailto:adi.aquarian@gmail.com">adi.aqua=
rian@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Srinivas,<br>I=
 see no problem in the Wireshark trace that you have given me. Although, th=
e trace does not have M3UA Activation messages (ASPUP/ASPAC), I can see GSM=
 Invokes initiated from PC 131 (IP .90) to PC 400 (IP .66) which gets repli=
ed to from .66. This basically means that the Destination is Active on both=
 sides.<br>

<br>The Alarm logs that you have sent have the last alarm logged at 2009-03=
-26, 13:05:00 whereas the wireshark trace shows messages from the next day =
(it could be possible that we are in different time zones and that is why w=
ireshark shows different times). In any case, all the alarms seemed to be i=
n state &quot;ceased&quot;. Is the switch engineer complaining about lost t=
raffic or just the alarms. <br>

<br>Thanks &amp; Regards,<br>Aditya Sehgal<br>
<br>The ala <br><div><div></div><div class=3D"h5"><br><div class=3D"gmail_q=
uote">On Fri, Mar 27, 2009 at 9:12 PM, srinivas varakala <span dir=3D"ltr">=
&lt;<a href=3D"mailto:srinu5659@gmail.com" target=3D"_blank">srinu5659@gmai=
l.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Hi Aditya<br><br>=A0=A0 Please=A0 find the attached file containing the GCT=
 load out put and trace for the same and the alarm sheet sent by switch eng=
ineer.<br>Please look in to this and help me out as i am fresher.<br><br>Th=
anks &amp; Regards<br>


<font color=3D"#888888">
Srinivas Varakala <br></font><div><div></div><div><br><div class=3D"gmail_q=
uote">On Fri, Mar 27, 2009 at 7:51 PM, Aditya Sehgal <span dir=3D"ltr">&lt;=
<a href=3D"mailto:adi.aquarian@gmail.com" target=3D"_blank">adi.aquarian@gm=
ail.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Srinivas,<br>Its not possible to answer your query without more informat=
ion (type of configuration for starters, a wireshark trace etc). However, A=
SPUP does not specify that the destination is up. Kindly check on the wires=
hark trace whether a subsequent ASPAC (ASP Active) messages were exchanged =
between the two nodes. <br>




HeartBEAT/HEARTBEAT-ACK just denotes that the Association is up (at SCTP le=
vel) and not necessairly that the &quot;destination&quot; is up and active.=
<br><br>Thanks &amp; Regards,<br>Aditya Sehgal <br><br><div class=3D"gmail_=
quote">




2009/3/27 srinivas varakala <span dir=3D"ltr">&lt;<a href=3D"mailto:srinu56=
59@gmail.com" target=3D"_blank">srinu5659@gmail.com</a>&gt;</span><br><bloc=
kquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, =
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



<div><div></div><div>
<br><div class=3D"gmail_quote"><span dir=3D"ltr"></span><br><br><br><br cle=
ar=3D"all">Hi,<br><br>=A0=A0 As i have small problem we have applied M3ua, =
TCAP, MAP SCCP licenses we are able to see ASSUP and Link is active in our =
server and we can run our application and by defining SSNs we can are able =
to quesy HLR but as problem i am facing is that Switch engineers are saying=
 that they are getting some aarams at there switch side as M3UA DESTINATION=
 INACCESSIBLE but when we check in our server we are seeing that links are =
up by tracing the routes by wireshark we see that HeartBeat and HartBeat AC=
KNOWLDMENT.<br>






<br>For your reference please find the attachment sent by the switch engine=
ers.<br><br>Request you to pleae reply soon<br>.<br><br><br>Thanks &amp; Re=
gards<br><font color=3D"#888888">Srinivas Varakala<br>Pyro Networks.<br>






</font></div><br><br clear=3D"all"><br>-- <br>Thanks &amp; Regards<br>Srini=
vas Varakala<br>Pyro Networks.<br>
<br></div></div>_______________________________________________<br>
Sigtran mailing list<br>
<a href=3D"mailto:Sigtran@ietf.org" target=3D"_blank">Sigtran@ietf.org</a><=
br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sigtran" target=3D"_blank"=
>https://www.ietf.org/mailman/listinfo/sigtran</a><br>
<br></blockquote></div><font color=3D"#888888"><br><br clear=3D"all"><br>--=
 <br>There are only 10 type of people in this World...Those who understand =
binary and those who dont<br>
</font></blockquote></div><br><br clear=3D"all"><br></div></div>-- <br><div=
><div></div><div>Thanks &amp; Regards<br>Srinivas Varakala<br>Pyro Networks=
.<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>There are o=
nly 10 type of people in this World...Those who understand binary and those=
 who dont<br></div></div>Sent from: Bangalore KA India.
</blockquote></div><br><br clear=3D"all"><br>-- <br>Thanks &amp; Regards<br=
>Srinivas Varakala<br>Pyro Networks.<br>

--0016e652ff9a3ccbaa04663d95d2--