Pavel, Your first concern is not a concern. The system I would be running SIPp on is a Freepbx based system. I have been running other PNP python scripts and the Multicast addresses are allowed by default.
On Tue, Apr 16, 2019 at 8:34 AM Ed Lentz <ele...@gmail.com> wrote: > 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 > -- Thank you Ed Lentz VP of Technical Operations CQ Simple LLC 5103 Eastman Ave. Ste 125 Midland, Mi USA 48640 989-492-7068
_______________________________________________ Sipp-users mailing list Sipp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sipp-users
