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 <sinde...@ttc.cz
<mailto: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
<mailto:Sipp-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/sipp-users
<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
