[asterisk-bugs] [JIRA] (ASTERISK-20981) Call-ID header generation to exclude colon

Rusty Newton (JIRA) noreply at issues.asterisk.org
Thu Feb 14 09:16:58 CST 2013


     [ https://issues.asterisk.org/jira/browse/ASTERISK-20981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-20981:
------------------------------------

    Description: 
I'm not marking it as a bug, but it makes asterisk incompatible with some grandstream phones (probably older GXP series).

One of our customers said that call transfer not always works. We discovered this after analysing weeks of logs, that sometimes these phones generated improper Refer-to headers when transfering. In place there was :5060 in original Call-ID, apropriate Refer-To header had some trash in it. As in example:

Refer-To: <sip:167 at 192.168.11.1?Replaces=2df72a142b79b2cd4d8d88f629641474%40192.168.11.1%3:5060%3Bfrom-tag%3D4161c6a374b2b401%3Bto-tag%3Das5a98266b>


Original Call-ID had a form of 2df72a142b79b2cd4d8d88f629641474 at 192.168.11.1:5060


Notice additional %3 characters in Refer-To.

So - we applied the following patch that seem to resolve the issue. I call it an issue, as it is not a bug, but we know that at least Grandstream GXP 2000 series phones are affected, and there is no upgrade to resolve it. We also notified the producer, but without feedback. As far as we have customers having dozens of these phones, we decided to fix it at Asterisk not at the phone part.

I attach the patch as it may be useful for other grandstream owners. Changing Call-ID generation seems harmless to asterisk, but saves some old hardware.

[Edit by Rusty Newton - removed patch, as it must be submitted with a signed contributors agreement]


  was:
I'm not marking it as a bug, but it makes asterisk incompatible with some grandstream phones (probably older GXP series).

One of our customers said that call transfer not always works. We discovered this after analysing weeks of logs, that sometimes these phones generated improper Refer-to headers when transfering. In place there was :5060 in original Call-ID, apropriate Refer-To header had some trash in it. As in example:

Refer-To: <sip:167 at 192.168.11.1?Replaces=2df72a142b79b2cd4d8d88f629641474%40192.168.11.1%3:5060%3Bfrom-tag%3D4161c6a374b2b401%3Bto-tag%3Das5a98266b>


Original Call-ID had a form of 2df72a142b79b2cd4d8d88f629641474 at 192.168.11.1:5060


Notice additional %3 characters in Refer-To.

So - we applied the following patch that seem to resolve the issue. I call it an issue, as it is not a bug, but we know that at least Grandstream GXP 2000 series phones are affected, and there is no upgrade to resolve it. We also notified the producer, but without feedback. As far as we have customers having dozens of these phones, we decided to fix it at Asterisk not at the phone part.

I attach the patch as it may be useful for other grandstream owners. Changing Call-ID generation seems harmless to asterisk, but saves some old hardware.

--- asterisk-1.8.20.0/channels/chan_sip.c.orig  2013-01-23 23:34:57.000000000 +0100
+++ asterisk-1.8.20.0/channels/chan_sip.c       2013-01-23 23:35:34.000000000 +0100
@@ -7970,7 +7970,7 @@
 static void build_callid_pvt(struct sip_pvt *pvt)
 {
        char buf[33];
-       const char *host = S_OR(pvt->fromdomain, ast_sockaddr_stringify_remote(&pvt->ourip));
+       const char *host = S_OR(pvt->fromdomain, ast_sockaddr_stringify_host_remote(&pvt->ourip));

        ast_string_field_build(pvt, callid, "%s@%s", generate_random_string(buf, sizeof(buf)), host);
 }


    
> Call-ID header generation to exclude colon
> ------------------------------------------
>
>                 Key: ASTERISK-20981
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20981
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 1.8.20.0
>         Environment: Does not matter
>            Reporter: Michał Mosiewicz
>            Assignee: Michał Mosiewicz
>
> I'm not marking it as a bug, but it makes asterisk incompatible with some grandstream phones (probably older GXP series).
> One of our customers said that call transfer not always works. We discovered this after analysing weeks of logs, that sometimes these phones generated improper Refer-to headers when transfering. In place there was :5060 in original Call-ID, apropriate Refer-To header had some trash in it. As in example:
> Refer-To: <sip:167 at 192.168.11.1?Replaces=2df72a142b79b2cd4d8d88f629641474%40192.168.11.1%3:5060%3Bfrom-tag%3D4161c6a374b2b401%3Bto-tag%3Das5a98266b>
> Original Call-ID had a form of 2df72a142b79b2cd4d8d88f629641474 at 192.168.11.1:5060
> Notice additional %3 characters in Refer-To.
> So - we applied the following patch that seem to resolve the issue. I call it an issue, as it is not a bug, but we know that at least Grandstream GXP 2000 series phones are affected, and there is no upgrade to resolve it. We also notified the producer, but without feedback. As far as we have customers having dozens of these phones, we decided to fix it at Asterisk not at the phone part.
> I attach the patch as it may be useful for other grandstream owners. Changing Call-ID generation seems harmless to asterisk, but saves some old hardware.
> [Edit by Rusty Newton - removed patch, as it must be submitted with a signed contributors agreement]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list