Ivan Pletenev
2012-08-31 08:49:53 UTC
Hi.
I got the same problem - we can't resume external call hold. It happenedafter i did yum update. We use grandstream phones and yealink. Also i tried
call\unhold with iphone sip client media5-fone - no luck. Is there any news
on this problem?
---
Ivan Pletenev
---------- ðÅÒÅÓÙÌÁÅÍÏÅ ÓÏÏÂÝÅÎÉÅ ----------
Date: Thu, 16 Aug 2012 10:41:42 +0800
Subject: Re: [sipx-users] Cisco Hold/Resume
This is the INVITE sent by sipX to extension 9630. Take note of the
following.
2. Record-Route inserted by the proxy is
sip:192.168.2.2:5060;lr; \
sipXecs-CallDest=AL%2CINT; \
sipXecs-rs=%2Aauth%7E.%2Afrom%**7EODg0NzU1NjYx.\
900_ntap%2Aid%7EODQxMC01NDg%**60%**212feeb13001a96c3aa0337ff5b7ad**52d5
Record-Route: <sip:192.168.2.2:5060;lr;**sipXecs-CallDest=AL%2CINT;**
sipXecs-rs=%2Aauth%7E.%2Afrom%**7EODg0NzU1NjYx.900_ntap%2Aid%**
7EODQxMC01NDg%60%**212feeb13001a96c3aa0337ff5b7ad**52d5>
Cseq: 102 INVITE
Via: SIP/2.0/UDP 192.168.2.2;branch=z9hG4bK-XX-**
5573lQWr3kM1kxmqYz5eScEwLQ
Via: SIP/2.0/UDP 192.168.2.2;branch=z9hG4bK-XX-**
5570rFCDUPiSnEcmm2e9jPzGig~**LtZj4yrJmD_vUR1BPFVudQ;id=**8410-548
Via: SIP/2.0/UDP 192.168.2.2;branch=z9hG4bK-XX-**
556aS8mAjSeoiXcrkk_WOyyF`A~**Gb6iTJqTxGrjsIy6_sOZvw
Via: SIP/2.0/UDP 192.168.2.2:5090;branch=**z9hG4bK9e64cce5cb5d8d1e9811532*
*224296858313831;sipxecs-id=**2a38ffa1
Max-Forwards: 16
User-Agent: sipXecs/4.4.0 sipXecs/sipxbridge (Linux)
sipxecs-tag=request-invite-**z9hg4bk4a823cdc
Content-Type: application/sdp
Allow: INVITE,BYE,ACK,CANCEL,REFER,**OPTIONS,PRACK
Supported: replaces,100rel
Content-Length: 254
Date: Wed, 15 Aug 2012 19:15:59 GMT
Alert-Info: <http://external.call>;info=**alert-external;x-line-id=0
Expires: 20
X-Sipx-Handled: X192.168.2.2-60.220.247.5
This is the 200 OK sent back by Cisco. So far so good. It is well
constructed.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.2;branch=z9hG4bK-XX-**
5573lQWr3kM1kxmqYz5eScEwLQ
Via: SIP/2.0/UDP 192.168.2.2;branch=z9hG4bK-XX-**
5570rFCDUPiSnEcmm2e9jPzGig~**LtZj4yrJmD_vUR1BPFVudQ;id=**8410-548
Via: SIP/2.0/UDP 192.168.2.2;branch=z9hG4bK-XX-**
556aS8mAjSeoiXcrkk_WOyyF`A~**Gb6iTJqTxGrjsIy6_sOZvw
Via: SIP/2.0/UDP 192.168.2.2:5090;branch=**z9hG4bK9e64cce5cb5d8d1e9811532*
*224296858313831;sipxecs-id=**2a38ffa1
0d820f78
Date: Wed, 15 Aug 2012 19:11:55 GMT
CSeq: 102 INVITE
Server: Cisco-CP7940G/8.0
Record-Route: <sip:192.168.2.2:5060;lr;**sipXecs-CallDest=AL%2CINT;**
sipXecs-rs=%2Aauth%7E.%2Afrom%**7EODg0NzU1NjYx.900_ntap%2Aid%**
7EODQxMC01NDg%60%**212feeb13001a96c3aa0337ff5b7ad**52d5>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,**OPTIONS,REFER,REGISTER,UPDATE
Supported: replaces,join,norefersub
Content-Length: 207
Content-Type: application/sdp
Content-Disposition: session;handling=optional
This is the REFER and this is where the trouble is.
1. The REFER is being sent to 60.220.247.5:5080. This is the external
address of sipXbridge.
This must be the
destination address for mid-dialog request such as REFER.
2. The route header inserted in the REFER is sip:192.168.2.2:5060;lr;**
sipXecs-CallDest=AL%2CINT.
This is wrong because it is truncated. Route header must be
sip:192.168.2.2:5060;lr; \
sipXecs-CallDest=AL%2CINT; \
sipXecs-rs=%2Aauth%7E.%2Afrom%**7EODg0NzU1NjYx.\
900_ntap%2Aid%7EODQxMC01NDg%**60%**212feeb13001a96c3aa0337ff5b7ad**52d5
REFER sip:60.220.247.5:5080;sipXecs-**CallDest=AL%2CINT SIP/2.0
Via: SIP/2.0/UDP 192.168.2.215:5060;branch=**z9hG4bK22ea1de8
0d820f78
Max-Forwards: 70
Date: Wed, 15 Aug 2012 19:12:09 GMT
CSeq: 102 REFER
User-Agent: Cisco-CP7940G/8.0
Route: <sip:192.168.2.2:5060;lr;**sipXecs-CallDest=AL%2CINT>
1e13d7f6-68b8447a%40192.168.2.**215%3Bto-tag%**3D001da21a556300f5674f3198-
Content-Length: 0
This REFER will be rejected by sipXbridge because it's as funky as it
could get.
Date: Thu, 16 Aug 2012 10:41:42 +0800
Subject: Re: [sipx-users] Cisco Hold/Resume
This is the INVITE sent by sipX to extension 9630. Take note of the
following.
2. Record-Route inserted by the proxy is
sip:192.168.2.2:5060;lr; \
sipXecs-CallDest=AL%2CINT; \
sipXecs-rs=%2Aauth%7E.%2Afrom%**7EODg0NzU1NjYx.\
900_ntap%2Aid%7EODQxMC01NDg%**60%**212feeb13001a96c3aa0337ff5b7ad**52d5
Record-Route: <sip:192.168.2.2:5060;lr;**sipXecs-CallDest=AL%2CINT;**
sipXecs-rs=%2Aauth%7E.%2Afrom%**7EODg0NzU1NjYx.900_ntap%2Aid%**
7EODQxMC01NDg%60%**212feeb13001a96c3aa0337ff5b7ad**52d5>
Cseq: 102 INVITE
Via: SIP/2.0/UDP 192.168.2.2;branch=z9hG4bK-XX-**
5573lQWr3kM1kxmqYz5eScEwLQ
Via: SIP/2.0/UDP 192.168.2.2;branch=z9hG4bK-XX-**
5570rFCDUPiSnEcmm2e9jPzGig~**LtZj4yrJmD_vUR1BPFVudQ;id=**8410-548
Via: SIP/2.0/UDP 192.168.2.2;branch=z9hG4bK-XX-**
556aS8mAjSeoiXcrkk_WOyyF`A~**Gb6iTJqTxGrjsIy6_sOZvw
Via: SIP/2.0/UDP 192.168.2.2:5090;branch=**z9hG4bK9e64cce5cb5d8d1e9811532*
*224296858313831;sipxecs-id=**2a38ffa1
Max-Forwards: 16
User-Agent: sipXecs/4.4.0 sipXecs/sipxbridge (Linux)
sipxecs-tag=request-invite-**z9hg4bk4a823cdc
Content-Type: application/sdp
Allow: INVITE,BYE,ACK,CANCEL,REFER,**OPTIONS,PRACK
Supported: replaces,100rel
Content-Length: 254
Date: Wed, 15 Aug 2012 19:15:59 GMT
Alert-Info: <http://external.call>;info=**alert-external;x-line-id=0
Expires: 20
X-Sipx-Handled: X192.168.2.2-60.220.247.5
This is the 200 OK sent back by Cisco. So far so good. It is well
constructed.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.2;branch=z9hG4bK-XX-**
5573lQWr3kM1kxmqYz5eScEwLQ
Via: SIP/2.0/UDP 192.168.2.2;branch=z9hG4bK-XX-**
5570rFCDUPiSnEcmm2e9jPzGig~**LtZj4yrJmD_vUR1BPFVudQ;id=**8410-548
Via: SIP/2.0/UDP 192.168.2.2;branch=z9hG4bK-XX-**
556aS8mAjSeoiXcrkk_WOyyF`A~**Gb6iTJqTxGrjsIy6_sOZvw
Via: SIP/2.0/UDP 192.168.2.2:5090;branch=**z9hG4bK9e64cce5cb5d8d1e9811532*
*224296858313831;sipxecs-id=**2a38ffa1
0d820f78
Date: Wed, 15 Aug 2012 19:11:55 GMT
CSeq: 102 INVITE
Server: Cisco-CP7940G/8.0
Record-Route: <sip:192.168.2.2:5060;lr;**sipXecs-CallDest=AL%2CINT;**
sipXecs-rs=%2Aauth%7E.%2Afrom%**7EODg0NzU1NjYx.900_ntap%2Aid%**
7EODQxMC01NDg%60%**212feeb13001a96c3aa0337ff5b7ad**52d5>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,**OPTIONS,REFER,REGISTER,UPDATE
Supported: replaces,join,norefersub
Content-Length: 207
Content-Type: application/sdp
Content-Disposition: session;handling=optional
This is the REFER and this is where the trouble is.
1. The REFER is being sent to 60.220.247.5:5080. This is the external
address of sipXbridge.
This must be the
destination address for mid-dialog request such as REFER.
2. The route header inserted in the REFER is sip:192.168.2.2:5060;lr;**
sipXecs-CallDest=AL%2CINT.
This is wrong because it is truncated. Route header must be
sip:192.168.2.2:5060;lr; \
sipXecs-CallDest=AL%2CINT; \
sipXecs-rs=%2Aauth%7E.%2Afrom%**7EODg0NzU1NjYx.\
900_ntap%2Aid%7EODQxMC01NDg%**60%**212feeb13001a96c3aa0337ff5b7ad**52d5
REFER sip:60.220.247.5:5080;sipXecs-**CallDest=AL%2CINT SIP/2.0
Via: SIP/2.0/UDP 192.168.2.215:5060;branch=**z9hG4bK22ea1de8
0d820f78
Max-Forwards: 70
Date: Wed, 15 Aug 2012 19:12:09 GMT
CSeq: 102 REFER
User-Agent: Cisco-CP7940G/8.0
Route: <sip:192.168.2.2:5060;lr;**sipXecs-CallDest=AL%2CINT>
1e13d7f6-68b8447a%40192.168.2.**215%3Bto-tag%**3D001da21a556300f5674f3198-
Content-Length: 0
This REFER will be rejected by sipXbridge because it's as funky as it
could get.
Hi Joegen,
Here's a trace of two external calls to the Cisco phone I made. One was
put on hold and the next one a transfer.
Ly Tran
-----Original Message-----
Sent: Tuesday, August 14, 2012 8:04 PM
To: Discussion list for users of sipXecs software
Cc: Ly Tran
Subject: Re: [sipx-users] Cisco Hold/Resume
You will usually get better results reporting your issues when there is
something the developers could look at. If it's an easy fix, there is no
reason why it can't be fixed. Send a trace/tcp dump.
Here's a trace of two external calls to the Cisco phone I made. One was
put on hold and the next one a transfer.
Ly Tran
-----Original Message-----
Sent: Tuesday, August 14, 2012 8:04 PM
To: Discussion list for users of sipXecs software
Cc: Ly Tran
Subject: Re: [sipx-users] Cisco Hold/Resume
You will usually get better results reporting your issues when there is
something the developers could look at. If it's an easy fix, there is no
reason why it can't be fixed. Send a trace/tcp dump.
The firmware running on the Cisco phones is 8-12. Works only
internally. Cisco to Cisco, LG-Nortel to Cisco and vice versa. Only fails
when calls are coming in externally. Fails on Hold/Resume and in Transfer
mode, presumably because the call is placed on hold and MOH while the
transfer is being initiated.
No have not gotten a capture yet, but can get one.
-----Original Message-----
On Behalf Of Joe
Micciche
Sent: Tuesday, August 14, 2012 1:06 PM
Subject: Re: [sipx-users] Cisco Hold/Resume
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Do you have any traces, logs, tcpdump of the problem?
Does the problem occur only with internal calls? external?
- --
==============================**==============================**======
Red Hat, Inc. http://www.redhat.com
Senior Communications Engineer X (81) 44554
+1.919.754.4554 Key: 65F90FE1
==============================**==============================**======
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAqk2sACgkQJHjEUG**X5D+H5LQCfej+**PKHxv23muKStSGpmlqSwN
DisAoIzIcztGaszz8oBImM7kIwryG3**YD
=yxjE
-----END PGP SIGNATURE-----
______________________________**_________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/**archive/sipx-users/<http://list.sipfoundry.org/archive/sipx-users/>
______________________________**_________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/**archive/sipx-users/<http://list.sipfoundry.org/archive/sipx-users/>
internally. Cisco to Cisco, LG-Nortel to Cisco and vice versa. Only fails
when calls are coming in externally. Fails on Hold/Resume and in Transfer
mode, presumably because the call is placed on hold and MOH while the
transfer is being initiated.
No have not gotten a capture yet, but can get one.
-----Original Message-----
On Behalf Of Joe
Micciche
Sent: Tuesday, August 14, 2012 1:06 PM
Subject: Re: [sipx-users] Cisco Hold/Resume
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I do have a backup, but do not want to go back to 4.2.1.. We did not
have this problem with the last version which was
4.4.0-382.g16f5.x86_64, its with this latest update to 4.4.0-418.
Which firmware are you running on these phones?have this problem with the last version which was
4.4.0-382.g16f5.x86_64, its with this latest update to 4.4.0-418.
Do you have any traces, logs, tcpdump of the problem?
Does the problem occur only with internal calls? external?
- --
==============================**==============================**======
Red Hat, Inc. http://www.redhat.com
Senior Communications Engineer X (81) 44554
+1.919.754.4554 Key: 65F90FE1
==============================**==============================**======
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAqk2sACgkQJHjEUG**X5D+H5LQCfej+**PKHxv23muKStSGpmlqSwN
DisAoIzIcztGaszz8oBImM7kIwryG3**YD
=yxjE
-----END PGP SIGNATURE-----
______________________________**_________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/**archive/sipx-users/<http://list.sipfoundry.org/archive/sipx-users/>
______________________________**_________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/**archive/sipx-users/<http://list.sipfoundry.org/archive/sipx-users/>