[Sigtran] Source /Destination Addresses in SUA CO

"Ilie Glib" <ilie.glib@googlemail.com> Fri, 16 November 2007 11:51 UTC

Return-path: <sigtran-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IszjU-00082d-QE; Fri, 16 Nov 2007 06:51:36 -0500
Received: from sigtran by megatron.ietf.org with local (Exim 4.43) id 1IszjT-0007zW-RH for sigtran-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 06:51:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IszjT-0007z5-HF for sigtran@ietf.org; Fri, 16 Nov 2007 06:51:35 -0500
Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IszjQ-0005b0-FF for sigtran@ietf.org; Fri, 16 Nov 2007 06:51:35 -0500
Received: by nz-out-0506.google.com with SMTP id n1so796039nzf for <sigtran@ietf.org>; Fri, 16 Nov 2007 03:51:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=Z8WTHeg4lKtgvz1ebb+2lHUTPIZExxX22Cas908mJko=; b=ur1+N3BtSff6FUoVUNtwUWkKWsB0L0LvI4oeEZI5w5HRCFQzuO6uqv+goto7fHT6tGuq3Py6Ejszem0S1hLbFXaYw3ZkIoZD4qW/ez5kf0/Qwe6RuCO+FmX07A5HdZ+hK2AKYDZJKeK8e/CQF+ccvhrX+7YkFa1yNuJouB2lrMg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=MOAnOwqOU4w1UWy7Sojib8UL5S4VVBXbcPXv3YkCkI4vZkKAS6WJPpy/K+nCJIspo6VZBqmEZ7SyJ9ICdKaN2oOaLX8n280Fpdc95x5LwA3LKBzTT7A2b9WnrZo7kJB6jM4V09OWuHClI7rju7nCksNYeLWWEHZtY8traksn2hw=
Received: by 10.142.106.18 with SMTP id e18mr544400wfc.1195213891357; Fri, 16 Nov 2007 03:51:31 -0800 (PST)
Received: by 10.142.216.17 with HTTP; Fri, 16 Nov 2007 03:51:31 -0800 (PST)
Message-ID: <17b146d60711160351vda9c8d5rae2f14a6f3cbf1e0@mail.gmail.com>
Date: Fri, 16 Nov 2007 12:51:31 +0100
From: Ilie Glib <ilie.glib@googlemail.com>
To: sigtran <sigtran@ietf.org>
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a743e34ab8eb08259de9a7307caed594
Subject: [Sigtran] Source /Destination Addresses in SUA CO
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1341066094=="
Errors-To: sigtran-bounces@ietf.org

Hello Folks,

I have a basic question, which shall be easy to answer.
In SCCP for a connection-oriented message, the significance of Called and
Calling Party addresses is related to the direction of the connection set-up
(i.e. independent of the direction the message is going).

Is there any difference in SUA CO messages for Source and Destination
Address parameters with respect to this rule?
Are you aware of any interoperability problems where SUA CO does not follow
the SCCP rule for Source and Destination Addresses?

In one of the mails sent on the SIGTRAN list (included below) it is said
 "... behavior is same for CC/CREF in case of SCCP. So the called party
should be the calling party address received in the CR message.".

This looks alarming.

I am afraid that the note
    NOTE *1:    Destination Address parameter will be present in case

               that the received CORE message conveys the Source

               Address parameter.
in sections
3.3.4.  Connection Acknowledge (COAK) and

3.3.5.  Connection Refused (COREF)

might be misinterpreted, as requesting to copy the destination address in
the source address.

I think that the RFC shall be more specific about use of Source and
Destination Address parameters in SUA CO.

Any opinions?


Thank you in advance

/Ilie



Hi Chen Puran,

I am not sure that I have understand your problem clearly or not, regarding
RFC 3868 it is very clear that the COREF should always contain ("will
contain" as the note *1) the destination address parameter as the source
address parameter received in the CORE message if received only, the same is
true for the COAK also. Though it should not used for the routing purposes.

And regarding the Q71X, I think these are too very clear about the Called
party address parameter use in the case of CC/CREF message, just want to
mention one thing called party behavior is same for CC/CREF in case of SCCP.
So the called party should be the calling party address received in the CR
message.

Section 2.2.1 NOTE - The called party address in the CREF or CC messages
shall not be used for routing.

Thought section 2.7.2 defines some rules for the international gateway (in
case of international network) on the responding address but it's not saying
that the destination should not be filled as source address parameter.

I hope I have answered your query, please let me know if not.

Thanks,

Salil

 -----Original Message-----

From: chen.puran@zte.com.cn
[*mailto:chen.puran@zte.com.cn*<chen.puran@zte.com.cn>
]

Sent: Saturday, June 02, 2007 10:26 AM

To: sigtran@ietf.org

Subject: [Sigtran] help:about Destination Address parameter of COREF

Hello :

I have a question about SUA COREF Message ,in RFC3868 describe of
Destination Address parameter of COREF is

"NOTE *1: Destination Address parameter will be present in case

that the received CORE message conveys the Source

Address parameter. "

it define Destination Address is CORE's Source Address.but COREF Destination
Address parameter is a optional parameter,so it is not a according of
routing.

in Q.714 ,it's not define clearly which address will chose in CREF called
party address parameter.but it said that DIS_CONNECTIND message responding
address is CREF called party address,description is in below

"It is the task of the outgoing international gateway2 (or originating
international node) to make sure that the calling party address or
responding address (i.e. called party address parameter in a CC or CREF

message) satisfies the following rules:"

in Q.711,it said

"The "responding address" parameter is present in the N-DISCONNECT primitive
only in the case where the primitive is used to indicate rejection of a
signalling connection establishment attempt by an SCCP user function. The
parameter conveys the address of the service access point from which the
N-DISCONNECT-request was issued and under circumstances like that mentioned
above the "responding address" may be different from the "called address" in
the corresponding N-CONNECT request primitive."

from the description of "responding address",it's address of
N-DISCONNECT-request point.

I think it's conflicting in description between RFC3868 and Q71X,which
should be of Destination Address parameter? Thanks.
_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran