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

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 16 Jun 2001 02:21:19 -0400

> -----Original Message-----
> From: Michael Hammer [mailto:[email-masked]]
> Sent: Friday, June 15, 2001 4:19 PM
> To: Gonzalo Camarillo
> Cc: Mark Watson; Jonathan Rosenberg; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Sipping] RE: [SIP] SUS/RES encapsulation
> 
> 
> Comments embedded:
> 
> At 10:55 PM 6/15/2001 +0300, Gonzalo Camarillo wrote:
> >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
> 
> 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?

Just to be clear here, I was not proposing that the SDP have to change, even
if the SUS didn't imply a hold. The proposal was that for the case where SUS
doesn't cause hold, it be encapsulated in a re-INVITE which has the *same*
SDP sent previously. This can be easily detected in the MGC, which then
knows it doesn't need to change anything on the MG. re-INVITE with
unmodified SDP is at the core of the session timer extension.

Mark writes:
>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.

SIP-T is not a generic tunneling and encapsulation protocol. The idea with
SIP-T is to be able to leverage SIPs call control and application
capabilities, while providing ISUP transparency. This means that if an ISUP
message has some semantics which do have an equivalent in SIP, the
functionality should be mapped whenever possible, in addition to the
tunneling. 

As a result, I feel very strongly that if a SUS does imply hold, it MUST
appear within a re-INVITE that sets the SDP to 0.0.0.0. If the SUS has no
semantics outside of the circuit network, I feel less strongly about whether
it can appear in INFO vs. INVITE. I suggested always putting it in the
INVITE for consistency.

-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

_______________________________________________
Sipping mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/sipping