From santhana@huawei.com Thu May 14 22:37:15 2009 Return-Path: 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 530C63A69B4 for ; Thu, 14 May 2009 22:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.106 X-Spam-Level: X-Spam-Status: No, score=0.106 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RDNS_NONE=0.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 HO5CK42SyXzo for ; Thu, 14 May 2009 22:37:14 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 6039C3A68EC for ; Thu, 14 May 2009 22:37:14 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJO00CSO7OAP2@szxga02-in.huawei.com> for sigtran@ietf.org; Fri, 15 May 2009 13:38:35 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJO00D7A7OALU@szxga02-in.huawei.com> for sigtran@ietf.org; Fri, 15 May 2009 13:38:34 +0800 (CST) Received: from BLRNSHTIPL2NC ([10.18.1.32]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJO00K227O9QY@szxml04-in.huawei.com> for sigtran@ietf.org; Fri, 15 May 2009 13:38:34 +0800 (CST) Date: Fri, 15 May 2009 11:06:39 +0530 From: Santhana To: sigtran@ietf.org Message-id: <001201c9d51f$1f6a4350$2001120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_Ij8lqqLG1xh1MN59lhLkWQ)" Thread-index: AcnVHx6WzdxHB9J+Q9q3vrEAbCTm6w== Subject: [Sigtran] [M3UA] Can IPSP client receive ASP UP message X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 05:37:15 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Ij8lqqLG1xh1MN59lhLkWQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Brian Considering two IPSPs, IPSP A and IPSP B, can any of them receive ASP UP message for bringing up the ASP. Does each ASP be able to act as server or client? Does the M3UA RFC mandate this behavior ? Or once it has started operating as Client or server it can stick to that role. So that the client will always receive ASP UP/DOWN/ACTIVE/INACTIVE ACK messages and server always receive ASP UP/DOWN/ACTIVE/INACTIVE messages. If in some implementation an IPSP cannot act as client and server both what should be the response from the client IPSP when it receives ASP UP message. Regards Santhanakrishnan --Boundary_(ID_Ij8lqqLG1xh1MN59lhLkWQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Brian

            Considering two IPSPs, IPSP A and IPSP B, can any of them receive ASP UP message for bringing up the ASP.

 

Does each ASP be able to act as server or client? Does the M3UA RFC mandate this behavior ?

 

Or once it has started operating as Client or server it can stick to that role. So that the client will always receive ASP UP/DOWN/ACTIVE/INACTIVE ACK messages and server always receive ASP UP/DOWN/ACTIVE/INACTIVE messages.

 

If in some implementation an IPSP cannot act as client and server both what should be the response from the client IPSP when it receives ASP UP message.

 

 

Regards

Santhanakrishnan

