Kamailio 4.3.3 and HUAWEI HG8245. Port 1 call port 2. 481 Call/Transaction Does Not Exist. Warning: 399 No Dialog match.
17 May
2016
17 May
'16
4:08 p.m.
Hi there.
In our network we used several ONT Huawei models. But with one model
HUAWEI-EchoLife HG8245 / V1R003C00S205 we have the following problem. When
connecting to this device in the POTS ports of the two phones. From the
first port we can not call to the second and from the second port can not
call to the first port. On the other ONT Huawei devices, there is no such
problem. Earlier we had set OpenSIP and this device did not have a problem.
The problem is likely in the configuration because it works at the default
settings.
kamailio -v
Version: kamailio 4.3.3 (x86_64/linux) f69971
/var/log/kamailio
May 17 10:53:21 kamailio /usr/local/sbin/kamailio[17875]: INFO: <script>:
Callee '123456' is local - M=INVITE RURI=sip:123456@10.10.10.200 F=
sip:654321@10.10.10.200 T=sip:123456@10.10.10.200 IP=10.14.197.13
5 ID=lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.10.10.100
May 17 10:53:21 kamailio /usr/local/sbin/kamailio[17875]: INFO: <script>:
Call control: dst user '123456' currently has [0/2] active calls - M=INVITE
RURI=sip:123456@10.10.10.200 F=sip:654321@10.10.10.200 T=si
p:123456@10.10.10.200 IP=10.10.10.100 ID=
lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.10.10.100
May 17 10:53:21 kamailio /usr/local/sbin/kamailio[17875]: INFO: <script>:
Normalize source: sip:654321@10.10.10.200 -> sip:654321@10.10.10.200
May 17 10:53:21 kamailio /usr/local/sbin/kamailio[17875]: INFO: <script>:
Request leaving server - M=INVITE
RURI=sip:123456@10.10.10.100:5060;transport=udp
F=sip:654321@10.10.10.200 T=sip:123456@178.168.4.
37 IP=10.10.10.100 ID=lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.10.10.100
May 17 10:53:22 kamailio /usr/local/sbin/kamailio[17873]: INFO: <script>:
Reply - S=100 D=Trying F=sip:654321@10.10.10.200 T=sip:123456@10.10.10.200
IP=10.10.10.100 ID=lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.1
4.197.135
May 17 10:53:22 kamailio /usr/local/sbin/kamailio[17861]: INFO: <script>:
Reply - S=481 D=Call/Transaction Does Not Exist F=sip:654321@10.10.10.200 T=
sip:123456@10.10.10.200 IP=10.10.10.100 ID=
lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.10.10.100
sngrep
2016/05/17 10:53:21.514702 10.10.10.100:5060 -> 10.10.10.200:5060
INVITE sip:123456@10.10.10.200 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.100:5060;branch=z9hG4bKz4j0izm0i8jcn2pmlkm4c24cz
Route: <sip:10.10.10.200:5060;transport=udp;lr>
Call-ID: lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.10.10.100
From: <sip:654321@10.10.10.200>;tag=pk4nzz3j
To: <sip:123456@10.10.10.200>
CSeq: 1 INVITE
Contact: <sip:654321@10.10.10.100:5060;transport=udp>
Supported: 100rel,replaces,timer,privacy,in-dialog
Session-Expires: 1800
Accept: application/sdp,application/simservs+xml
Min-SE: 90
Accept-Encoding: identity
Accept-Language: en
Allow:
INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER
Max-Forwards: 70
User-Agent: HUAWEI-EchoLife HG8245/V1R003C00S205
Session-ID: 20zlkckj1kz4ll1i1ic2pl1csk80kli1
Content-Length: 318
Content-Type: application/sdp
2016/05/17 10:53:21.590008 10.10.10.100:5060 -> 10.10.10.200:5060
INVITE sip:123456@10.10.10.200 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.100:5060;branch=z9hG4bK0lz4ll1ikm1k02p20lz4ll1il
Route: <sip:10.10.10.200:5060;transport=udp;lr>
Call-ID: lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.10.10.100
From: <sip:654321@10.10.10.200>;tag=pk4nzz3j
To: <sip:123456@10.10.10.200>
CSeq: 2 INVITE
Contact: <sip:654321@10.10.10.100:5060;transport=udp>
Supported: 100rel,replaces,timer,privacy,in-dialog
Session-Expires: 1800
Accept: application/sdp,application/simservs+xml
Min-SE: 90
Proxy-Authorization: Digest
username="654321",realm="10.10.10.200",nonce="VzrPHVc6zfEYftiGlJYC9XLb4ixCZtQB",uri="
sip:123456@10.10.10.200
",response="55e03b278f1cbdda52852004bbc8d7c9",algorithm=MD5,cnonce="0f31d
b",qop=auth,nc=00000006
Accept-Encoding: identity
Accept-Language: en
Allow:
INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER
Max-Forwards: 70
User-Agent: HUAWEI-EchoLife HG8245/V1R003C00S205
Session-ID: 20zlkckj1kz4ll1i1ic2pl1csk80kli1
Content-Length: 318
Content-Type: application/sdp
2016/05/17 10:53:21.642831 10.10.10.200:5060 -> 10.10.10.100:5060
INVITE sip:123456@10.10.10.100:5060;transport=udp SIP/2.0
Record-Route:
<sip:10.10.10.200;lr=on;ftag=pk4nzz3j;nat=yes;did=925.a5a1;vst=AAAAAAkLCwgLCnEDBHgfBg4WHwIWHQMuMzc-;vsf=AAAAAAkLAwgLAnEDBHgfBg4WHwIWHQMuMzc->
Via: SIP/2.0/UDP
10.10.10.200;branch=z9hG4bKd55d.f4d5d1ee3d090fe847af101d0a47ac5e.0
Via: SIP/2.0/UDP
10.10.10.100:5060;rport=5060;branch=z9hG4bK0lz4ll1ikm1k02p20lz4ll1il
Call-ID: lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.10.10.100
From: "654321" <sip:654321@10.10.10.200>;tag=pk4nzz3j
To: <sip:123456@10.10.10.200>
CSeq: 2 INVITE
Contact: <sip:654321@10.10.10.100:5060;transport=udp>
Supported: 100rel,replaces,timer,privacy,in-dialog
Session-Expires: 1800
Accept: application/sdp,application/simservs+xml
Min-SE: 90
Accept-Encoding: identity
Accept-Language: en
Allow:
INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER
Max-Forwards: 69
User-Agent: HUAWEI-EchoLife HG8245/V1R003C00S205
Content-Length: 334
Content-Type: application/sdp
P-Asserted-Identity: <sip:654321@10.10.10.200>
2016/05/17 10:53:22.121872 10.10.10.200:5060 -> 10.10.10.100:5060
INVITE sip:123456@10.10.10.100:5060;transport=udp SIP/2.0
Record-Route:
<sip:10.10.10.200;lr=on;ftag=pk4nzz3j;nat=yes;did=925.a5a1;vst=AAAAAAkLCwgLCnEDBHgfBg4WHwIWHQMuMzc-;vsf=AAAAAAkLAwgLAnEDBHgfBg4WHwIWHQMuMzc->
Via: SIP/2.0/UDP
10.10.10.200;branch=z9hG4bKd55d.f4d5d1ee3d090fe847af101d0a47ac5e.0
Via: SIP/2.0/UDP
10.10.10.100:5060;rport=5060;branch=z9hG4bK0lz4ll1ikm1k02p20lz4ll1il
Call-ID: lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.10.10.100
From: "654321" <sip:654321@10.10.10.200>;tag=pk4nzz3j
To: <sip:123456@10.10.10.200>
CSeq: 2 INVITE
Contact: <sip:654321@10.10.10.100:5060;transport=udp>
Supported: 100rel,replaces,timer,privacy,in-dialog
Session-Expires: 1800
Accept: application/sdp,application/simservs+xml
Min-SE: 90
Accept-Encoding: identity
Accept-Language: en
Allow:
INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER
Max-Forwards: 69
User-Agent: HUAWEI-EchoLife HG8245/V1R003C00S205
Content-Length: 334
Content-Type: application/sdp
P-Asserted-Identity: <sip:654321@10.10.10.200>
2016/05/17 10:53:22.996850 10.10.10.100:5060 -> 10.10.10.200:5060
SIP/2.0 481 Call/Transaction Does Not Exist
Via: SIP/2.0/UDP
10.10.10.200;branch=z9hG4bKd55d.f4d5d1ee3d090fe847af101d0a47ac5e.0,SIP/2.0/UDP
10.10.10.100:5060;branch=z9hG4bK0lz4ll1ikm1k02p20lz4ll1il;rport=5060
Call-ID: lps4s2204mz4ll1i4mz4ll1ici0lc81i(a)10.10.10.100
From: "654321"<sip:654321@10.10.10.200>;tag=pk4nzz3j
To: <sip:123456@10.10.10.200>;tag=m2scp1cm
CSeq: 2 INVITE
Warning: 399 10.10.10.100 "SS100006F143L3557[05552] No Dialog match"
User-Agent: HUAWEI-EchoLife HG8245/V1R003C00S205
Content-Length: 0
17 May
17 May
4:53 p.m.
On Tue, May 17, 2016 at 05:08:45PM +0300, Mx R wrote:
In our network we used several ONT Huawei models. But
with one model
HUAWEI-EchoLife HG8245 / V1R003C00S205 we have the following problem. When
connecting to this device in the POTS ports of the two phones. From the
first port we can not call to the second and from the second port can not
call to the first port. On the other ONT Huawei devices, there is no such
problem. Earlier we had set OpenSIP and this device did not have a problem.
The problem is likely in the configuration because it works at the default
settings.
In the past I ran into other devices/PBXs that can't handle the fact
there is an outgoing/incoming call with the same callid. You could try
the topoh module (with modparam("topoh", "mask_callid", 1))
Beware that it might introduce other problems in some calls scenarios,
my prefered solution is to route the call to a b2bua (asterisk) when I
detected hairpinning.
27 May
27 May
6:32 p.m.
Hi there,
The question is still relevant.
It seems to me that the problem lies somewhere in this part.
route[REPLY] {
route(ACCOUNTING);
t_on_reply("1");
t_on_failure("1");
if(is_present_hf("Proxy-Authorization"))
{
remove_hf("Proxy-Authorization");
};
xlog("L_INFO", "Request leaving server - M=$rm RURI=$ru F=$fu
T=$tu
IP=$si ID=$ci\n");
if (!t_relay()) {
if (method=="INVITE" || method=="ACK") {
route(RTPPROXY);
};
sl_reply_error();
};
exit;
}
2016-05-17 17:53 GMT+03:00 Daniel Tryba <d.tryba(a)pocos.nl>nl>:
On Tue, May 17, 2016 at 05:08:45PM +0300, Mx R wrote:
In our network we used several ONT Huawei models.
But with one model
HUAWEI-EchoLife HG8245 / V1R003C00S205 we have the following problem.
When
connecting to this device in the POTS ports of
the two phones. From the
first port we can not call to the second and from the second port can not
call to the first port. On the other ONT Huawei devices, there is no such
problem. Earlier we had set OpenSIP and this device did not have a
problem.
The problem is likely in the configuration because it works at the
default
settings.
In the past I ran into other devices/PBXs that can't handle the fact
there is an outgoing/incoming call with the same callid. You could try
the topoh module (with modparam("topoh", "mask_callid", 1))
Beware that it might introduce other problems in some calls scenarios,
my prefered solution is to route the call to a b2bua (asterisk) when I
detected hairpinning.
_______________________________________________
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
1 Jun
1 Jun
6:16 p.m.
Thanks Daniel
modparam("topoh", "mask_callid", 1)
It worked.
2016-05-17 17:53 GMT+03:00 Daniel Tryba <d.tryba(a)pocos.nl>nl>:
On Tue, May 17, 2016 at 05:08:45PM +0300, Mx R wrote:
In our network we used several ONT Huawei models.
But with one model
HUAWEI-EchoLife HG8245 / V1R003C00S205 we have the following problem.
When
connecting to this device in the POTS ports of
the two phones. From the
first port we can not call to the second and from the second port can not
call to the first port. On the other ONT Huawei devices, there is no such
problem. Earlier we had set OpenSIP and this device did not have a
problem.
The problem is likely in the configuration because it works at the
default
settings.
In the past I ran into other devices/PBXs that can't handle the fact
there is an outgoing/incoming call with the same callid. You could try
the topoh module (with modparam("topoh", "mask_callid", 1))
Beware that it might introduce other problems in some calls scenarios,
my prefered solution is to route the call to a b2bua (asterisk) when I
detected hairpinning.
_______________________________________________
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
2 Jun
2 Jun
8:47 a.m.
Interesting to know that some devices still can't handle sip spirals...
Cheers,
Daniel
On 01/06/16 18:16, Mx R wrote:
Thanks Daniel
modparam("topoh", "mask_callid", 1)
It worked.
2016-05-17 17:53 GMT+03:00 Daniel Tryba <d.tryba(a)pocos.nl
<mailto:d.tryba@pocos.nl>>:
On Tue, May 17, 2016 at 05:08:45PM +0300, Mx R wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com - http://www.kamailio.org
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
In our network we used several ONT Huawei models.
But with one model
HUAWEI-EchoLife HG8245 / V1R003C00S205 we have the following
problem. When
connecting to this device in the POTS ports of
the two phones.
From the
first port we can not call to the second and from
the second
port can not
call to the first port. On the other ONT Huawei
devices, there
is no such
problem. Earlier we had set OpenSIP and this
device did not have
a problem.
The problem is likely in the configuration because it works at
the default
settings.
In the past I ran into other devices/PBXs that can't handle the fact
there is an outgoing/incoming call with the same callid. You could try
the topoh module (with modparam("topoh", "mask_callid", 1))
Beware that it might introduce other problems in some calls scenarios,
my prefered solution is to route the call to a b2bua (asterisk) when I
detected hairpinning.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
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
23 Jun
23 Jun
12:37 p.m.
Hi there.
This problem has been solved. We contacted with the supplier. And they have
given us a new firmware for devices that have this problem.
Thanks to all.
2016-06-02 9:47 GMT+03:00 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Interesting to know that some devices still can't
handle sip spirals...
Cheers,
Daniel
On 01/06/16 18:16, Mx R wrote:
Thanks Daniel
modparam("topoh", "mask_callid", 1)
It worked.
2016-05-17 17:53 GMT+03:00 Daniel Tryba <d.tryba(a)pocos.nl>nl>:
On Tue, May 17, 2016 at 05:08:45PM +0300, Mx R
wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierlahttp://www.asipto.com -
http://www.kamailio.orghttp://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
In our network we used several ONT Huawei models.
But with one model
HUAWEI-EchoLife HG8245 / V1R003C00S205 we have the following problem.
When
connecting to this device in the POTS ports of
the two phones. From the
first port we can not call to the second and from the second port can
not
call to the first port. On the other ONT Huawei
devices, there is no
such
problem. Earlier we had set OpenSIP and this
device did not have a
problem.
The problem is likely in the configuration because it works at the
default
settings.
In the past I ran into other devices/PBXs that can't handle the fact
there is an outgoing/incoming call with the same callid. You could try
the topoh module (with modparam("topoh", "mask_callid", 1))
Beware that it might introduce other problems in some calls scenarios,
my prefered solution is to route the call to a b2bua (asterisk) when I
detected hairpinning.
_______________________________________________
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
2870
days inactive
2907
days old
5 comments
3 participants
participants (3)
-
Daniel Tryba -
Daniel-Constantin Mierla -
Mx R