Menu
▾
▴
Re: [Sipp-users] sipp INVITE with media
|
From: sindelka <sin...@tt...> - 2016-08-25 08:52:27
|
Sorry, ignore my last message, I've sent it prematurely. The complete version follows. > 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. Header: item1, item2 and Header: item1 Header: item2 are fully equivalent. So unless the device under test has a bug preventing it from handling a comma-separated list of Via uris, this is also not the reason of your trouble. > I think if this is resolved, valid values will appear in the [routes] Via: has nothing to do with [routes]. [routes] expands to a list of routes received in Record-Route in the opposite direction (if rrs="true" was used), with Route: as a header name. example: incoming INVITE: ... Record-Route: route1, route2 Record-Route: route3 ... in the 200 to that INVITE if [last_Record-Route:] is present in the 200's source code, regardless whether rrs="true" was used in its <recv request>: ... Record-Route: route1, route2, route3 ... in the outgoing BYE if rrs="true" was used in <recv request> of the INVITE and the [routes] keyword was used in the BYE's source code: ... Route: route1, route2, route3 ... P. Dne 25.8.2016 v 10:45 sindelka napsal(a): > > Hi, > > > 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. > > Header: item1, item2 > > and > > Header: item1 > Header: item2 > > are fully equivalent. So unless the device under test has a bug > preventing it from handling a comma-separated list of Via uris, this > is also not the reason of your trouble. > > > > I think if this is resolved, valid values will appear in the [routes] > > Via: has nothing to do with [routes]. [routes] expands to a list of > routes received in Record-Route in the opposite direction (if > rrs="true" was used), with Route: as a header name. > > example: > > incoming INVITE: > > Record-Route: route1, route2 > Record-Route: route3 > > 200 to that INVITE regardless whether rrs=true was used and > [last_Record-Route:] is present in the 200's source code: > Record-Route: route1, route2, route3 > > outgoing BYE if > > Route: route1, route2, route3 > > P. > > > Dne 25.8.2016 v 9:56 Owais Ahmad napsal(a): >> 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 <sin...@tt... >> <mailto:sin...@tt...>> 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 >> Sip...@li... >> <mailto:Sip...@li...> >> https://lists.sourceforge.net/lists/listinfo/sipp-users >> <https://lists.sourceforge.net/lists/listinfo/sipp-users> >> >> > |