Subject: RE: [Sipping] RE: [SIP] SUS/RES encapsulation

From: "Mark Watson" <[email-masked]>
Date: Thu, 14 Jun 2001 18:17:55 +0100

I am confused that we are now making rules about which ISUP messages
can/cannot be included in the INFO method. What about unrecognised messages
?

I understood that INFO was used to send ISUP messages in the case that there
was no need for any action at the SIP layer - a PSTN GW receiving INFO just
passes on the encapsulated ISUP message. A SIP UA receiving INFO with
encapsulated ISUP ignores it. It will be more work to rule out inclusion of
SUS/RES in INFO than it would be to support it, because I'd have to check
the type of the ISUP message to see if it was allowed in INFOs.

Surely what happens to the media stream is orthoganal to the transport of
the ISUP messages ? As has been said on this thread, Suspend may/may not
lead to a need to hold the media stream. If you have a codec with silence
suppression it won't make any difference to the bandwidth used anyway.

To my mind, the only question is whether the body of a SIP message can
contain an ISUP payload when there is no functional relationship between the
two ?

The answer is Yes for provisional responses.
The question does not make sense for INVITE, ACK or BYE.
We have not yet answered this for Re-INVITE.

I'd be inclined to say yes on grounds of consistency/simplicity.

Regards...Mark

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: 12 June 2001 18:43
> To: Jonathan Rosenberg
> Cc: 'Michael Hammer'; [email-masked]; 
> [email-masked];
> [email-masked]
> Subject: Re: [Sipping] RE: [SIP] SUS/RES encapsulation
> 
> 
> Hello all,
> 
> I believe that this approach (suggested by Jonathan) will 
> make everybody
> happy. We will add some wording in the draft... now we consider this
> issue resolved.
> 
> Thanks Jonathan,
> 
> Best regards,
> 
> Gonzalo
> 
> Jonathan Rosenberg wrote:
> > 
> > I'm not clear on what you are proposing.
> > 
> > I would propose that if the originating GW wants to stop 
> the media stream
> > from being received, it sends the SUS in a re-INVITE with 
> held SDP. If it
> > doesn't want to stop the media stream, it sends a re-INVITE 
> with the same
> > SDP as before (refresh).
> > 
> > -JOnathan R.
> > 
> > ---
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > [email-masked]                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> > 
> > 
> > > -----Original Message-----
> > > From: Michael Hammer [mailto:[email-masked]]
> > > Sent: Tuesday, June 12, 2001 11:32 AM
> > > To: [email-masked]
> > > Cc: [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]
> > > Subject: Re: [Sipping] RE: [SIP] SUS/RES encapsulation
> > >
> > >
> > > Jon,
> > >
> > > Thought to consider:
> > >
> > > Do you want to burden an MGC with possibly sending MGCP
> > > messages to a media
> > > gateway and the gateway to respond by changing the bearer
> > > state, only to
> > > perhaps tear down the call seconds later, or perhaps to do another
> > > re-Invite to put it back to the prior state?  That may be 
> a waste of
> > > computing resources.
> > >
> > > In a PSTN-IP-PSTN transit situation, the distant end can 
> handle the
> > > follow-on leg in whatever manner it decides.  With an
> > > IP-based end-point,
> > > do you want to make changes that may not mean much?  If the
> > > prior leg has
> > > stopped sending bearer data, then presumably the IP leg is
> > > not wasting much
> > > bandwidth on the silent party.
> > >
> > > I'm not sure what is gained here to make the extra 
> handling worth it.
> > >
> > > Mike
> > >
> > > At 02:57 PM 6/11/2001 -0600, [email-masked] wrote:
> > > >I think this case is interesting in so far as the
> > > originating PSTN gateway
> > > >(which has received the SUS and which will subsequently send
> > > a re-INVITE or
> > > >INFO) is making a decision about how the terminating SIP
> > > endpoint should
> > > >react to the suspension of the PSTN leg of the call. In some
> > > networks it
> > > >might not matter if the terminating SIP endpoint continues
> > > to transmit media
> > > >to the PSTN gateway while the call is suspended. If however
> > > the terminating
> > > >SIP endpoint is using a dialup link for connectivity or has
> > > some similar
> > > >bandwidth constraint, the endpoint might want to stop
> > > transmitting media.
> > > >
> > > >So, should a SIP endpoint (which could be a native SIP 
> phone with no
> > > >understanding of ISUP) have to understand a SUS in INFO in
> > > order to know
> > > >that it should stop transmitting media, if its local
> > > policies suggest that
> > > >it should do just that? Should the PSTN gateway decide 
> this for SIP
> > > >endpoints (perhaps it makes a difference if they are in the same
> > > >administrative domain or not)? On the converse side, is
> > > there any harm in
> > > >the PSTN gateway sending a re-INVITE on receipt of SUS? I
> > > don't see why it
> > > >would be undesirable to cease the flow of media for the
> > > duration of the
> > > >suspension of the call, especially considering that
> > > suspensions most often
> > > >lead to the termination of the call.
> > > >
> > > >I am certainly wary of defining two mechanisms for this
> > > (i.e. allowing both
> > > >INFO and re-INVITE for SUS), since I'm not sure why a
> > > gateway vendor would
> > > >implement one rather than the other. Perhaps if there 
> needs to be a
> > > >mechanism by which the gateway can handle a SUS without
> > > forcing a change in
> > > >the media characteristics of a call, it could send a
> > > re-INVITE without SDP,
> > > >or something. Personally I'd rather see one defined way of
> > > handling this
> > > >case.
> > > >
> > > >Jon Peterson
> > > >Level(3) Communications
> > > >
> > > >-----Original Message-----
> > > >From: Gonzalo Camarillo 
> [mailto:[email-masked]]
> > > >Sent: Monday, June 11, 2001 6:53 AM
> > > >To: Jonathan Rosenberg
> > > >Cc: sip; Peterson, Jon; [email-masked]
> > > >Subject: Re: [SIP] SUS/RES encapsulation
> > > >
> > > >
> > > >Hello,
> > > >
> > > >Jonathan Rosenberg wrote:
> > > > > I may be mistaken, but I thought
> > > > > that SUS really was an end-to-end hold of media, and
> > > therefore, should be
> > > > > mapped to the equivalent function in SIP - a re-INVITE
> > > with 0.0.0.0 SDP.
> > > >
> > > >SUS is used when an ISDN subscriber unplugs his phone 
> from the socket
> > > >and plugs it in another socket in the middle of the call.
> > > When the call
> > > >is SUSpended, the local exchange of the user unplugging the
> > > phone cuts
> > > >the media, but the rest of the switches do not do anything.
> > > >
> > > >SUS is also sent by the an analog callee when he hangs up,
> > > but for our
> > > >purposes it does not matter which one of the scenarios 
> we are dealing
> > > >with.
> > > >
> > > >
> > > >I agree with you that SDP 0.0.0.0 is the proper way to 
> go, and that's
> > > >why it was included in the draft in the first place. 
> However, I have
> > > >been receiving comments about this proposing a 
> differeent mapping.
> > > >That's why I wanted to get the opinion of the mailing list.
> > > My personal
> > > >opinion was written in the draft already.
> > > >
> > > >The proposal that I have received is that, since in the 
> PSTN all the
> > > >switches but the local exchange do not do anything, the SUS
> > > message can
> > > >be mapped to an INFO message, since it does not affect the
> > > state of the
> > > >session.
> > > >
> > > >Opinions?
> > > >
> > > >Best regards,
> > > >
> > > >Gonzalo
> > > >--
> > > >Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> > > >Columbia University                  Mobile:  +358 40 702 35 35
> > > >472 Computer Science Building        Fax   :  +358  9 299 30 52
> > > >1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> > > >New York, NY 10027
> > > >USA                              [email-masked]
> > > >
> > > >_______________________________________________
> > > >Sipping mailing list
> > > >[email-masked]
> > > >http://www.ietf.org/mailman/listinfo/sipping
> > >
> > >
> > > _______________________________________________
> > > Sipping mailing list
> > > [email-masked]
> > > http://www.ietf.org/mailman/listinfo/sipping
> > >
> 
> -- 
> Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> Columbia University                  Mobile:  +358 40 702 35 35
> 472 Computer Science Building        Fax   :  +358  9 299 30 52
> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> New York, NY 10027                   
> USA                              [email-masked]
> 
> _______________________________________________
> Sipping mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/sipping
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 14 Jun 2001 20:34:38 +0300

