I missed that. The ack is correctly being sent in response to the 200 OK. I further debugged, there are two issues: 180 Ringing uses [last_Via:] but in the trace, I can see all the Via header values comma separated, instead of CRLF and the "Via:" prepended.
I think if this is resolved, valid values will appear in the [routes] On Thu, Aug 25, 2016 at 12:43 PM, sindelka <sinde...@ttc.cz> wrote: > Hello Ahmad?Owais (sorry, both may be used as first names), > > > UAS receives an ACK in response to its 180 Ringing > > sending ACK upon reception of 180 is too early - only reception of a > final response (i.e. with response codes 200 and above) is to be > confirmed by an ACK. So modify your scenario accordingly and you'll be > fine. > > > Record routes are only being added in INVITE packets although I use > rrs="true" in recv and I add [routes] in all subsequent send sections. > > That's a misunderstanding. > First, SIPp doesn't add anything automatically to the messages. So if > you want the record-route header(s) to be present in the ACK your > scenario sends, you must place them to the source code of the ACK, like > you did in the INVITE. > Second, rrs="true" is an attribute of <recv request>, allowing to store > the route set received in an incoming request for use in outgoing > requests. To mirror the record-route header in the response to an > incoming request, [last_Record-Route:] keyword is used, as with any > other header which needs to be copied from the request to the response. > Only for upstream requests you need to copy the route list previously > received in Record-Route into the Route header of the outgoing request. > So in an UAC scenario, you basically never need to use rrs. In an UAS > one, you use rrs="true" when receiving requests, and if you want to send > a BYE yourself, you have to put the keyword [routes] into the source > code of the BYE. If there was a Record-Route header in the last received > request with rrs="true", your BYE will contain a properly filled Route: > header; if there wasn't, there will be no Route: header, nor an empty > line. The same applies for [last_Record-Route] in the responses. So it > is safe to make your scenarios universal this way, regardless whether > the remote party uses Record-Route headers in its requests or not. > > Pavel > > > > ------------------------------------------------------------ > ------------------ > _______________________________________________ > Sipp-users mailing list > 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
