Bug in SIP URI: ; received="XX.XX.XX.XX:XXXX" is not valid (SIP BNF)
Hi, when FS calls to a natted user, it generates an INVITE with a Request URI as follows: INVITE sip:user@XX.XX.XX.XX:XXXX;transport=udp;received="XX.XX.XX.XX:XXXX" SIP/2.0 Well, this is not valid since a SIP URI parameter cannot contain quote symbol ("). You can verify it in RFC 3261 - page 222 (look for "other-param"): ------------ uri-parameters = *( ";" uri-parameter) uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / other-param transport-param = "transport=" ( "udp" / "tcp" / "sctp" / "tls" / other-transport) other-transport = token user-param = "user=" ( "phone" / "ip" / other-user) other-user = token method-param = "method=" Method ttl-param = "ttl=" ttl maddr-param = "maddr=" host lr-param = "lr" other-param = pname [ "=" pvalue ] pname = 1*paramchar pvalue = 1*paramchar paramchar = param-unreserved / unreserved / escaped param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" ------------- This causes Twinkle sofphone droping the incoming request since it's malformed. Quote symbol (") should not be used in a SIP URI parameter in order to be SIP compliant. Since I just use Twinkle (the best and more SIP compliant softphone for Linux) I can't test FreeSwitch for now :( Best regards. -- Iñaki Baz Castillo
El Miércoles, 19 de Noviembre de 2008, Iñaki Baz Castillo escribió:
Quote symbol (") should not be used in a SIP URI parameter in order to be SIP compliant.
Hi, I've opened a bug for this (probably I should do it instead of reporting the bug in the maillist): http://jira.freeswitch.org/browse/SFSIP-102 Regards. -- Iñaki Baz Castillo
you'll see where sip compliance gets you ;) On Tue, Nov 18, 2008 at 6:04 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
Hi, when FS calls to a natted user, it generates an INVITE with a Request URI as follows:
INVITE sip:user@XX.XX.XX.XX:XXXX;transport=udp;received="XX.XX.XX.XX:XXXX" SIP/2.0
Well, this is not valid since a SIP URI parameter cannot contain quote symbol ("). You can verify it in RFC 3261 - page 222 (look for "other-param"):
------------ uri-parameters = *( ";" uri-parameter) uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / other-param transport-param = "transport=" ( "udp" / "tcp" / "sctp" / "tls" / other-transport) other-transport = token user-param = "user=" ( "phone" / "ip" / other-user) other-user = token method-param = "method=" Method ttl-param = "ttl=" ttl maddr-param = "maddr=" host lr-param = "lr" other-param = pname [ "=" pvalue ] pname = 1*paramchar pvalue = 1*paramchar paramchar = param-unreserved / unreserved / escaped param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" -------------
This causes Twinkle sofphone droping the incoming request since it's malformed. Quote symbol (") should not be used in a SIP URI parameter in order to be SIP compliant.
Since I just use Twinkle (the best and more SIP compliant softphone for Linux) I can't test FreeSwitch for now :(
Best regards.
-- Iñaki Baz Castillo
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
2008/11/19 Anthony Minessale <anthony.minessale@gmail.com>:
you'll see where sip compliance gets you ;)
Well, I'm a SIP guy (even if I know that SIP related RFC's are written by people from other galaxy). But I just expect that I can use Twinkle softphone (the most compliant SIP sofphone) with FreeSwitch (this is not possible now due to the FS bug I've reported). :) -- Iñaki Baz Castillo <ibc@aliax.net>
lets get an interop going then. can you open the issue in jira http://jira.freeswitch.org will the twinkle author cooperate? The problem with being the most sip compliant "whatever" is the key to interop is bending on both sides. On Wed, Nov 19, 2008 at 3:43 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
2008/11/19 Anthony Minessale <anthony.minessale@gmail.com>:
you'll see where sip compliance gets you ;)
Well, I'm a SIP guy (even if I know that SIP related RFC's are written by people from other galaxy). But I just expect that I can use Twinkle softphone (the most compliant SIP sofphone) with FreeSwitch (this is not possible now due to the FS bug I've reported). :)
-- Iñaki Baz Castillo <ibc@aliax.net> _______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
2008/11/19 Anthony Minessale <anthony.minessale@gmail.com>:
lets get an interop going then. can you open the issue in jira http://jira.freeswitch.org
Hi, in my second mail in this thread I already open a bug report that is already being handled: http://jira.freeswitch.org/browse/SFSIP-102
will the twinkle author cooperate?
Well, I will contact him sure. Anyway, I can sure you that my report is 100% correct (I've long exprience with SIP BNF grammar since I've done my own SIP parser trying to be fully SIP compliant and totally strict).
The problem with being the most sip compliant "whatever" is the key to interop is bending on both sides.
Sure, but again I can sure you that, in this case, Twinkle is correct but FS is not (FS creates an invalid SIP URI). Thanks for all, hope you developers could solve this small issue so I can use Twinkle to try FS. Be sure that I will examinate, test and force FS SIP stack all I can and will report issues if they appear ;) Best regards. -- Iñaki Baz Castillo <ibc@aliax.net>
We can follow up on the bug on this, but brian and I were testing this last night, it seems to work fine in our code, but I want to make sure there are no devices that expect it the other way, so we can post the patch we worked up last night but it will need some level of interop with different devices to make sure we don't have a regression we have to find out how to address. Mike On Nov 19, 2008, at 9:44 AM, Iñaki Baz Castillo wrote:
2008/11/19 Anthony Minessale <anthony.minessale@gmail.com>:
lets get an interop going then. can you open the issue in jira http://jira.freeswitch.org
Hi, in my second mail in this thread I already open a bug report that is already being handled: http://jira.freeswitch.org/browse/SFSIP-102
will the twinkle author cooperate?
Well, I will contact him sure. Anyway, I can sure you that my report is 100% correct (I've long exprience with SIP BNF grammar since I've done my own SIP parser trying to be fully SIP compliant and totally strict).
The problem with being the most sip compliant "whatever" is the key to interop is bending on both sides.
Sure, but again I can sure you that, in this case, Twinkle is correct but FS is not (FS creates an invalid SIP URI).
Thanks for all, hope you developers could solve this small issue so I can use Twinkle to try FS. Be sure that I will examinate, test and force FS SIP stack all I can and will report issues if they appear ;)
2008/11/19 Michael Jerris <mike@jerris.com>:
We can follow up on the bug on this, but brian and I were testing this last night, it seems to work fine in our code, but I want to make sure there are no devices that expect it the other way, so we can post the patch we worked up last night but it will need some level of interop with different devices to make sure we don't have a regression we have to find out how to address.
Thanks a lot. I expect that it not possible that any SIP device *needs* a custom RURI parameter ("received") contaning a value between quote symbols ("). I just can't imagine that removing these quotes will make the INVITE being droped or rejected by a SIP device that worked when these quotes exist in the parameter. Anyway I understand you and I'll try it with some devices and will report the result here. Thanks a lot. -- Iñaki Baz Castillo <ibc@aliax.net>
2008/11/19 Iñaki Baz Castillo <ibc@aliax.net>:
Anyway I understand you and I'll try it with some devices and will report the result here.
Opsss, sorry... I can't test it since the patch is not available yet XD -- Iñaki Baz Castillo <ibc@aliax.net>
Its sip... you learn to expect the unexpected. I have personally seen some of the dumbest things possible in SIP with various phones. /b On Nov 19, 2008, at 9:01 AM, Iñaki Baz Castillo wrote:
I expect that it not possible that any SIP device *needs* a custom RURI parameter ("received") contaning a value between quote symbols ("). I just can't imagine that removing these quotes will make the INVITE being droped or rejected by a SIP device that worked when these quotes exist in the parameter.
Its sip... you learn to expect the unexpected. I have personally seen some of the dumbest things possible in SIP with various phones.
/b
I've been watching FS (and Asterisk) for the past 3 years and if there's anything I've learned it's that SIP is a fickle friend. Saying that something is "the most SIP compliant" device/endpoint/gadget isn't exactly a bragging point. If every piece of SIP equipment out there tried to adhere to the absolute letter of every SIP-related RFC then nothing would work! (Yes, that's an exaggeration, but not a big one.) Anyway, we're all stuck with SIP because no one could come up with anything better *and* get enough telecom players to use it widely. So instead we're all stuck with a grossly imperfect protocol that has its strengths and weaknesses. The FS devs have chosen a wise course: make their SIP implementation use the good stuff in SIP while trying to minimize the stupid things that SIP allows and/or requires. End of rant, thanks for listening. -MC
El Miércoles, 19 de Noviembre de 2008, Michael Collins escribió:
The FS devs have chosen a wise course: make their SIP implementation use the good stuff in SIP while trying to minimize the stupid things that SIP allows and/or requires.
I think it's a good aproach. RFC 3261 is full of stupid ideas and "features". My favourites are: - Section 18.2.2 (Sending Responses). - Section 23 (S/MIME) There is no SIP stack implementing them, nobody understand them and there is no interest in implementing them in a future, but anyway, in any new exotic draft about SIP you could read something as "privacy could be handled with S/MIME...". In the other side, SIP protocol is cool and extensible :) -- Iñaki Baz Castillo
On 11/19/08, Michael Collins <mcollins@fcnetwork.com> wrote:
I've been watching FS (and Asterisk) for the past 3 years and if there's anything I've learned it's that SIP is a fickle friend. Saying that something is "the most SIP compliant" device/endpoint/gadget isn't exactly a bragging point. If every piece of SIP equipment out there tried to adhere to the absolute letter of every SIP-related RFC then nothing would work! (Yes, that's an exaggeration, but not a big one.)
Anyway, we're all stuck with SIP because no one could come up with anything better *and* get enough telecom players to use it widely. So instead we're all stuck with a grossly imperfect protocol that has its strengths and weaknesses. The FS devs have chosen a wise course: make their SIP implementation use the good stuff in SIP while trying to minimize the stupid things that SIP allows and/or requires.
End of rant, thanks for listening.
-MC
Basic tenet for any RFC: "Be strict in what you send and liberal in what you accept." -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
-----Original Message----- From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Kristian Kielhofner
Basic tenet for any RFC:
"Be strict in what you send and liberal in what you accept."
This "robustness principle" doesn't work too well for such applications. (See: Browser HTML/CSS compat hacks, but at least there you had the justification of having human authors for content.) Too bad this nonsense is perpetuated. Check the "SIP Torture Tests" (RFC 4475) for admittance on how screwed up the parsing is, and how they think implementations should just try to "infer" the intention. So not only do you have to deal with pointless parsing of _valid_ messages, but it'd be "good" to go write a heuristical parser that guesses, too. Yea, many different implementations, all "inferring" intention should just work dandy. -Michael
On 11/21/08, Michael Giagnocavo <mgg@giagnocavo.net> wrote:
-----Original Message----- From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Kristian Kielhofner
Basic tenet for any RFC:
"Be strict in what you send and liberal in what you accept."
This "robustness principle" doesn't work too well for such applications. (See: Browser HTML/CSS compat hacks, but at least there you had the justification of having human authors for content.)
Too bad this nonsense is perpetuated. Check the "SIP Torture Tests" (RFC 4475) for admittance on how screwed up the parsing is, and how they think implementations should just try to "infer" the intention. So not only do you have to deal with pointless parsing of _valid_ messages, but it'd be "good" to go write a heuristical parser that guesses, too.
Yea, many different implementations, all "inferring" intention should just work dandy.
-Michael
This thread /was/ about a questionable/superfluous double quote in a URI parameter. Postel's Law fits this situation quite well. I might be willing to spend my time ranting about the IETF and any questionable RFCs if there were a reasonable alternative. Suggestions? -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
On Nov 21, 2008, at 4:25 PM, Kristian Kielhofner wrote:
On 11/21/08, Michael Giagnocavo <mgg@giagnocavo.net> wrote:
-----Original Message----- From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org ] On Behalf Of Kristian Kielhofner
Basic tenet for any RFC:
"Be strict in what you send and liberal in what you accept."
This "robustness principle" doesn't work too well for such applications. (See: Browser HTML/CSS compat hacks, but at least there you had the justification of having human authors for content.)
Too bad this nonsense is perpetuated. Check the "SIP Torture Tests" (RFC 4475) for admittance on how screwed up the parsing is, and how they think implementations should just try to "infer" the intention. So not only do you have to deal with pointless parsing of _valid_ messages, but it'd be "good" to go write a heuristical parser that guesses, too.
Yea, many different implementations, all "inferring" intention should just work dandy.
-Michael
This thread /was/ about a questionable/superfluous double quote in a URI parameter. Postel's Law fits this situation quite well.
I might be willing to spend my time ranting about the IETF and any questionable RFCs if there were a reasonable alternative.
Suggestions?
For the record, we did correct this issue in svn trunk Mike
We have to finish FS first, then we'll work on the SNAP protocol. On Fri, Nov 21, 2008 at 3:25 PM, Kristian Kielhofner < kkielhofner@star2star.com> wrote:
-----Original Message----- From: freeswitch-dev-bounces@lists.freeswitch.org [mailto: freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Kristian Kielhofner
Basic tenet for any RFC:
"Be strict in what you send and liberal in what you accept."
This "robustness principle" doesn't work too well for such applications. (See: Browser HTML/CSS compat hacks, but at least there you had the justification of having human authors for content.)
Too bad this nonsense is perpetuated. Check the "SIP Torture Tests" (RFC
On 11/21/08, Michael Giagnocavo <mgg@giagnocavo.net> wrote: 4475) for admittance on how screwed up the parsing is, and how they think implementations should just try to "infer" the intention. So not only do you have to deal with pointless parsing of _valid_ messages, but it'd be "good" to go write a heuristical parser that guesses, too.
Yea, many different implementations, all "inferring" intention should
just work dandy.
-Michael
This thread /was/ about a questionable/superfluous double quote in a URI parameter. Postel's Law fits this situation quite well.
I might be willing to spend my time ranting about the IETF and any questionable RFCs if there were a reasonable alternative.
Suggestions?
-- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
participants (7)
-
Anthony Minessale
-
Brian West
-
Iñaki Baz Castillo
-
Kristian Kielhofner
-
Michael Collins
-
Michael Giagnocavo
-
Michael Jerris