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

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 15 Jun 2001 22:55:33 +0300

Hello,

I believe that everybody agrees that if the gateway wants to stop the
media while the call is SUSpended, the SUS has to be sent in a re-INVITE
with SDP 0.0.0.0

When the gateway does not want to stop the media, we have three
possibilities. I personally am happy with any of them.

1) The SUS is sent in an INFO
Pros: Easier implementation for gateways. They just receive the SUS, and
since no SIP operation is needed, they just encapsulate the message in
an INFO (as any other ISUP message that does not require SIP operation)
and send the INFO out.

Cons: A gateway will have to expect SUS messages in both re-INVITEs and
INFOs

2) The SUS is sent in a re-INVITE with the same SDP as before (refresh)
Pros: Gateways will expect SUSs to arrive just in re-INVITEs
 
Cons: Gateways have to handle SUS as a special message that does not
require SIP operation but has to be sent in a re-INVITE rather than in
an INFO

3) We allow both behaviors
Pros: Implementors use the method that is easier for them to implement. 

Cons: A gateway will have to expect SUS messages in both re-INVITEs and
INFOs

I do not see a big deal here. I believe that we can go for the 3rd
solution and forget about the issue. This is a small issue and I would
not like to have a 3 million-message discussion thread about it.

If folks really dislike solution number 3, I would like to get the
opinion of people actually implementing this, since the only advantage
or disadvantage that I find when I compare solutions number 1 and 2 is
that one might be easier to implement than the other.

However, from the feedback I have received so far, the INFO solution is
easier to implement in gateways that will never stop the media path
upone reception of SUS. They will never use re-INVITEs for SUS, so they
will implement a rule saying that all incoming SUSs go inside an INFO.

The re-INVITE solution is easier to implement for gateways that offer
the option of stopping or not stopping the media path as a configuration
parameter. They implement a rule saying that all incoming SUS are sent
in re-INVITEs. Then, they will place the proper SDP body (0.0.0.0 or
refresh) depending on that configuration parameter.

Anyway, one way or the other this small issue MUST be resolved before
the middle of next week.

Best regards,

Gonzalo

Mark Watson wrote:
> 
> Gonzalo,
> 
> See comments below...
> 
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:[email-masked]]
> > Sent: 14 June 2001 18:35
> > To: Watson, Mark [MAIFP:EP11-M:EXCH]
> > Cc: Jonathan Rosenberg; 'Michael Hammer'; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: Re: [Sipping] RE: [SIP] SUS/RES encapsulation
> >
> >
> > 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.
> >
> 
> I don't recall seeing agreement on this topic. To my mind, leaving the
> SUS in an INFO is *more* coherant - why make an exception for this
> single message type. I really do not want to have to look inside INFO
> messages to see what the ISUP message type is - I just want to pass
> this ISUP message onwards whatever.
> 
> I'm not even sure it makes sense to break out the two cases above -
> ISUP messages are encapsulated in SIP message bodies in exactly the
> same way, whatever the message type. I really don't see the problem
> with allowing ISUP messages to be encapsulated in any appropriate SIP
> message type.
> 
> We should be trying to keep the layers logically as separate as
> possible. Where there is a functional linkage (e.g. INVITE <> IAM)
> then we describe this, but where there is not there is no need for
> arbitrary rules.
> 
> Sending of SUS/RES at the ISUP layer and holding of the media stream
> at the SDP layer should be logically independent actions because one
> can happen without the other, and vice-versa.
> 
> 
> > 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.
> 
> I disagree. I think it's simpler if we keep the operations
> independent:
> Holding the media stream is performed with a Re-INVITE.
> Sending of SUS/RES (or any ISUP message) is done by encapsulating in a
> SIP message body. If a SIP message is being sent anyway we use that,
> if no SIP message is being sent we use an INFO.
> 
> This is usual practice in encapsulation schemes (in my experience) -
> the encapsulated protocol pays as little attention as possible to the
> types of messages in the encapsulating protocol.
> 
> Regards...Mark
> 
> >
> > 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:
> > >
> > > 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
> > >
> 
> --
> 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

-- 
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: Michael Hammer <[email-masked]>
Date: Fri, 15 Jun 2001 16:20:28 -0400

p.s.  This may really be an implementation detail that depende on what the 
implementor wants to do with the RTP stream.

Mike

---

From: Michael Hammer <[email-masked]>
Date: Fri, 15 Jun 2001 16:18:53 -0400

Comments embedded:

>media while the call is SUSpended, the SUS has to be sent in a re-INVITE

I'm not sure who the everybody is here, I have only heard a couple of 
voices and it is by no means unanimous.

I believe that it is highly likely that if there is a SUS, then there will 
be no media to transmit over the SDP anyway, and as Mark pointed out, the 
silence suppression will automatically kick in and throttle the RTP 
stream.  By changing the SDP you force some interactions with MGCP or H.248 
if the network uses MGCs.  I'm not convinced that we need to increase the 
message flow to the media gateways and between media gateways for this 
situation, when the RTP management can be done autonomously, automatically, 
and probably far faster.  Why the extra complexity?

>require SIP operation but has to be sent in a re-INVITE rather than in

Don't forget to add the additional work needed to modify the RTP streams 
based on SDP changes.

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 15 Jun 2001 10:39:11 +0100

Gonzalo,

See comments below...

> will be encapsulated in the same way - always in a re-INVITE.

I don't recall seeing agreement on this topic. To my mind, leaving the SUS
in an INFO is *more* coherant - why make an exception for this single
message type. I really do not want to have to look inside INFO messages to
see what the ISUP message type is - I just want to pass this ISUP message
onwards whatever.

I'm not even sure it makes sense to break out the two cases above - ISUP
messages are encapsulated in SIP message bodies in exactly the same way,
whatever the message type. I really don't see the problem with allowing ISUP
messages to be encapsulated in any appropriate SIP message type.

We should be trying to keep the layers logically as separate as possible.
Where there is a functional linkage (e.g. INVITE <> IAM) then we describe
this, but where there is not there is no need for arbitrary rules.

Sending of SUS/RES at the ISUP layer and holding of the media stream at the
SDP layer should be logically independent actions because one can happen
without the other, and vice-versa.
 
> 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

I disagree. I think it's simpler if we keep the operations independent:
Holding the media stream is performed with a Re-INVITE.
Sending of SUS/RES (or any ISUP message) is done by encapsulating in a SIP
message body. If a SIP message is being sent anyway we use that, if no SIP
message is being sent we use an INFO.

This is usual practice in encapsulation schemes (in my experience) - the
encapsulated protocol pays as little attention as possible to the types of
messages in the encapsulating protocol.

Regards...Mark

> 
> However, as you also point out, a SIP entity (gateway or UA) receiving
> > I am confused that we are now making rules about which ISUP messages
> > 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.
> > 
> > > > > >(which has received the SUS and which will subsequently send
> > > > > a re-INVITE or
> > > > > >react to the suspension of the PSTN leg of the call. In some
> > > > > networks it