What does the subscription timeout consist of, is it mostly the terminating ring timeout and some processing delay?
In the telecom world, the transferor is in effect, indefinately subscribed to the state of the transferee, unless the transferor gets tired and hangs up, or the transferee does'nt pick the call. In that sense, so long as the transferee ring timeout has not expired, the "subscription" does not expire, hence on the SIP side, the subscription interval is probably of the order of the ring timeout plus processing time, and in that case, requesting an extention is probably not going to be of much use, as an expired subscription logically means that the transferee did not pick the call on time. Is this argument accurate? Kedar On 7/26/06, Frank Shearar <[EMAIL PROTECTED]> wrote: > > My first recommendation below is bogus. That is, RFC 3265 says in section > 3.1.1 that > > 200-class responses to SUBSCRIBE requests also MUST contain an > "Expires" header. The period of time in the response MAY be shorter > but MUST NOT be longer than specified in the request. The period of > time in the response is the one which defines the duration of the > subscription. > > so the transferee ALWAYS uses expiry with REFER. Thus, the transferor had > better resubscribe timeously. > > frank > > ----- Original Message ----- > From: "Frank Shearar" <[EMAIL PROTECTED]> > To: "SIP Implementors" <[email protected]> > Sent: Wednesday, July 26, 2006 10:18 AM > Subject: Re: [Sip-implementors] REFER's implicit subscription times > out.Resubscribe how? > > > > As Somesh says, a REFERred UA typically ends the subscription with > > reason=noresource. > > > > I think the lesson here is that, as RFC 3515 says, the subscription is > > implicit, and doesn't have a fixed expiry date. It expires when the far > side > > succeeds, fails or declines the transfer. > > > > Thus, I'd say that ideally (using call transfer terminology) > > (a) the transferee shouldn't use expiry at all with REFER, and > > (b) if she does, the transferor had better make sure she resubscribes to > the > > REFER timeously. > > > > Thanks! > > > > frank > > > > ----- Original Message ----- > > From: "Paul Kyzivat" <[EMAIL PROTECTED]> > > To: "Frank Shearar" <[EMAIL PROTECTED]> > > Cc: "SIP Implementors" <[email protected]> > > Sent: Tuesday, July 25, 2006 6:51 PM > > Subject: Re: [Sip-implementors] REFER's implicit subscription times out. > > Resubscribe how? > > > > > > > Yes, in this case you are out of luck. You can't get back to that > > > subscription. > > > > > > Paul > > > > > > Frank Shearar wrote: > > > > Following on from my previous question, say I send A a REFER. A > tells > me > > the > > > > subscription's duration. I'm too lazy to respond quick enough with a > > > > resubscription, and A sends me a NOTIFY with "Subscription-State: > > > > terminated;reason=timeout". > > > > > > > > How can I resubscribe? > > > > > > > > Remember that RFC 3515 says "follow the procedure in RFC 3265". RFC > 3265 > > > > says in section 3.2.4 "Subscriber NOTIFY Behavior" > > > > > > > > timeout: The subscription has been terminated because it was not > > > > refreshed before it expired. Clients MAY re-subscribe > > > > immediately. The "retry-after" parameter has no semantics for > > > > "timeout". > > > > > > > > Of course, if you try that with a REFER you end up creating a > SUBSCRIBE > > with > > > > "Event: refer" that does not match any existing subscription, and A > > rightly > > > > rejects the SUBSCRIBE with a 403 Forbidden (as per RFC 3515 section > > 2.4.4). > > > > > > > > Is it simply the case that you CAN'T resubscribe this implicit > REFER? > If > > I > > > > sent another REFER, it's not quite the same as a normal SUBSCRIBE. > (I'm > > not > > > > asking for state change notifications, I'm asking A to do > something.) > > > > > > > > frank > > > > > > > > _______________________________________________ > > > > Sip-implementors mailing list > > > > [email protected] > > > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > > > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
