Hi Pavel, For a total novice in SiPp I could have picked an easier project !! Thanks for your detailed response. I will see if I can work through it.
Thanks again On Mon, Apr 15, 2019 at 6:32 PM Šindelka Pavel <sinde...@ttc.cz> wrote: > 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 > listSipp-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/sipp-users > > > _______________________________________________ > Sipp-users mailing list > Sipp-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sipp-users > -- Ed
_______________________________________________ Sipp-users mailing list Sipp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sipp-users