Hello,

If we want the media stream to be stopped while we are SUSpended, it is
clear that we will send a re-INVITE with SDP 0.0.0.0 and the SUS in it.

Since sometimes we do not want to stop the media path, we have two
possibilities:
1)Encapsulate the SUS in an INFO.
2)Encapsulate the SUS in a re-INVITE with the same SDP as before.

As you point out, INFO might be appropiate, since we do not require any
actions from the SIP plane. However, we have agreed that re-INVITE seems
to be a more coherent solution, since all the SUS received by a gateway
will be encapsulated in the same way - always in a re-INVITE.

Encapsulating SUSs in INFOs or re-INVITEs depending on whether we want
to stop the media or not seems to be slightly more complicated. That's
the only reason why we have chosen to send every SUS in a re-INVITE.

However, as you also point out, a SIP entity (gateway or UA) receiving
an INFO with a SUS in it is not supposed to crash.

Best regards,

Gonzalo

Mark Watson wrote:
> can/cannot be included in the INFO method. What about unrecognised
> messages ?
> 
> I understood that INFO was used to send ISUP messages in the case that
> there was no need for any action at the SIP layer - a PSTN GW
> receiving INFO just passes on the encapsulated ISUP message. A SIP UA
> receiving INFO with encapsulated ISUP ignores it. It will be more work
> to rule out inclusion of SUS/RES in INFO than it would be to support
> it, because I'd have to check the type of the ISUP message to see if
> it was allowed in INFOs.
> 
> Surely what happens to the media stream is orthoganal to the transport
> of the ISUP messages ? As has been said on this thread, Suspend
> may/may not lead to a need to hold the media stream. If you have a
> codec with silence suppression it won't make any difference to the
> bandwidth used anyway.
> 
> contain an ISUP payload when there is no functional relationship
> between the two ?
>