Subject: RE: [Sip] "t=" in 200

From: Baniel Uri-CUB001 <[email-masked]>
Date: Thu, 2 Aug 2001 11:53:13 -0500

Gonzalo

Let me be more specific. Say a UAC send t= 0 0 (for an ad hock session) but
the UAS likes to accept the call in 20 seconds, i.e. sends an immediate OK,
but wish to have the RTP ports open up only 20 seconds later on.

Would this be legal? (or is it non negotiable as you say...)

Uri

=======================================================================
[email-masked], 
Tel: (847) 632 4616; Fax: (847) 632 3963; 
"If it wasn't for bad luck, I would not have luck at all" - Cream 1968
=======================================================================

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Thursday, August 02, 2001 11:57 AM
> To: Baniel Uri-CUB001
> Cc: [email-masked]'
> Subject: Re: [Sip] "t=" in 200
> 
> 
> Hello,
> 
> > Is it allowed for a UAS to change the original value of the 
> SDP "t=" field in its 200 response?
> 
> 
> The t value is typically intended to be used for pre-arranged events.
> That is, the evening news will be multicast from 9 pm thru 10 pm.
> 
> The SDP of an INVITE for an "ad-hoc" session typically contains t=0 0,
> since there is no pre-established duraction for the session. When the
> session is over, a BYE will be sent.
> 
> So, if you receive an INVITE for a pre-arrange session (for 
> example, the
> evening news from 9 thru 10), it means that the multicast (in this
> example) will begin at 9 and finish at 10. If you answer with a
> different t= value it just means that you will leave the multicast
> session before or after it has finished, but it does not make any
> difference.
> 
> So, to answer you question, t= is nothing that you negotiate. You can
> send a BYE whenever you want, regardless of the t= value.
> 
> Regards,
> 
> Gonzalo
> 
> > 
> > > =============================================
> > > [email-masked],
> > > Tel: (847) 632 4616; Fax: (847) 632 3963;
> > > "I was down since I began to crawl" Cream 71
> > > =============================================
> > >
> > >
> > 
> > _______________________________________________
> > 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
> 
> -- 
> 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]
> 

_______________________________________________
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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 02 Aug 2001 20:10:21 +0300

Hello,

That would be legal, because the session you are actually accepting in
the one that you are sending in the 200 OK. However, no UA supports
this.

So, when I said that this was not negotiable, I meant that nobody
implements this for ad-hoc sessions. It seems more reasonable to use a
retry-after header.

Regards,

Gonzalo