24 Apr
2012
24 Apr
'12
3:10 p.m.
Hello,
I was wondering if someone here can point quickly where specs mention
what is the right reply code to send when a request within dialog is
received with lower cseq value than the previous request. I couldn't
spot the part in the RFC yet, if any related exists.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
24 Apr
24 Apr
3:17 p.m.
Hi Daniel,
See RFC 3261 section 12.2.2:
If the remote sequence number was not empty, but the sequence number
of the request is lower than the remote sequence number, the request
is out of order and MUST be rejected with a 500 (Server Internal
Error) response.
However, 400 or some 4xx response would seem more reasonable to me, to
let the UAC know it just did something wrong.
And I'm not the only one:
http://comments.gmane.org/gmane.ietf.sip-implementors/8970
On 04/24/2012 02:10 PM, Daniel-Constantin Mierla wrote:
Hello,
I was wondering if someone here can point quickly where specs mention
what is the right reply code to send when a request within dialog is
received with lower cseq value than the previous request. I couldn't
spot the part in the RFC yet, if any related exists.
Cheers,
Daniel
3:27 p.m.
Hello,
thanks, I found that as well, but I didn't wanted to believe is no
update to it in regard to sip client behavior. A phone replying with
such generic code is really misleading for such case . So I searched
further in 4xx class, base rfc and other extensions, and could not find
anything.
Cheers,
Danie
On 4/24/12 2:17 PM, Andrew Pogrebennyk wrote:
Hi Daniel,
See RFC 3261 section 12.2.2:
If the remote sequence number was not empty, but the sequence number
of the request is lower than the remote sequence number, the request
is out of order and MUST be rejected with a 500 (Server Internal
Error) response.
However, 400 or some 4xx response would seem more reasonable to me, to
let the UAC know it just did something wrong.
And I'm not the only one:
http://comments.gmane.org/gmane.ietf.sip-implementors/8970
On 04/24/2012 02:10 PM, Daniel-Constantin Mierla wrote:
> Hello,
>
> I was wondering if someone here can point quickly where specs mention
> what is the right reply code to send when a request within dialog is
> received with lower cseq value than the previous request. I couldn't
> spot the part in the RFC yet, if any related exists.
>
> Cheers,
> Daniel
>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
4:55 p.m.
24 apr 2012 kl. 14:27 skrev Daniel-Constantin Mierla:
Hello,
thanks, I found that as well, but I didn't wanted to believe is no update to it in
regard to sip client behavior. A phone replying with such generic code is really
misleading for such case . So I searched further in 4xx class, base rfc and other
extensions, and could not find anything.
You propably want to add a reason header or something to explain for the poor guy
running wireshark.
The error code is not all.
/O
Cheers,
Danie
On 4/24/12 2:17 PM, Andrew Pogrebennyk wrote:
---
* Olle E Johansson - oej(a)edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
Hi Daniel,
See RFC 3261 section 12.2.2:
If the remote sequence number was not empty, but the sequence number
of the request is lower than the remote sequence number, the request
is out of order and MUST be rejected with a 500 (Server Internal
Error) response.
However, 400 or some 4xx response would seem more reasonable to me, to
let the UAC know it just did something wrong.
And I'm not the only one:
http://comments.gmane.org/gmane.ietf.sip-implementors/8970
On 04/24/2012 02:10 PM, Daniel-Constantin Mierla wrote:
> Hello,
>
> I was wondering if someone here can point quickly where specs mention
> what is the right reply code to send when a request within dialog is
> received with lower cseq value than the previous request. I couldn't
> spot the part in the RFC yet, if any related exists.
>
> Cheers,
> Daniel
>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
5:04 p.m.
Hello,
On 4/24/12 3:55 PM, Olle E. Johansson wrote:
24 apr 2012 kl. 14:27 skrev Daniel-Constantin Mierla:
I would do if I was developing the hard/softphone. So I
was actually
wondering how to detect such situation based on the reply received in
the proxy.
Btw, what Asterisk/Sems does in this situation (just for the developers
of such end points here :-) ), any special hint-header added?
Cheers,
Daniel
Hello,
thanks, I found that as well, but I didn't wanted to believe is no update to it in
regard to sip client behavior. A phone replying with such generic code is really
misleading for such case . So I searched further in 4xx class, base rfc and other
extensions, and could not find anything.
You propably want to add a reason header or something to explain for the poor guy
running wireshark.
The error code is not all.
/O
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Cheers,
Danie
On 4/24/12 2:17 PM, Andrew Pogrebennyk wrote:
---
* Olle E Johansson - oej(a)edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
Hi Daniel,
See RFC 3261 section 12.2.2:
If the remote sequence number was not empty, but the sequence number
of the request is lower than the remote sequence number, the request
is out of order and MUST be rejected with a 500 (Server Internal
Error) response.
However, 400 or some 4xx response would seem more reasonable to me, to
let the UAC know it just did something wrong.
And I'm not the only one:
http://comments.gmane.org/gmane.ietf.sip-implementors/8970
On 04/24/2012 02:10 PM, Daniel-Constantin Mierla wrote:
> Hello,
>
> I was wondering if someone here can point quickly where specs mention
> what is the right reply code to send when a request within dialog is
> received with lower cseq value than the previous request. I couldn't
> spot the part in the RFC yet, if any related exists.
>
> Cheers,
> Daniel
>
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
5:09 p.m.
24 apr 2012 kl. 16:04 skrev Daniel-Constantin Mierla:
Hello,
On 4/24/12 3:55 PM, Olle E. Johansson wrote:
No for Asterisk. It should, really.
/O
24 apr 2012 kl. 14:27 skrev Daniel-Constantin
Mierla:
I would do if I was developing the hard/softphone. So I
was actually wondering how to detect such situation based on the reply received in the
proxy.
Btw, what Asterisk/Sems does in this situation (just for the developers of such end
points here :-) ), any special hint-header added? Hello,
thanks, I found that as well, but I didn't wanted to believe is no update to it in
regard to sip client behavior. A phone replying with such generic code is really
misleading for such case . So I searched further in 4xx class, base rfc and other
extensions, and could not find anything.
You propably want to add a reason header or something to explain for the poor guy
running wireshark.
The error code is not all. 
25 Apr
25 Apr
3:01 p.m.
o Daniel-Constantin Mierla on 04/24/2012 04:04 PM:
Btw, what Asterisk/Sems does in this situation (just
for the
developers of such end points here :-) ), any special hint-header added?
SEMS adds "Retry-After: 0" if the method is NOTIFY. Additionally, you
can now ignore the low CSeq for NOTIFY if ignore_notify_lower_cseq=yes
in sems.conf.
but yes, a Warning would be in order.
Stefan
24 Apr
24 Apr
3:19 p.m.
12.2.2
If the remote sequence number is empty, it MUST be set to the value
of the sequence number in the CSeq header field value in the request.
If the remote sequence number was not empty, but the sequence number
of the request is lower than the remote sequence number, the request
is out of order and MUST be rejected with a 500 (Server Internal
Error) response. If the remote sequence number was not empty, and
the sequence number of the request is greater than the remote
sequence number, the request is in order. It is possible for the
CSeq sequence number to be higher than the remote sequence number by
more than one. This is not an error condition, and a UAS SHOULD be
prepared to receive and process requests with CSeq values more than
one higher than the previous received request. The UAS MUST then set
the remote sequence number to the value of the sequence number in the
CSeq header field value in the request.
If a proxy challenges a request generated by the UAC, the UAC has
to resubmit the request with credentials. The resubmitted request
will have a new CSeq number. The UAS will never see the first
request, and thus, it will notice a gap in the CSeq number space.
Such a gap does not represent any error condition.
o Daniel-Constantin Mierla on 04/24/2012 02:10 PM:
Hello,
I was wondering if someone here can point quickly where specs mention
what is the right reply code to send when a request within dialog is
received with lower cseq value than the previous request. I couldn't
spot the part in the RFC yet, if any related exists.
Cheers,
Daniel
4597
days inactive
4598
days old
7 comments
4 participants
participants (4)
-
Andrew Pogrebennyk -
Daniel-Constantin Mierla -
Olle E. Johansson -
Stefan Sayer