Hi,
o Robert Szokovacs on 11/22/2011 10:31 AM:
Hi,
I have this setup: a B2BUA and a mediaserver, based on SEMS.
The SEMS sends a REFER to the B2BUA which starts to send NOTIFYs according to
the progress of the REFERred call: for example: 100, 183,. 180, 200. One of
the NOTIFY gets lost on the network, lets say the 183, then it's
retransmitted, but before the retransmittion, the 180 is sent and replied:
100->
<--OK(100)
183->
...
180->
<-OK(180)
183(r)->
<-500
(the B2BUA terminates the subscription here)
So the SEMS refuses the retransmitted 183 NOTIFY, because it's cseq is smaller
than the 180's. The SEMS code references the 12.2.2 section of the RFC, I
presume this part:
"
If the remote sequence number was not empty, but the sequence number
of the request is lower than the remote sequence number, the request
is out of order and MUST be rejected with a 500 (Server Internal
Error) response.
"
https://tools.ietf.org/html/rfc3261#section-12.2.2
I guess one of the peers behaviour is wrong, otherwise any random hickup could
terminate the subscription. Which one is the correct behaviour?
i think that the B2BUA should not terminate the subscription on
reception of the 500 (as opposed to 408/481, see 12.2.1.2). 500 error
are often used to make the client retry it at a later point, e.g. to
resolve a glare situation; and the dialog is definitely not terminated
by the 500. The B2B of course is free to terminate the subscription
any time it thinks its appropriate (i.e. this is imo not against the
rfc) with another NOTIFY with status terminated, but it would not make
sense to do so unless e.g. 606 or 408/481 is received.
Also, since the 500 is generated by the AmSipDialog, with reply_error(), which
doesn't call onReplySent(), my application has no way of knowing something
went wrong, and it's statemachine falls apart.
but here only that one request failed - it should not be processed by
the application anyway.
if the B2BUA is ending the (event notification-) dialog created by the
REFER when it receives the 500, it's broken, the 500 reply does not
end that dialog.
so I actually don't see why your application's statemachine should get
confused.
Is there any particular reason reply_error() shouldn't call onReplySent()?
reply_error method is static, and may be called unrelated to a SIP dialog.
don't get me wrong; it would be possible to call onSendReply() from
that point in onRxRequest, but as this request hasn't been accepted as
valid UAS transaction, it could actually break other things.
Stefan
Thank you!
br
Szo
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
--
tel:+491621366449
sip:[email protected]
mailto/xmpp:[email protected]
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
