I have searched the archive for an answer to this question, and I did not find it. If I missed, I apologize. Please point me in the right direction.
I am having a problem with the pa module of ser (0.8.12). Using ethereal, I see that in response to a SUBSCRIBE, ser will sometimes send an OK and then a NOTIFY. However, other times ser sends the NOTIFY and then the OK. For a single UA sending multiple SUBSCRIBE's to ser, about half of the OK's are sent first and about half of the NOTIFY's are sent first.
This is a problem because I am running the UA behind a SIP-aware firewall which expects the OK first. If the OK is not received, the NOTIFY will not be allowed back through the firewall.
Looking at RFC 3265, 3.1.4.1: "This SUBSCRIBE request will be confirmed with a final response. 200-class responses indicate that the subscription has been accepted, and that a NOTIFY will be sent immediately."
Looking at RFC 3265, 3.1.6.2: "Upon successfully accepting or refreshing a subscription, notifiers MUST send a NOTIFY message immediately to communicate the current resource state to the subscriber. This NOTIFY message is sent on the same dialog as created by the SUBSCRIBE response. <snip> Note that a NOTIFY message is always sent immediately after any 200-class response to a SUBSCRIBE request, regardless of whether the subscription has already been authorized."
My interpretation is that the RFC requires the OK to be sent first. Is that a valid interpretation?
Is there an easy fix for this (perhaps in ser.cfg) or will this require a code change?
Thanks,
Jay
JAY ALLISON wrote:
I have searched the archive for an answer to this question, and I did not find it. If I missed, I apologize. Please point me in the right direction.
I am having a problem with the pa module of ser (0.8.12). Using ethereal, I see that in response to a SUBSCRIBE, ser will sometimes send an OK and then a NOTIFY. However, other times ser sends the NOTIFY and then the OK. For a single UA sending multiple SUBSCRIBE's to ser, about half of the OK's are sent first and about half of the NOTIFY's are sent first.
This is a problem because I am running the UA behind a SIP-aware firewall which expects the OK first. If the OK is not received, the NOTIFY will not be allowed back through the firewall.
Looking at RFC 3265, 3.1.4.1: "This SUBSCRIBE request will be confirmed with a final response. 200-class responses indicate that the subscription has been accepted, and that a NOTIFY will be sent immediately."
Looking at RFC 3265, 3.1.6.2: "Upon successfully accepting or refreshing a subscription, notifiers MUST send a NOTIFY message immediately to communicate the current resource state to the subscriber. This NOTIFY message is sent on the same dialog as created by the SUBSCRIBE response.
<snip> Note that a NOTIFY message is always sent immediately after any 200-class response to a SUBSCRIBE request, regardless of whether the subscription has already been authorized."
My interpretation is that the RFC requires the OK to be sent first. Is that a valid interpretation?
Is there an easy fix for this (perhaps in ser.cfg) or will this require a code change?
I changed the behavior of this in the CVS version in January. Before that, it was sending the notify before generating the response. Currently, it only sends NOTIFY messages from the periodic call to timer_presentity(). I guess the timer could get called before the response is sent. I'll see if I can delay setting the flag indicating that a notify should be sent until after the response is actually sent.
Jamey
jay,
even if 200 ok is sent first, it doesn't mean that it would also arrive to the destination before the following notify if udp transport is used. so the the ua and any firewall must be able to handle the case where notify arrives before 200 ok.
-- juha
-
Jamey Hicks -
JAY ALLISON -
Juha Heinanen