16 Jun
2004
16 Jun
'04
5:24 p.m.
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