Subject: RE: [Sip] Re: SDP hold

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 1 Aug 2001 02:23:51 -0400

I think that this is a good idea.

-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: Christer Holmberg [mailto:[email-masked]]
> Sent: Wednesday, August 01, 2001 1:17 AM
> To: Paul Kyzivat
> Cc: Gonzalo Camarillo; [email-masked]; mmusic; Colin Perkins; Jonathan
> Rosemberg
> Subject: Re: [Sip] Re: SDP hold
> 
> 
> 
> Hi,
> 
> Can't we use the "inactive" tag, so we don't have to define a new?
> "Inactive" is used by both MGCP and MEGACO when a connection 
> is created,
> but no media is supposed to be sent nor received, so maybe it 
> would be a
> good idea to use the same tag also for SIP.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> Paul Kyzivat wrote:
> > 
> > Gonzalo Camarillo wrote:
> > >
> > > Hello,
> > >
> > > > I know I will remember eventually, but can you remind 
> me of such a
> > > > scenario? I think I recall some cases where you invite 
> on hold, and then
> > > > reinvite. But when would this be used rather than 
> inviting without SDP?
> > >
> > > Actually you INVITE without SDP and get an SDP in the 200 
> OK. Now you
> > > MUST send an SDP in the ACK.
> > >
> > > You MAY try to send an INVITE with the SDP just obtained 
> to the other
> > > party and expect the 200 OK to arrive quickly enough. 
> That is, before
> > > the fist party gets tired of retransmitting the 200 OK 
> without getting
> > > an ACK.
> > >
> > > Luckily you have another option. When you receive the 200 
> OK from your
> > > first INVITE without SDP, you send an ACK with SDP 
> 0.0.0.0 (hold). Then
> > > you INVITE the other party and get his SDP. Now you can 
> re-INVITE the
> > > first party.
> > 
> > OK, that makes some sense. But it is problematic unless it can be
> > depended upon to work all the time, with any type of media. 
> (The 3pcc
> > may not understand the media being used by the endpoints.) 
> I am not sure
> > this is the case.
> > 
> > Also, isn't there a potential problem with this technique?
> > After you re-INVITE the first party with the SDP from the 
> other party,
> > the SDP you get back may not be the same as it was in the 
> first invite.
> > If not, then you have to reinvite the other party again. 
> This process
> > may never terminate.
> > 
> > Seems like it would be better to count on turning around 
> the invite to
> > the other party before the first party times out. It takes 
> a long time
> > to timeout, so this shouldn't usually be a problem.
> > 
> > >
> > > > Where this isn't sufficient, it might be better to 
> simply invite without
> > > > any media sessions at all, just to establish a 
> signalling relationship.
> > > > (But I don't believe that is technically legal at the moment.)
> > >
> > > You INVITE without any media description. The thing is 
> that since you
> > > will get media description in the 200 OK, you MUST send 
> an SDP in your
> > > ACK.
> > 
> > What I meant was that you might invite with the intent of 
> establishing a
> > call that has no media sessions. It isn't straightforward 
> to do, since
> > if you offer SDP that contains no m= lines it is like 
> offering no SDP.
> > You can probably do it by offering an SDP with "m=xxx 0 ...", but
> > probably most UAs would reject this as useless. And in any case it
> > wouldn't serve your purpose.
> > 
> >         Paul
> > 
> > _______________________________________________
> > Sip mailing list  http://www.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
>