If it generically works, it should work also for the dialog pinging - the idea
with my patch is , for replies (which may have the cseq affected) to take the
cseq from the request stored in the transaction (so the original cseq).
I will upload the patch on GIT and do the backport. Maybe @saghul
Closed #165 via acb1b378e59fc2f7608e566347ceebd5f4159210.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/165#event-136899380___
Devel mailing list
Devel@lists.opensips.org
In-dialog requests (re-INVITEs) would also have the CSeq modified if dialog
pinging is enabled. We need to get the updated CSeq for both requests and
responses, is this handled?
---
Reply to this email directly or view it on GitHub:
Hello,
It works in our use case, both in 1.8.4 and 1.11.1, thanks.
But I can't tell for cseq pinging.
Regards.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/165#issuecomment-47633448___
Devel mailing
@saghul correct me if I'm wrong, but the by the in-dialig support added by
you in cseq fetching, the whole idea is to have the same cseq value for the
request and it's reply (that was broken if using the in-dialog pinging, as
request had the original cseq while its replies the dialog updated
@bogdan-iancu what we need is a way to fetch the actual cseq for a given
request or reply. Regardless of cseq mangling happening or not. Otherwise
MediaProxy could get confused because it relies on incrementing cseqs.The code
there was written before dialog pinging was a thing, so it may need
1) the cseq's seen by mediaproxy are incremental, no worries :)
2) as changing the cseq on proxy, you can see (in a consistent way) either the
original cseq values, either the changed values; in this particular case you
will see the original values (incremental and consistent across
Hi @adrien-martin , please try the attached patch which should solve the both
problems : cseq pinging and various formats of the cseq header -
https://gist.github.com/bogdan-iancu/f860eb15d4d2df3f0b17
---
Reply to this email directly or view it on GitHub:
Hum, unfortunately it doesn't work.
I don't use dialog ping (assuming it is a ping with dialog module).
Sending a trace by mail.
With some more custom logs (in the if statement, as it matches in both cases):
NOTICE:mediaproxy:get_cseq_number: trans-cseq_n.s: 'CSeq:2',
trans-cseq_n.len: '6'
Ah, I see. The fun fact here is that, that field should contain just the number
(according to the comments in the code), yet it doesn't. In the initial version
of the code I advanced the pointer by CSEQ_LEN, which is defined as the length
of CSeq: (note the space after the colon).
I think
Hum, ok.
I think finding the ':' could be a good solution too, I never encountered such
a case but some UAC could insert some spaces before ':'.
---
Reply to this email directly or view it on GitHub:
Hum, something feels wrong here. I did some git archeolgy and looks like I
modified that code to look the way it does now in order for it to work with
dialog pings:
https://github.com/OpenSIPS/opensips/commit/80511207e9acec1bfabed7807a83329a8adebbce
When dialog ping is used OpenSIPS needs to
Here is another patch: https://gist.github.com/saghul/8983424 can you please
try it out?
@vladpaiu, IIRC you wrote the dialog ping logic, does what I did there look
good to you?
---
Reply to this email directly or view it on GitHub:
@adrien-martin can you please test if it works after applying the following
patch? https://gist.github.com/saghul/8952340
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/165#issuecomment-34851588___
It works, the connection data field in SDP is correctly set are there are no
errors in logs.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/165#issuecomment-34867972___
Devel mailing list
Thanks for confirming, I'll commit the changes later today.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/165#issuecomment-34868870___
Devel mailing list
Devel@lists.opensips.org
Thanks for your patch!
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/165#issuecomment-34870552___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
The pseudo-variable $cs seems to work.
When in debug mode, it print the line: DEBUG:core:get_hdr_field: cseq CSeq:
2 INVITE
$cs value is '2', $hdr(cseq) value is '2 INVITE', and the sip line is 'CSeq:2
INVITE'.
Regards.
---
Reply to this email directly or view it on GitHub:
Hum, I'll look into it, thanks for the test!
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/165#issuecomment-34614574___
Devel mailing list
Devel@lists.opensips.org
I just checked and we don't really parse the packet but use the provided
functions to extract the value. Does pseudo-variable which extracts the CSeq
work for you?
---
Reply to this email directly or view it on GitHub:
20 matches
Mail list logo
