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