--Boundary_(ID_Ij8lqqLG1xh1MN59lhLkWQ)-- From bidulock@openss7.org Fri May 15 01:32:54 2009 Return-Path: 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 3BEC63A6A5E for ; Fri, 15 May 2009 01:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.204, 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 LW42f9u8y137 for ; Fri, 15 May 2009 01:32:53 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 415E93A6E1D for ; Fri, 15 May 2009 01:32:44 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:2IKkmsPf+98SrjiW7NUdgFSvEeN/N05R@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id n4F8Y29s003545; Fri, 15 May 2009 02:34:02 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:OU0y4l1+JV8D/vSrED0ya/MEkohjwbNs@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id n4F8Y2n7027864; Fri, 15 May 2009 02:34:02 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id n4F8Y2OP027851; Fri, 15 May 2009 02:34:02 -0600 Date: Fri, 15 May 2009 02:34:02 -0600 From: "Brian F. G. Bidulock" To: Santhana Message-ID: <20090515083402.GA7550@openss7.org> Mail-Followup-To: Santhana , sigtran@ietf.org References: <001201c9d51f$1f6a4350$2001120a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001201c9d51f$1f6a4350$2001120a@china.huawei.com> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: sigtran@ietf.org Subject: Re: [Sigtran] [M3UA] Can IPSP client receive ASP UP message X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 08:32:54 -0000 Santhana, Santhana wrote: (Fri, 15 May 2009 11:06:39) > > Hi Brian > > Considering two IPSPs, IPSP A and IPSP B, can any of them > receive ASP UP message for bringing up the ASP. Sure. > Does each ASP be able to act as server or client? Does the M3UA RFC > mandate this behavior ? No, it does not mandate that both are able to act as both. > Or once it has started operating as Client or server it can stick to > that role. So that the client will always receive ASP > UP/DOWN/ACTIVE/INACTIVE ACK messages and server always receive ASP > UP/DOWN/ACTIVE/INACTIVE messages. An implementation should be able to stick to one role if it wishes. > If in some implementation an IPSP cannot act as client and server both > what should be the response from the client IPSP when it receives ASP > UP message. ERROR "Unexpected Message" --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ From sujayudupa@huawei.com Tue May 19 05:39:07 2009 Return-Path: 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 8C1B43A6ECE for ; Tue, 19 May 2009 05:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 QqjdtGVLfTP3 for ; Tue, 19 May 2009 05:39:06 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 75B563A6EB1 for ; Tue, 19 May 2009 05:39:06 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJW000AP5VKAO@szxga01-in.huawei.com> for sigtran@ietf.org; Tue, 19 May 2009 20:40:32 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJW004P25VKVL@szxga01-in.huawei.com> for sigtran@ietf.org; Tue, 19 May 2009 20:40:32 +0800 (CST) Received: from BLRNSHTIPL8NC ([10.18.1.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJW00LGI5VJZA@szxml06-in.huawei.com> for sigtran@ietf.org; Tue, 19 May 2009 20:40:32 +0800 (CST) Date: Tue, 19 May 2009 18:10:32 +0530 From: Sujay Udupa To: sigtran@ietf.org Message-id: <000001c9d87f$007d07d0$2601120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_T/tSoiuO01329BD8+2/8zg)" Thread-index: AcnYfv/Fki8JTnmORaWI5PovBZE5dQ== Subject: [Sigtran] RFC 3868 query regarding sequence number X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 03:40:10 -0000 This is a multi-part message in MIME format. --Boundary_(ID_T/tSoiuO01329BD8+2/8zg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi All, I have a query regarding section 3.3.1 in RFC 3868 3.3.1. Connection Oriented Data Transfer (CODT) ... ... | Tag = 0x0107 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | ... ... Parameters Routing Context Mandatory Sequence Number Optional *1 ... ... NOTE *1: This parameter is not present in case of Expedited Data (ED). Implementation note: For the CODT to represent DT1, DT2 and ED messages, the following conditions MUST be met: DT1 is represented by a CODT when: Sequence Number parameter is present (contains "more" indicator). DT2 is represented by a CODT when: Sequence Number parameter is present (contains P(S), P(R) and more indicator) ED is represented by a CODT with: Sequence Number parameter is not present Here Sequence number is mentioned as a optional parameter. Can one assume that is a message is received without a sequence number, then the message is Expedited? Can a DT1 message not have a sequence number? Thanks, Sujay --Boundary_(ID_T/tSoiuO01329BD8+2/8zg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi All,

 

I have a query regarding section 3.3.1 in RFC 3868
 
3.3.1.  Connection Oriented Data Transfer (CODT)
...
...
   |         Tag = 0x0107          |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
...
...
     Parameters
     Routing Context               Mandatory
     Sequence Number               Optional *1
...
...
   NOTE *1:   This parameter is not present in case of Expedited Data
              (ED).
 
   Implementation note: For the CODT to represent DT1, DT2 and ED
   messages, the following conditions MUST be met:
 
   DT1 is represented by a CODT when:
     Sequence Number parameter is present (contains "more" indicator).
 
   DT2 is represented by a CODT when:
     Sequence Number parameter is present (contains P(S), P(R) and more
     indicator)
 
   ED is represented by a CODT with:
     Sequence Number parameter is not present
 
Here Sequence number is mentioned as a optional parameter. Can one assume that is a message is received without a sequence number, then the message is Expedited? Can a DT1 message not have a sequence number?
 
Thanks,
Sujay
 

 

--Boundary_(ID_T/tSoiuO01329BD8+2/8zg)-- From sergey.mikhailov@gmail.com Wed May 20 22:46:15 2009 Return-Path: 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 512DB3A6873 for ; Wed, 20 May 2009 22:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.581 X-Spam-Level: X-Spam-Status: No, score=0.581 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] 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 qFccMZ56Jj4Y for ; Wed, 20 May 2009 22:46:14 -0700 (PDT) Received: from mail-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by core3.amsl.com (Postfix) with ESMTP id 64F233A69A7 for ; Wed, 20 May 2009 22:46:01 -0700 (PDT) Received: by bwz22 with SMTP id 22so806284bwz.37 for ; Wed, 20 May 2009 22:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:cc :references:subject:date:mime-version:content-type:x-priority :x-msmail-priority:x-mailer:x-mimeole; bh=WbcqJ/lVCu2hbVRii/9F03HOEHaX84TDK4UHql/wRLw=; b=tEzAlX4jlDUM3B/dulr1E2Rsu5h//JvqP+zmbXzkBjeIiTHOVwrVvruf7LCBlxW4w4 fAO7qWygSOCxY9Ht0yn+W9jSKCNmfWb+Erz7Aato8toNchxvkPTJjz7tgXOQdra/lTC5 G/xd0i5zp9G+vmvGP8Oem976YJ7mhH8qBCd1E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=Ru2lpaslmOInJHx7kRyK2rGsJJhMSoPRryU9Trj7YnGWwYxOuAgxqAGGoReaN6F7+l 17X3UfrUIuCs7C6VHWtjOYSm1jvtE6yekYZzo6iGb11t4i5rCFjwkgPCwtlsDSXqlU5Z sMU7MRX2HNdmtlyB5MkY25mp4XBqZnRke03Nk= Received: by 10.103.24.17 with SMTP id b17mr1160851muj.21.1242884856360; Wed, 20 May 2009 22:47:36 -0700 (PDT) Received: from smikhailov ([89.105.151.254]) by mx.google.com with ESMTPS id 12sm437986muq.23.2009.05.20.22.47.31 (version=SSLv3 cipher=RC4-MD5); Wed, 20 May 2009 22:47:34 -0700 (PDT) Message-ID: From: "Sergey Mikhailov" To: "Sujay Udupa" References: <000001c9d87f$007d07d0$2601120a@china.huawei.com> Date: Thu, 21 May 2009 13:47:48 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01C9DA1A.BA7F4E80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: SIGTRAN Subject: Re: [Sigtran] RFC 3868 query regarding sequence number X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 05:46:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0043_01C9DA1A.BA7F4E80 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Sujay, when a CODT does not have Sequence Number, then it represents ED. DT1 may not be represented by a CODT without Sequence Number. This is what is meant by this implementation note. Regards, Sergey Mikhailov. ----- Original Message -----=20 From: Sujay Udupa=20 To: sigtran@ietf.org=20 Sent: Tuesday, May 19, 2009 8:40 PM Subject: [Sigtran] RFC 3868 query regarding sequence number Hi All, =20 I have a query regarding section 3.3.1 in RFC 3868 3.3.1. Connection = Oriented Data Transfer (CODT)...... | Tag =3D 0x0107 = | Length | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = Sequence Number |...... = Parameters Routing Context Mandatory Sequence = Number Optional *1...... NOTE *1: This parameter is = not present in case of Expedited Data (ED). = Implementation note: For the CODT to represent DT1, DT2 and ED = messages, the following conditions MUST be met: DT1 is represented by = a CODT when: Sequence Number parameter is present (contains "more" = indicator). DT2 is represented by a CODT when: Sequence Number = parameter is present (contains P(S), P(R) and more indicator) ED = is represented by a CODT with: Sequence Number parameter is not = present Here Sequence number is mentioned as a optional parameter. Can = one assume that is a message is received without a sequence number, then = the message is Expedited? Can a DT1 message not have a sequence number? = Thanks,Sujay =20 -------------------------------------------------------------------------= ----- _______________________________________________ Sigtran mailing list Sigtran@ietf.org https://www.ietf.org/mailman/listinfo/sigtran ------=_NextPart_000_0043_01C9DA1A.BA7F4E80 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Sujay,
 
