Hello, the only step I'd not be sure of is how the operating system will deal with SIPp asking to open a socket on a multicast address. So that's the first thing to try. You'll have to assign the multicast address to an interface first, in addition to a unicast one, by means of the operating system. You can only use IP addresses which are already up in the system as values of -i and other command line parameters of SIPp).
The next issue is that I would assume that the 200 OK response to the SUBSCRIBE as well as the NOTIFY have to be sent from, and the 200 OK response to the NOTIFY may be expected on, a unicast address of the server. To achieve that, you'll need to run two scenarios in parallel, one bound to the multicast address and only handling the reception of the SUBSCRIBE and the other one bound to the unicast one and handling all the rest. The scenario bound to the multicast address will expect the SUBSCRIBE to arrive and forward all its headers (using the [last-*] keywords) to the other scenario by means of <sendCmd>. The other scenario will use <action> and <ereg> in <recvCmd> to extract from the received inter-scenario message the contents of Contact and other headers it needs to use to populate the headers of the NOTIFY and of the 200 OK response to the SUBSCRIBE, use <setdest> to set the destination for the 200 OK response to the subscribe it will send send to the socket address extracted from the topmost Via header of the SUBSCRIBE, send the 200 OK, then use <setdest> again to set the destination for the NOTIFY to the socket address extracted from the Contact, send the NOTIFY with the necessary Content and with Subscription-State set to terminated;reason=noresource to properly terminate the dialog initiated by the SUBSCRIBE instead of having to handle the unsubscription request coming from the phone, and wait for the 200 OK response to that NOTIFY from the phone. The double <setdest> may be an overkill in most real life cases, but in general the phone may indicate a different socket in the Via (for the response to the current request) and in the Contact (for subsequent requests within the same dialog). Also, something is telling me that a scenario decides whether to behave as an UAS or UAC depending on whether <recv> or <send> is the first tag in the file even if a <recvCmd> precedes it, so you'll have to put <recv request=SUBSCRIBE optional="true"/> before the <recvCmd> in the scenario bound to the unicast socket to make it act as an UAS one although the optional SUBSCRIBE will actually never come. Pavel Dne 15.4.2019 v 20:14 Ed Lentz napsal(a): I am trying to get a PNP server working so I can send a url to my SIP based phones. Here is the sequence that has to happen: Phone sends a subscribe message to 224.0.1.75 Server sends an OK back to the phone Server sends a Notify to the phone to check-sync along with the URL Phone sends back a OK phone contacts the url address to download the appropriate files. Is this something SIPp can handle? If so How would I start? Thanks -- _______________________________________________ Sipp-users mailing list Sipp-users@lists.sourceforge.net<mailto:Sipp-users@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/sipp-users
_______________________________________________ Sipp-users mailing list Sipp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sipp-users
