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? [1] http://track.sipfoundry.org/secure/attachment/20485/trace_179.pcap _______________________________________________ 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/
