I have used what you suggested below and is working great for us. Thank you!
On Mar 31, 2011, at 7:40 PM, Ovidiu Sas wrote:
Well, in the mean time, you can use the following workaround: let the
phone register over tcp and perform authentication and for subsequent
calls coming from the
On 03/31/2011 03:21 AM, Cindy Leung wrote:
I know I'm doing something bad here. However, we are having a problem with one
of the SIP phones that we support. When it sends out an INVITE and then
CANCEL, the CANCEL is not being forwarded. We are suspecting that it is caused
by a wrong CSeq
I guess I wasn't being clear enough in the call flow. I assume the CSeq in the
CANCEL has to be the same as the second INVITE.
1. Phone sends out INVITE #1, OpenSIPS responds with 401, Phone ACK'd. I
believe the transaction is over at this point.
2. Phone sends out INVITE #2 with auth,
What are you trying to do exactly?
s
Il 31/03/2011 16:37, Cindy Leung ha scritto:
I guess I wasn't being clear enough in the call flow. I assume the CSeq in the
CANCEL has to be the same as the second INVITE.
1. Phone sends out INVITE #1, OpenSIPS responds with 401, Phone ACK'd. I
believe
On Thu, Mar 31, 2011 at 10:37 AM, Cindy Leung cinthia...@gmail.com wrote:
I guess I wasn't being clear enough in the call flow. I assume the CSeq in
the CANCEL has to be the same as the second INVITE.
1. Phone sends out INVITE #1, OpenSIPS responds with 401, Phone ACK'd. I
believe the
I don't mean to step on Cinthia's toe here, but I would like to add a little
to her comments / questions in response some follow ups here. The problem
being presented has been acknowledged as a bad device, in violation of the
RFC. And although it's not popular to work around issues, sometimes it
I assume that this is a hack because the GW is not able to properly
handle the second INVITE (with auth header) that has the same Cseq as
the initial INVITE (despite the fact that those two INVITEs are on
different branch-es). As a workaround, the CSeq was probably tempered
in the local_route.
Thanks for the feedback Ovidiu.
The GW appears to handle the INVITEs fine, which is how the transaction CSeq
gets updated to 2. The problem occurs when we get the CANCEL, which has a
CSeq of 1, not 2. We will investigate some of the ideas you propose here.
We have opened a ticket with the
Based on how the problem was described here, the issue is with how
opensips was configured: the second INVITE sent by opensips should
have the same CSeq as the initial INVITE (assuming that you perform
uac authentication in opensips).
Are you performing uac authentication in opensips?
Regards,
It has more to do with what OpenSIPS is receiving, not sending. We get the
first INVITE from the endpoint, challenge it, then get another INVITE from
the endpoint, and it is incrementing the CSeq on the second INVITE. We have
no control over what the endpoint does with Cseq, unfortunately.
-dg
Are you saying that the caller is sending an INVITE with CSeq 1, get's
challenged, sends back an authenticated INVITE with CSeq 2 and when
the call is aborted, the client that generated the second INVITE with
Cseq 2 is sending a CANCEL with CSeq 1?
Can you post a trace of such scenario?
You can
My first response to this got rejected as I was just over the body size
limit for the forum. I'm posting as an attachment this time:
You are exactly correct in your read back ;) Here is a trace, I think I
removed everything. 1.1.1.1 is my office, where both number and
are registered
The sequence is totally broken.
You can try to modify the Cseq and loop the CANCEL but the proper
thing to do here is to get a fix from the SIP UA manufacturer or get
rid of the phone and use a good one.
Regards,
Ovidiu Sas
On Thu, Mar 31, 2011 at 4:10 PM, Daniel Goepp d...@goepp.net wrote:
My
Thanks Ovidiu,
Yeah, that is pretty much the conclusion we had come to regarding the
endpoint...we were just hoping I guess to have a fix and not have to wait
for the vendor to fix the phone, which will likely take quite some time.
Oh well, that's life :(
-dg
On Thu, Mar 31, 2011 at 3:22 PM,
I know I'm doing something bad here. However, we are having a problem with one
of the SIP phones that we support. When it sends out an INVITE and then
CANCEL, the CANCEL is not being forwarded. We are suspecting that it is caused
by a wrong CSeq value.
INVITE #1 gets challenged.
INVITE #2
Cinthia,
The CSeq needs to be changed before it hits opensips. So you could do
something where if the cancel is not matched, lookup the right cseq
using a memcache lookup (that you stored during the accepted invite)
and send it out to it self with the modified CSeq. I wouldn't be
surprised if
16 matches
Mail list logo
