20 Feb
2004
20 Feb
'04
9:24 a.m.
I'm wondering whether people know if there could be a problem
with * receiving retransmissions of INFO/DTMF requests.
I'm trying to play DTMF via INFO to *. If it takes a 200 reply too
long to come back, the request is retransmitted. Whenever this
happens, the IVR down in PSTN reports that the number sequence
is incorrect.
This makes me guess that * turns INFO retransmissions into new
DTMF digits on the PSTN part.
Does anybody have the same experience? Is it a known problem?
Are there any patches?
Thanks,
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
22 Feb
22 Feb
8:52 p.m.
New subject: [Serusers] Re: [Asterisk-Users] INFO/DTMF retransmissions in * not absorbed?
Hi Jiri,
Been there. We switched from INFO to RFC2833 for this same reason.
Take a look at:
http://bugs.digium.com/bug_view_page.php?bug_id=0001033
Not only retransmissions are affected but out of order packets too.
This behaviour can be partly blamed on the RFC:
"In addition, the INFO method does not define additional mechanisms
for ensuring in-order delivery. While the CSeq header will be
incremented upon the transmission of new INFO messages, this should
not be used to determine the sequence of INFO information. This is
due to the fact that there could be gaps in the INFO message CSeq
count caused by a user agent sending re-INVITES or other SIP
messages. "
Regards,
Andres
Jiri Kuthan wrote:
I'm wondering whether people know if there could be
a problem
with * receiving retransmissions of INFO/DTMF requests.
I'm trying to play DTMF via INFO to *. If it takes a 200 reply too
long to come back, the request is retransmitted. Whenever this
happens, the IVR down in PSTN reports that the number sequence
is incorrect.
This makes me guess that * turns INFO retransmissions into new
DTMF digits on the PSTN part.
Does anybody have the same experience? Is it a known problem?
Are there any patches?
Thanks,
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users(a)lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Andres
Network Admin
http://www.telesip.net
24 Feb
24 Feb
2:18 a.m.
New subject: [Serusers] Re: [Asterisk-Users] INFO/DTMF retransmissions in * not absorbed?
Andres,
thanks for your reply. I beg to disagree, here are the arguments:
1) Having INFO is imho a useful thing: it allows elements out of the
media path to control DTMF-based service logic. Otherwise, you
will end up processing media which affects bandwidth and latency
noticably and does not scale.
2) Apart from the out-of-order argument, reprocessing retransmissions
is a bug worth fixing. It is responsibility of transaction layer
to absorb UDP retransmissions and never let app see them.
(Similarly like TCP does not pass retranmissions to apps.) I think
there are more cases for proper transaction processing other than just
DTMF/INFO.
3) out-of-order delivery may or may not be an issue: gnerally, one would
need to mainain a kind of playout buffer like for RTP. O-o-o delivery
does not matter to me personaly since I send DTMF/INFO in stop-and-go mode.
(BTW, I think the text in the RFC is not entirely correct, re-INIVITE
should not cause CSeq gaps. Nevertheless, the RFC does not prevent
anybody from implementing an "INFO playout buffer").
-jiri
On Sun, 22 Feb 2004, Andres wrote:
Hi Jiri,
Been there. We switched from INFO to RFC2833 for this same reason.
Take a look at:
http://bugs.digium.com/bug_view_page.php?bug_id=0001033
Not only retransmissions are affected but out of order packets too.
This behaviour can be partly blamed on the RFC:
"In addition, the INFO method does not define additional mechanisms
for ensuring in-order delivery. While the CSeq header will be
incremented upon the transmission of new INFO messages, this should
not be used to determine the sequence of INFO information. This is
due to the fact that there could be gaps in the INFO message CSeq
count caused by a user agent sending re-INVITES or other SIP
messages. "
Regards,
Andres
Jiri Kuthan wrote:
I'm wondering whether people know if there
could be a problem
with * receiving retransmissions of INFO/DTMF requests.
I'm trying to play DTMF via INFO to *. If it takes a 200 reply too
long to come back, the request is retransmitted. Whenever this
happens, the IVR down in PSTN reports that the number sequence
is incorrect.
This makes me guess that * turns INFO retransmissions into new
DTMF digits on the PSTN part.
Does anybody have the same experience? Is it a known problem?
Are there any patches?
Thanks,
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users(a)lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Andres
Network Admin
http://www.telesip.net
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users(a)lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
5:15 a.m.
New subject: [Serusers] Re: [Asterisk-Users] INFO/DTMF retransmissions in * not absorbed?
Hi Jiri,
I certainly welcome and applaud your comments and suggestions. But I
could not continue to push this issue as an asterisk "bug" since the RFC
did not back me up. Absorbing these SIP INFO retransmissions is more
like a common sense thing/feature that should be implemented in asterisk
rather than an RFC violation, since the RFC is quite vague. If anybody
has the knowledge to implement this feature I can certainly help test it.
Regards,
Andres.
Jiri Kuthan wrote:
Andres,
thanks for your reply. I beg to disagree, here are the arguments:
1) Having INFO is imho a useful thing: it allows elements out of the
media path to control DTMF-based service logic. Otherwise, you
will end up processing media which affects bandwidth and latency
noticably and does not scale.
2) Apart from the out-of-order argument, reprocessing retransmissions
is a bug worth fixing. It is responsibility of transaction layer
to absorb UDP retransmissions and never let app see them.
(Similarly like TCP does not pass retranmissions to apps.) I think
there are more cases for proper transaction processing other than just
DTMF/INFO.
3) out-of-order delivery may or may not be an issue: gnerally, one would
need to mainain a kind of playout buffer like for RTP. O-o-o delivery
does not matter to me personaly since I send DTMF/INFO in stop-and-go mode.
(BTW, I think the text in the RFC is not entirely correct, re-INIVITE
should not cause CSeq gaps. Nevertheless, the RFC does not prevent
anybody from implementing an "INFO playout buffer").
-jiri
On Sun, 22 Feb 2004, Andres wrote:
--
Andres
Network Admin
http://www.telesip.net
Hi Jiri,
Been there. We switched from INFO to RFC2833 for this same reason.
Take a look at:
http://bugs.digium.com/bug_view_page.php?bug_id=0001033
Not only retransmissions are affected but out of order packets too.
This behaviour can be partly blamed on the RFC:
"In addition, the INFO method does not define additional mechanisms
for ensuring in-order delivery. While the CSeq header will be
incremented upon the transmission of new INFO messages, this should
not be used to determine the sequence of INFO information. This is
due to the fact that there could be gaps in the INFO message CSeq
count caused by a user agent sending re-INVITES or other SIP
messages. "
Regards,
Andres
Jiri Kuthan wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
I'm wondering whether people know if there
could be a problem
with * receiving retransmissions of INFO/DTMF requests.
I'm trying to play DTMF via INFO to *. If it takes a 200 reply too
long to come back, the request is retransmitted. Whenever this
happens, the IVR down in PSTN reports that the number sequence
is incorrect.
This makes me guess that * turns INFO retransmissions into new
DTMF digits on the PSTN part.
Does anybody have the same experience? Is it a known problem?
Are there any patches?
Thanks,
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users(a)lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Andres
Network Admin
http://www.telesip.net
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users(a)lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
10:30 a.m.
New subject: [Serusers] Re: [Asterisk-Users] INFO/DTMF retransmissions in * not absorbed?
Andres,
the normative reference for abrorbing retranmissions is in RFC3261 --
INFO/RFC refers to it by telling "all transaction handling is like
for BYE requests". This is the specific piece of text from RFC3261
which explains why not absorbing retransmissions breaks the spec.
Cheeers, -jiri
17.2.2 Non-INVITE Server Transaction
...
Once in the "Trying" state, any further request
retransmissions are discarded. ...
On Mon, 23 Feb 2004, Andres wrote:
Hi Jiri,
I certainly welcome and applaud your comments and suggestions. But I
could not continue to push this issue as an asterisk "bug" since the RFC
did not back me up. Absorbing these SIP INFO retransmissions is more
like a common sense thing/feature that should be implemented in asterisk
rather than an RFC violation, since the RFC is quite vague. If anybody
has the knowledge to implement this feature I can certainly help test it.
Regards,
Andres.
Jiri Kuthan wrote:
Andres,
thanks for your reply. I beg to disagree, here are the arguments:
1) Having INFO is imho a useful thing: it allows elements out of the
media path to control DTMF-based service logic. Otherwise, you
will end up processing media which affects bandwidth and latency
noticably and does not scale.
2) Apart from the out-of-order argument, reprocessing retransmissions
is a bug worth fixing. It is responsibility of transaction layer
to absorb UDP retransmissions and never let app see them.
(Similarly like TCP does not pass retranmissions to apps.) I think
there are more cases for proper transaction processing other than just
DTMF/INFO.
3) out-of-order delivery may or may not be an issue: gnerally, one would
need to mainain a kind of playout buffer like for RTP. O-o-o delivery
does not matter to me personaly since I send DTMF/INFO in stop-and-go mode.
(BTW, I think the text in the RFC is not entirely correct, re-INIVITE
should not cause CSeq gaps. Nevertheless, the RFC does not prevent
anybody from implementing an "INFO playout buffer").
-jiri
On Sun, 22 Feb 2004, Andres wrote:
--
Andres
Network Admin
http://www.telesip.net
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users(a)lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Hi Jiri,
Been there. We switched from INFO to RFC2833 for this same reason.
Take a look at:
http://bugs.digium.com/bug_view_page.php?bug_id=0001033
Not only retransmissions are affected but out of order packets too.
This behaviour can be partly blamed on the RFC:
"In addition, the INFO method does not define additional mechanisms
for ensuring in-order delivery. While the CSeq header will be
incremented upon the transmission of new INFO messages, this should
not be used to determine the sequence of INFO information. This is
due to the fact that there could be gaps in the INFO message CSeq
count caused by a user agent sending re-INVITES or other SIP
messages. "
Regards,
Andres
Jiri Kuthan wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
I'm wondering whether people know if there
could be a problem
with * receiving retransmissions of INFO/DTMF requests.
I'm trying to play DTMF via INFO to *. If it takes a 200 reply too
long to come back, the request is retransmitted. Whenever this
happens, the IVR down in PSTN reports that the number sequence
is incorrect.
This makes me guess that * turns INFO retransmissions into new
DTMF digits on the PSTN part.
Does anybody have the same experience? Is it a known problem?
Are there any patches?
Thanks,
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users(a)lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Andres
Network Admin
http://www.telesip.net
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users(a)lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
7582
days inactive
7586
days old
4 comments
2 participants
participants (2)
-
Andres -
Jiri Kuthan