RE: [Sip] INFO method used for ISUP to SIP IW (2nd round)

Hi, Mike,

I totally agree with your comments about

(1)INFO can be sent within dialog of cause at lease after early dialog is established.

(2)transparent backward ISUP message may be encapsulated in reliable 1xx or INFO.

But from the exact Q.1912.5 specification:

--Q.1912.5, on the other hand, describes how "transparent" messages are encapsulated, and it says they are carried in the following:
--a) 183 Session Progress provisional response if this is sent by the I-IWU in the backward direction before a confirmed dialog is established.
--b) INFO message in all other cases.

It seems that backward ISUP message before call is connected must be carried in 183 before a “confirmed dialog”,

I think this is the point which confuse some people who consider that INFO in early dialog is another option.

Reguards!

Peili Xu

-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of Ejzak, Richard P (Richard)
Sent: Thursday, July 21, 2005 10:41 PM
To: 'Mpierce1 at aol.com'; sip at ietf.org
Subject: RE: [Sip] INFO method used for ISUP to SIP IW (2nd round)

Mike,

I do not agree with your interpretation of Q.1912.5. Within RFC 3261 and RFC 3262, a dialog may be established by sending a reliable provisional or final response. Q.1912.5 simply says that if you haven't sent a reliable response yet (provisional or final, to establish a dialog), encapsulate a transparent backward ISUP message in a provisional. Your interpretation is correct without 100rel, but breaks down when using 100rel. So according to Q.1912.5, any transparent encapsulated ISUP in the backward direction after transmission of a reliable provisional response will use INFO, including during the period before transmission of the 200 OK response. Note that other (not transparent) ISUP messages follow different rules in Q.1912.5.

Regarding the supposed constraints on the use of INFO, RFC 2976 says the following things:

   It is necessary that the mid-session signaling information traverse
   the post session setup SIP signaling path. This is the path taken by
   SIP re-INVITEs, BYEs and other SIP requests that are tied to an
   individual session. This allows SIP proxy servers to receive, and
   potentially act on, the mid-session signaling information.

In RFC 3261 and RFC 3262, this requirement is also satisfied when a dialog is established using a reliable provisional response in support of, for example, the UPDATE request. RFC 2976 goes on to say:

      Unless stated otherwise, the protocol rules for the INFO request
      governing the usage of tags, Route and Record-Route,
      retransmission and reliability, CSeq incrementing and message
      formatting follow those in [1] as defined for the BYE request.

Reference [1] is RFC 2543. This text only discusses the rules for formatting various header. It does not constrain INFO to all aspects of the use of BYE. And that's all that's said about the relationship of INFO to BYE at user agents.

The real problem is that RFC 2976 has not been updated to match RFC 3261 and RFC 3262. But the intent of the original RFC seems clear enough to allow INFO in either direction once a dialog is established, such as by sending a reliable provisional response. I see no problem with either RFC 3398 or Q.1912.5 in their use of INFO.

Richard Ejzak

-----Original Message-----
From: Mpierce1 at aol.com [mailto:Mpierce1 at aol.com]
Sent: Wednesday, July 20, 2005 9:35 PM
To: sip at ietf.org
Subject: Re: [Sip] INFO method used for ISUP to SIP IW (2nd round)

To all,

Recently, there was a discussion of the question of whether or not the INFO can be sent before the dialog has been established. There seemed to be various opinions on this, but no clear answer. This is a very important issue for SIP-T.

As I noted before, INFO is defined in RFC 2976 where it states that it follows the rules for BYE as contained in RFC 2543. RFC 2543 is now obsolete. In fact, the main question about the use of INFO relates to its use during early dialog, a concept which was defined after INFO was defined.

RFC 3261 states that the BYE is used:
in the caller to callee direction, either in confirmed or early dialog state
in the callee to called direction, on confirmed dialog only

RFC 3398 indicates that the INFO is used to carry encapsulated ISUP:
in the caller to called direction, even if INVITE transaction is not finished (i.e., in both early and confirmed dialog state)
in the callee to caller direction, even before answer (i.e., in both early and confirmed dialog states)

So, the use of INFO in RFC 3398 does not always follow the rules for BYE as stated in RFC 2976.

Q.1912.5, on the other hand, describes how "transparent" messages are encapsulated, and it says they are carried in the following:
a) 183 Session Progress provisional response if this is sent by the I-IWU in the backward direction before a confirmed dialog is established.
b) INFO message in all other cases.

So the ITU-T Recommendation does have the INFO following the rules for BYE.

Is this a correct interpretation?

Mike Pierce