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

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 12 Aug 2005 09:22:54 -0400

I'm way behind on some of my E-mail, but as the person who chaired the 
development of Q.1912.5 I thought I'd better comment.

This point about when INFO can be used was one raised by Ericsson, and 
actually resulted in delay of approval of the specification.  The view 
was that INFO could not be sent until an early dialogue had been 
established.  That has nothing to do with whether the 183 response is 
reliable or not.

Peili Xu wrote:
> 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:
> 
>  
> 
>    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

_______________________________________________
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: xupeili 18916 <[email-masked]>
Date: Sun, 14 Aug 2005 00:20:35 +0800

Update RFC2976 will help those who don`t want to take the risk of disobey RFC even have some doubt about it.

Before that I think we can treat INFO like UPDATE except that UPDATE will do session modification.

Peili Xu

----- Original Message -----
From: Tom-PT Taylor <[email-masked]>
Date: Saturday, August 13, 2005 2:03 am
Subject: Re: [Sip] INFO method used for ISUP to SIP IW (2nd round)

> Once upon a time I figured I'd clarify the situation by updating 
> the 
> INFO specification.  I suppose I could still do that, but I was a 
> bit 
> nervous about what else might happen to that spec. if it were 
> reopened.
> Anyway, you've stated the ITU-T interpretation.
> 
> [email-masked] wrote:
> > In a message dated 8/12/2005 9:23:43 AM Eastern Daylight Time, 
> > [email-masked] writes:
> > 
> > 
> > 
> > I don't think there was ever a question that INFO could not be 
> used before an 
> > early dialog. The issue is whether or not it can be used after 
> an early 
> > dialog is established and before the confirmed dialog. After all 
> the discussion, I 
> > don't believe that there was a solid answer, since IETF RFCs and 
> Q.1912.5 seem 
> > to be contradictory (for the callee to caller direction).
> > 
> > There really isn't a clear statement in any RFC, except that 
> INFO follows the 
> > rules for BYE. RFC 3261 (which was written later) says that the 
> BYE can only 
> > be sent in the callee to caller direction on a confirmed dialog.
> > 
> > Q.1912.5 indicates that the INFO can be sent (callee to caller 
> direction) 
> > before confirmed dialog is established.
> > 
> > So which is correct? Can the INFO be used during the early 
> dialog state in 
> > the callee to caller direction? This is critically important for 
> the operation 
> > of SIP-T.
> > 
> > Mike Pierce
> > 
> 
>