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

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 21 Jul 2005 09:41:06 -0500

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 20, 2005 9:35 PM
To: [email-masked]
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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Peili Xu <[email-masked]>
Date: Fri, 22 Jul 2005 20:28:37 +0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of Ejzak,
Richard P (Richard)
Sent: Thursday, July 21, 2005 10:41 PM
To: [email-masked]'; [email-masked]
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:

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:

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 20, 2005 9:35 PM
To: [email-masked]
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 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. 

Mike Pierce