when a CODT does not have Sequence Number, then it = represents=20 ED.
DT1 may not be represented by a CODT without = Sequence=20 Number.
 
This is what is meant by this implementation=20 note.
 
Regards,
Sergey Mikhailov.
 
----- Original Message -----
From:=20 Sujay=20 Udupa
Sent: Tuesday, May 19, 2009 = 8:40 PM
Subject: [Sigtran] RFC 3868 = query=20 regarding sequence number

Hi=20 All,

 

I have a query regarding section 3.3.1 in RFC =
3868
 
3.3.1.  =
Connection Oriented Data Transfer =
(CODT)
...
...
   =
|         Tag =3D =
0x0107          =
|            =
 =
Length            =
|
   =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   =
|            =
            =
Sequence =
Number            =
            |=
...
...
   =
  Parameters
     Routing =
Context           =
    Mandatory
     Sequence =
Number           &=
nbsp;   Optional *1
...
...
   NOTE =
*1:   This parameter is not present in case of Expedited =
Data
           &=
nbsp;  (ED).
 
   =
Implementation note: For the CODT to represent DT1, DT2 and =
ED
   messages, the =
following conditions MUST be =
met:
 
   DT1 is =
represented by a CODT when:
     Sequence Number parameter is present =
(contains "more" indicator).
 
   DT2 is =
