Can see this thread on mailer. -- Aman
On Fri, Nov 22, 2013 at 10:01 PM, Aman <amanpreeet.si...@gmail.com> wrote: > Hi Folks, > > In a situation, UAC sent REFER message and UAS accept that with 202 > response and further when sending NOTIFY, it has not included the > "subscription expires” parameter in the subscription-state header. > But we also found that UAC never included "timer" extension under > supported or in required header of REFER or the initial INVITE message. > > Is it mandatory to send NOTIFY message with "subscription expires" > parameter even if UAC never mansion about the "timer" in the initial > requests. > > I checked the RFC3515 on this, as per section 2.4.4 Using SIP Events to > Report the Results of the Reference, > > Notice that unlike SUBSCRIBE, the REFER transaction does not contain > a duration for the subscription in either the request or the > response. The lifetime of the state being subscribed to is > determined by the progress of the referenced request. The duration > of the subscription is chosen by the agent accepting the REFER and is > communicated to the agent sending the REFER in the subscription's > initial NOTIFY (using the Subscription-State expires header > parameter). Note that agents accepting REFER and not wishing to hold > subscription state can terminate the subscription with this initial > NOTIFY. > > But as per section 3.4 Subscription Duration, > > The duration of an implicit subscription created by a REFER request > is initially determined by the agent accepting the REFER and > communicated to the subscribing agent in the Subscription-State > header field's expire parameter in the first NOTIFY sent in the > subscription. Reasonable choices for this initial duration depend on > the type of request indicated in the Refer-To URI. The duration > SHOULD be chosen to be longer than the time the referenced request > will be given to complete. For example, if the Refer-To URI is a SIP > INVITE URI, the subscription interval should be longer than the > Expire value in the INVITE. Additional time MAY be included to > account for time needed to authorize the subscription. The > subscribing agent MAY extend the subscription by refreshing it, or > terminate it by unsubscribing. As described in Section 2.4.7, the > agent accepting the REFER will terminate the subscription when it > reports the final result of the reference, indicating that > termination in the Subscription-State header field. > > Above section and example below is giving me second though as UAC has not > provided the expire value and not even the “Timer support” in the initial > INVITE or REFER request. > > > 4. Examples > 4.1 Prototypical REFER callflow > > Message Three (F3) > > NOTIFY sip:a...@atlanta.example.com SIP/2.0 > Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9922ef992-25 > To: <sip:a...@atlanta.example.com>;tag=193402342 > From: <sip:b...@atlanta.example.com>;tag=4992881234 > Call-ID: 898234...@agenta.atlanta.example.com > CSeq: 1993402 NOTIFY > Max-Forwards: 70 > Event: refer > Subscription-State: active;expires=(depends on Refer-To URI) > Contact: sip:b...@atlanta.example.com > Content-Type: message/sipfrag;version=2.0 > Content-Length: 20 > > > Sounds like RFC is not much clear on this situation, if someone please > share their views on correct behavior of this. > > > Cheers, > Aman > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
