On 2011. November 22., Stefan Sayer wrote: 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.
Because it expects to see "subscription-state: terminated" in a NOTIFY, but it doesn't. So it's an error the B2BUA. Regarding the original situation: is the retransmission legal? Or sending a new NOTIFY without receiving a 200 for the old one illegal to begin with? TIA br Szo _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