represented by a CODT when:
     Sequence Number parameter is present =
(contains P(S), P(R) and more
     =
indicator)
 
   ED is =
represented by a CODT with:
     Sequence Number parameter is not =
present
 
Here Sequence number is mentioned as a optional parameter. Can one =
assume that is a message is received without a sequence number, then the =
message is Expedited? Can a DT1 message not have a sequence =
number?
 
Thanks,
Sujay
 

 


_______________________________________________
Sigtran = mailing=20 = list
Sigtran@ietf.org
https://www.ietf.org/mailman/listinfo/sigtran=
------=_NextPart_000_0043_01C9DA1A.BA7F4E80-- From bidulock@openss7.org Wed May 20 23:02:41 2009 Return-Path: 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 25FB23A69D8 for ; Wed, 20 May 2009 23:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 Sp44chFOi9qU for ; Wed, 20 May 2009 23:02:40 -0700 (PDT) Received: from gw.openss7.com (gw.openss7.com [206.75.119.236]) by core3.amsl.com (Postfix) with ESMTP id 1ED413A69A7 for ; Wed, 20 May 2009 23:02:40 -0700 (PDT) Received: from wilbur.pigworks.openss7.net (IDENT:AUrHQfVLCteoGfR4WVVByjyVg942Rlmy@ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.13.8/8.13.8/Debian-3) with ESMTP id n4L646Er016383; Thu, 21 May 2009 00:04:06 -0600 Received: from wilbur.pigworks.openss7.net (IDENT:3YcVlwq0eh9cTE1HfmBDZPwlLqgaCjld@localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Debian-3) with ESMTP id n4L646I5018442; Thu, 21 May 2009 00:04:06 -0600 Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.13.8/8.13.8/Submit) id n4L646NS018441; Thu, 21 May 2009 00:04:06 -0600 Date: Thu, 21 May 2009 00:04:06 -0600 From: "Brian F. G. Bidulock" To: Sujay Udupa Message-ID: <20090521060406.GA18009@openss7.org> Mail-Followup-To: Sujay Udupa , sigtran@ietf.org References: <000001c9d87f$007d07d0$2601120a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c9d87f$007d07d0$2601120a@china.huawei.com> Organization: http://www.openss7.org/ Dsn-Notification-To: X-Spam-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: sigtran@ietf.org Subject: Re: [Sigtran] RFC 3868 query regarding sequence number X-BeenThere: sigtran@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bidulock@openss7.org List-Id: Signaling Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 06:02:41 -0000 Sujay, Sujay Udupa wrote: (Tue, 19 May 2009 18:10:32) > > Here Sequence number is mentioned as a optional parameter. We probably should have called it "Conditional". > Can one assume that is a message is received without a sequence > number, then the message is Expedited? Yes. > Can a DT1 message not have a sequence number? No. --brian -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/