> I'm looking at one of the traces in XX-6244 [1], and noticed > a problem with how we're sending the initial NOTIFY in a > subscribe dialog. I don't _think_ that it's the source of > that problem in that issue, but it is related and could cause > problems in cases of forked subscribe requests. > > In the standard initial subscription handshake: > > UAC UAS > | | > +---SUBSCRIBE--------->| > | | > |<-----202 Accepted----+ > | | > |<-----NOTIFY----------+ > +------200 Ok--------->| > | | > > the 202 response to the SUBSCRIBE and the initial NOTIFY can > occur in either order - that is, the UAS may send them in > either order and the UAC must be prepared to receive them in > either order. In the case in which a SUBSCRIBE request is > forked in a proxy, the UAC may in fact not ever get the 202 > for some subscriptions (if the request forks to multiple uASs > that accept it, only one of the 202 responses can be > forwarded by the proxy); in this case, the initial NOTIFY > must be treated as dialog-forming by the UAC. > > In order for this to work correctly, this means that the > initial NOTIFY in a new subscribe dialog must have a > Record-Route header identical to the one in the 202 Accepted > response for the dialog. That's the only way that the route > set can be established correctly for the dialog when the > NOTIFY arrives at the UAC first and/or the 202 is dropped in > the proxy. > > Our subscription code is not doing this in this case: the 202 > response has a Record-Route, but the initial NOTIFY (which is > sent before the > 202) does not. > > This may or may not be related to the particular issue (tbd), > but it certainly will bite us one way or another eventually, > so I think we need to open an issue and fix it. Comments?
I agree that this should be fixed. The record-route is the only means we have to attach some state information to a dialog so having it work reliably is indeed a very desirable behavior. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
