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
