Hi, sip-router Via parser is not RFC compliant as it does not accept any token in the transport (even if this does NOT occur in the top Via). A real example: kamailio receives a REGISTER like this (removing other headers):
REGISTER sip:domain,org SIP/2.0 Via: SIP/2.0/UDP 1.2.3.4:9090;branch=z9hG4bK3afb3d8e9ea4c4259f9d;rport Via: SIP/2.0/WS 1.2.3.4:36638;branch=z9hG4bK5089;received=9.9.9.9;rport=36638
And it fails parsing so also processing the request:
ERROR: <core> [parser/parse_via.c:1677]: ERROR: parse_via: bad char <W> on state 122 ERROR: <core> [parser/parse_via.c:2366]: ERROR: parse_via on: <SIP/2.0/UDP 1.2.3.4:9090;branch=z9hG4bK3afb3d8e9ea4c4259f9d;rport [...]> ERROR: <core> [parser/parse_via.c:2370]: ERROR: parse_via parse error, parsed so far:<SIP/2.0/> ERROR: <core> [parser/msg_parser.c:139]: ERROR: get_hdr_field: bad via INFO: <core> [parser/msg_parser.c:353]: ERROR: bad header field [Via: SIP/2.0/WS 1.2.]
Please, make it possible for the Via transport to contain an unknown token, at least when it does NOT occur in the top Via header. Why should Kamailio care about the second Via transport field?
I strongly need it as, obviously I'm involved in SIP over an unknown transport (yet), and this is a show-stopper.
Thanks a lot.
2011/9/2 Iñaki Baz Castillo ibc@aliax.net:
Hi, sip-router Via parser is not RFC compliant as it does not accept any token in the transport (even if this does NOT occur in the top Via). A real example: kamailio receives a REGISTER like this (removing other headers):
REGISTER sip:domain,org SIP/2.0 Via: SIP/2.0/UDP 1.2.3.4:9090;branch=z9hG4bK3afb3d8e9ea4c4259f9d;rport Via: SIP/2.0/WS 1.2.3.4:36638;branch=z9hG4bK5089;received=9.9.9.9;rport=36638
And it fails parsing so also processing the request:
ERROR: <core> [parser/parse_via.c:1677]: ERROR: parse_via: bad char <W> on state 122 ERROR: <core> [parser/parse_via.c:2366]: ERROR: parse_via on: <SIP/2.0/UDP 1.2.3.4:9090;branch=z9hG4bK3afb3d8e9ea4c4259f9d;rport [...]> ERROR: <core> [parser/parse_via.c:2370]: ERROR: parse_via parse error, parsed so far:<SIP/2.0/> ERROR: <core> [parser/msg_parser.c:139]: ERROR: get_hdr_field: bad via INFO: <core> [parser/msg_parser.c:353]: ERROR: bad header field [Via: SIP/2.0/WS 1.2.]
Please, make it possible for the Via transport to contain an unknown token, at least when it does NOT occur in the top Via header. Why should Kamailio care about the second Via transport field?
Hi, any comment about this report please? I've tryed to figure how to change the Via transport parser in order to allow any token (as RFC3261 states) but I've got lost within the hyper-optimized parser :)
2011/9/6 Iñaki Baz Castillo ibc@aliax.net:
Please, make it possible for the Via transport to contain an unknown token, at least when it does NOT occur in the top Via header. Why should Kamailio care about the second Via transport field?
Hi, any comment about this report please? I've tryed to figure how to change the Via transport parser in order to allow any token (as RFC3261 states) but I've got lost within the hyper-optimized parser :)
Hi, some comment please? :(
This issue is breaking a new SIP transport we have proposed:
http://tools.ietf.org/html/draft-ibc-rtcweb-sip-websocket-00
Thanks a lot.
PS: I will try to modify the Via parser so it allows any token in the Via transport field.
Iñaki Baz Castillo writes:
This issue is breaking a new SIP transport we have proposed:
http://tools.ietf.org/html/draft-ibc-rtcweb-sip-websocket-00
inaki,
how about using rtmp instead?
-- juha
2011/9/13 Juha Heinanen jh@tutpro.com:
Iñaki Baz Castillo writes:
This issue is breaking a new SIP transport we have proposed:
http://tools.ietf.org/html/draft-ibc-rtcweb-sip-websocket-00
inaki,
how about using rtmp instead?
Hi Juha,
RTMP/Flash is not the way to go these days. The future is HTML5 (which includes WebSocket protocol) and WebRTC (for multimedia, audio/video RTP and so on).
For further discussions about this topic I suggest following the IETF rtcweb maillist in which the draft has been presented:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg01091.html
Regards.
Hello,
On 9/13/11 9:02 PM, Iñaki Baz Castillo wrote:
2011/9/6 Iñaki Baz Castilloibc@aliax.net:
Please, make it possible for the Via transport to contain an unknown token, at least when it does NOT occur in the top Via header. Why should Kamailio care about the second Via transport field?
Hi, any comment about this report please? I've tryed to figure how to change the Via transport parser in order to allow any token (as RFC3261 states) but I've got lost within the hyper-optimized parser :)
Hi, some comment please? :(
you started the discussion when many of us were partying for 10 years celebration :-) so it got lost -- reminders are recommended always.
There is no real good reason why not accepting unknown transport protocols non-top Vias. The limitation is coming from implementation of the parser, but should be relaxed.
The best would be to introduce PROTO_OTHER in the enum of protocols (ip_addr.h, enum sip_protos) and in case this type is encountered, read the string value of the protocol.
Via parser is using quite a lot of states, so if you look to update it, when it gets to the state where the transport (proto) part starts, if does not match UDP, TCP, TLS or SCTP, then set vb->proto=PROTO_OTHER and start and length of the token in vb->transport. Should not be very complex to enhance once you get into via parser states.
I may fix it before 3.2.0 is out if you are not doing it meanwhile, but cannot give you a timeline for it right now.
Cheers, Daniel
This issue is breaking a new SIP transport we have proposed:
http://tools.ietf.org/html/draft-ibc-rtcweb-sip-websocket-00
Thanks a lot.
PS: I will try to modify the Via parser so it allows any token in the Via transport field.
2011/9/13 Daniel-Constantin Mierla miconda@gmail.com:
you started the discussion when many of us were partying for 10 years celebration :-) so it got lost -- reminders are recommended always.
There is no real good reason why not accepting unknown transport protocols non-top Vias. The limitation is coming from implementation of the parser, but should be relaxed.
The best would be to introduce PROTO_OTHER in the enum of protocols (ip_addr.h, enum sip_protos) and in case this type is encountered, read the string value of the protocol.
Via parser is using quite a lot of states, so if you look to update it, when it gets to the state where the transport (proto) part starts, if does not match UDP, TCP, TLS or SCTP, then set vb->proto=PROTO_OTHER and start and length of the token in vb->transport. Should not be very complex to enhance once you get into via parser states.
I may fix it before 3.2.0 is out if you are not doing it meanwhile, but cannot give you a timeline for it right now.
Thanks a lot Daniel !
I will try to do it by myself by following your useful indications. If I get it I will announce prior to commiting it.
Thanks.
13 sep 2011 kl. 22:10 skrev Iñaki Baz Castillo:
2011/9/13 Daniel-Constantin Mierla miconda@gmail.com:
you started the discussion when many of us were partying for 10 years celebration :-) so it got lost -- reminders are recommended always.
There is no real good reason why not accepting unknown transport protocols non-top Vias. The limitation is coming from implementation of the parser, but should be relaxed.
The best would be to introduce PROTO_OTHER in the enum of protocols (ip_addr.h, enum sip_protos) and in case this type is encountered, read the string value of the protocol.
Via parser is using quite a lot of states, so if you look to update it, when it gets to the state where the transport (proto) part starts, if does not match UDP, TCP, TLS or SCTP, then set vb->proto=PROTO_OTHER and start and length of the token in vb->transport. Should not be very complex to enhance once you get into via parser states.
I may fix it before 3.2.0 is out if you are not doing it meanwhile, but cannot give you a timeline for it right now.
Thanks a lot Daniel !
I will try to do it by myself by following your useful indications. If I get it I will announce prior to commiting it.
That reminds me of my favorite issue: Is it possible to get Kamailio to accept other URI schemes than SIP and SIPS?
/O
2011/9/13 Olle E. Johansson oej@edvina.net:
That reminds me of my favorite issue: Is it possible to get Kamailio to accept other URI schemes than SIP and SIPS?
It accepts TEL uris, but AFAIK there is no way to know (in the config script) the parsed URI schema (but just doing a regular expression matching like if $ru =~ "^tel:".
13 sep 2011 kl. 22:14 skrev Iñaki Baz Castillo:
2011/9/13 Olle E. Johansson oej@edvina.net:
That reminds me of my favorite issue: Is it possible to get Kamailio to accept other URI schemes than SIP and SIPS?
It accepts TEL uris, but AFAIK there is no way to know (in the config script) the parsed URI schema (but just doing a regular expression matching like if $ru =~ "^tel:".
We started this discussion at the SIP-xmpp interoperability workshop in Paris years ago. I wanted XMPP: uri's in the From: header.
Now, there are reasons in unified communication to register a mailto: uri to a contact in the registrar. I vaguely remember the SIP RFC having a section of being neutral here.
/O
On 13.09.2011 22:12, Olle E. Johansson wrote:
13 sep 2011 kl. 22:10 skrev Iñaki Baz Castillo:
2011/9/13 Daniel-Constantin Mierlamiconda@gmail.com:
you started the discussion when many of us were partying for 10 years celebration :-) so it got lost -- reminders are recommended always.
There is no real good reason why not accepting unknown transport protocols non-top Vias. The limitation is coming from implementation of the parser, but should be relaxed.
The best would be to introduce PROTO_OTHER in the enum of protocols (ip_addr.h, enum sip_protos) and in case this type is encountered, read the string value of the protocol.
Via parser is using quite a lot of states, so if you look to update it, when it gets to the state where the transport (proto) part starts, if does not match UDP, TCP, TLS or SCTP, then set vb->proto=PROTO_OTHER and start and length of the token in vb->transport. Should not be very complex to enhance once you get into via parser states.
I may fix it before 3.2.0 is out if you are not doing it meanwhile, but cannot give you a timeline for it right now.
Thanks a lot Daniel !
I will try to do it by myself by following your useful indications. If I get it I will announce prior to commiting it.
That reminds me of my favorite issue: Is it possible to get Kamailio to accept other URI schemes than SIP and SIPS?
Oh yes, tm module fails for example if RURI is a service URN.
regards klaus
Hi Klaus,
The problem is not the TM-Module, but the URI-Parser of the core which does not support URN's. The OpenIMSCore has support for URN-URI's, I've ported the support to my carstenbock/ims branch; i will try to add the support for URN's to the trunk-version this week.
Regards, Carsten
2011/9/14 Klaus Darilion klaus.mailinglists@pernau.at:
On 13.09.2011 22:12, Olle E. Johansson wrote:
13 sep 2011 kl. 22:10 skrev Iñaki Baz Castillo:
2011/9/13 Daniel-Constantin Mierlamiconda@gmail.com:
you started the discussion when many of us were partying for 10 years celebration :-) so it got lost -- reminders are recommended always.
There is no real good reason why not accepting unknown transport protocols non-top Vias. The limitation is coming from implementation of the parser, but should be relaxed.
The best would be to introduce PROTO_OTHER in the enum of protocols (ip_addr.h, enum sip_protos) and in case this type is encountered, read the string value of the protocol.
Via parser is using quite a lot of states, so if you look to update it, when it gets to the state where the transport (proto) part starts, if does not match UDP, TCP, TLS or SCTP, then set vb->proto=PROTO_OTHER and start and length of the token in vb->transport. Should not be very complex to enhance once you get into via parser states.
I may fix it before 3.2.0 is out if you are not doing it meanwhile, but cannot give you a timeline for it right now.
Thanks a lot Daniel !
I will try to do it by myself by following your useful indications. If I get it I will announce prior to commiting it.
That reminds me of my favorite issue: Is it possible to get Kamailio to accept other URI schemes than SIP and SIPS?
Oh yes, tm module fails for example if RURI is a service URN.
regards klaus
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
14 sep 2011 kl. 09:09 skrev Carsten Bock:
Hi Klaus,
The problem is not the TM-Module, but the URI-Parser of the core which does not support URN's. The OpenIMSCore has support for URN-URI's, I've ported the support to my carstenbock/ims branch; i will try to add the support for URN's to the trunk-version this week.
Does this mean ONLY URN's or a generic support for *any* URI scheme?
/O
Regards, Carsten
2011/9/14 Klaus Darilion klaus.mailinglists@pernau.at:
On 13.09.2011 22:12, Olle E. Johansson wrote:
13 sep 2011 kl. 22:10 skrev Iñaki Baz Castillo:
2011/9/13 Daniel-Constantin Mierlamiconda@gmail.com:
you started the discussion when many of us were partying for 10 years celebration :-) so it got lost -- reminders are recommended always.
There is no real good reason why not accepting unknown transport protocols non-top Vias. The limitation is coming from implementation of the parser, but should be relaxed.
The best would be to introduce PROTO_OTHER in the enum of protocols (ip_addr.h, enum sip_protos) and in case this type is encountered, read the string value of the protocol.
Via parser is using quite a lot of states, so if you look to update it, when it gets to the state where the transport (proto) part starts, if does not match UDP, TCP, TLS or SCTP, then set vb->proto=PROTO_OTHER and start and length of the token in vb->transport. Should not be very complex to enhance once you get into via parser states.
I may fix it before 3.2.0 is out if you are not doing it meanwhile, but cannot give you a timeline for it right now.
Thanks a lot Daniel !
I will try to do it by myself by following your useful indications. If I get it I will announce prior to commiting it.
That reminds me of my favorite issue: Is it possible to get Kamailio to accept other URI schemes than SIP and SIPS?
Oh yes, tm module fails for example if RURI is a service URN.
regards klaus
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Carsten Bock CEO (Geschäftsführer)
ng-voice GmbH i. Gr.
http://www.ng-voice.com mailto:carsten@ng-voice.com
Mobile +49 179 2021244 Office +49 40 34927219 Fax +49 40 34927220
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
Hi Olle,
it added support for URN-URI's and for CID-URI's. I think it is limited to support only few URI schemes for performance reasons.
Carsten
2011/9/14 Olle E. Johansson oej@edvina.net:
14 sep 2011 kl. 09:09 skrev Carsten Bock:
Hi Klaus,
The problem is not the TM-Module, but the URI-Parser of the core which does not support URN's. The OpenIMSCore has support for URN-URI's, I've ported the support to my carstenbock/ims branch; i will try to add the support for URN's to the trunk-version this week.
Does this mean ONLY URN's or a generic support for *any* URI scheme?
/O
Regards, Carsten
2011/9/14 Klaus Darilion klaus.mailinglists@pernau.at:
On 13.09.2011 22:12, Olle E. Johansson wrote:
13 sep 2011 kl. 22:10 skrev Iñaki Baz Castillo:
2011/9/13 Daniel-Constantin Mierlamiconda@gmail.com:
you started the discussion when many of us were partying for 10 years celebration :-) so it got lost -- reminders are recommended always.
There is no real good reason why not accepting unknown transport protocols non-top Vias. The limitation is coming from implementation of the parser, but should be relaxed.
The best would be to introduce PROTO_OTHER in the enum of protocols (ip_addr.h, enum sip_protos) and in case this type is encountered, read the string value of the protocol.
Via parser is using quite a lot of states, so if you look to update it, when it gets to the state where the transport (proto) part starts, if does not match UDP, TCP, TLS or SCTP, then set vb->proto=PROTO_OTHER and start and length of the token in vb->transport. Should not be very complex to enhance once you get into via parser states.
I may fix it before 3.2.0 is out if you are not doing it meanwhile, but cannot give you a timeline for it right now.
Thanks a lot Daniel !
I will try to do it by myself by following your useful indications. If I get it I will announce prior to commiting it.
That reminds me of my favorite issue: Is it possible to get Kamailio to accept other URI schemes than SIP and SIPS?
Oh yes, tm module fails for example if RURI is a service URN.
regards klaus
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Carsten Bock CEO (Geschäftsführer)
ng-voice GmbH i. Gr.
http://www.ng-voice.com mailto:carsten@ng-voice.com
Mobile +49 179 2021244 Office +49 40 34927219 Fax +49 40 34927220
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
- Olle E Johansson - oej@edvina.net
- Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hello,
On 9/14/11 9:40 AM, Carsten Bock wrote:
Hi Olle,
it added support for URN-URI's and for CID-URI's. I think it is limited to support only few URI schemes for performance reasons.
the performance reasons are for well-known/very common values, but we should support the other as well. It is the same with SIP methods.
Cheers, Daniel
Carsten
2011/9/14 Olle E. Johanssonoej@edvina.net:
14 sep 2011 kl. 09:09 skrev Carsten Bock:
Hi Klaus,
The problem is not the TM-Module, but the URI-Parser of the core which does not support URN's. The OpenIMSCore has support for URN-URI's, I've ported the support to my carstenbock/ims branch; i will try to add the support for URN's to the trunk-version this week.
Does this mean ONLY URN's or a generic support for *any* URI scheme?
/O
Regards, Carsten
2011/9/14 Klaus Darilionklaus.mailinglists@pernau.at:
On 13.09.2011 22:12, Olle E. Johansson wrote:
13 sep 2011 kl. 22:10 skrev Iñaki Baz Castillo:
2011/9/13 Daniel-Constantin Mierlamiconda@gmail.com: > you started the discussion when many of us were partying for 10 years > celebration :-) so it got lost -- reminders are recommended always. > > There is no real good reason why not accepting unknown transport > protocols > non-top Vias. The limitation is coming from implementation of the > parser, > but should be relaxed. > > The best would be to introduce PROTO_OTHER in the enum of protocols > (ip_addr.h, enum sip_protos) and in case this type is encountered, read > the > string value of the protocol. > > Via parser is using quite a lot of states, so if you look to update it, > when > it gets to the state where the transport (proto) part starts, if does > not > match UDP, TCP, TLS or SCTP, then set vb->proto=PROTO_OTHER and start > and > length of the token in vb->transport. Should not be very complex to > enhance > once you get into via parser states. > > I may fix it before 3.2.0 is out if you are not doing it meanwhile, but > cannot give you a timeline for it right now.
Thanks a lot Daniel !
I will try to do it by myself by following your useful indications. If I get it I will announce prior to commiting it.
That reminds me of my favorite issue: Is it possible to get Kamailio to accept other URI schemes than SIP and SIPS?
Oh yes, tm module fails for example if RURI is a service URN.
regards klaus
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Carsten Bock CEO (Geschäftsführer)
ng-voice GmbH i. Gr.
http://www.ng-voice.com mailto:carsten@ng-voice.com
Mobile +49 179 2021244 Office +49 40 34927219 Fax +49 40 34927220
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
- Olle E Johansson - oej@edvina.net
- Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
2011/9/13 Iñaki Baz Castillo ibc@aliax.net:
I may fix it before 3.2.0 is out if you are not doing it meanwhile, but cannot give you a timeline for it right now.
Thanks a lot Daniel !
I will try to do it by myself by following your useful indications. If I get it I will announce prior to commiting it.
Hi Daniel, finally I got it :)
It's tested and commited to master. Via parser now allows any token as Via transport field (including ugly words as "UD", "TC", "WS", "baz.2-foo").
Regards.
-
Carsten Bock -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Juha Heinanen -
Klaus Darilion -
Olle E. Johansson