What does this have to do with Cisco Hold/Resume. Please start a new thread and somebody might respond. I have ideas but will wait for new thread.
On Fri, Aug 31, 2012 at 4:49 AM, Ivan Pletenev <[email protected]> wrote: > Hi. >> > > I got the same problem - we can't resume external call hold. It happened > after 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 > >> >> ---------- Пересылаемое сообщение ---------- >> From: Joegen Baclor <[email protected]> >> To: Ly Tran <[email protected]>, Discussion list for users of sipXecs >> software <[email protected]> >> Cc: >> 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. >> 1. Contact given by sipXbridge is >> sip:[email protected]:**5090<http://sip:[email protected]:5090> >> 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 >> >> >> INVITE sip:[email protected]:5060;**transport=udp;x-sipX-nonat SIP/2.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> >> Call-Id: 68ea044d15efa3fd534fa8de2e1055**[email protected] >> Cseq: 102 INVITE >> From: "+1512xxxxxxx" <sip:[email protected]**>;tag=884755661 >> To: <sip:[email protected]**> >> 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) >> References: 68ea044d15efa3fd534fa8de2e1055**[email protected];rel=chain;** >> sipxecs-tag=request-invite-**z9hg4bk4a823cdc >> Contact: <sip:[email protected]:**5090;x-sipX-nonat> >> 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 >> From: "+1512xxxxxxx" <sip:[email protected]**>;tag=884755661 >> To: <sip:[email protected]**>;tag=**000f34d70512009962af5853-** >> 0d820f78 >> Call-ID: 68ea044d15efa3fd534fa8de2e1055**[email protected] >> Date: Wed, 15 Aug 2012 19:11:55 GMT >> CSeq: 102 INVITE >> Server: Cisco-CP7940G/8.0 >> Contact: <sip:[email protected]:5060;**transport=udp> >> 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. >> The contact sent by sipXbridge is >> sip:[email protected]:**5090<http://sip:[email protected]:5090>. >> 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 >> From: <sip:[email protected]**>;tag=**000f34d70512009962af5853-** >> 0d820f78 >> To: "+1512xxxxxxx" <sip:[email protected]**>;tag=884755661 >> Call-ID: 68ea044d15efa3fd534fa8de2e1055**[email protected] >> Max-Forwards: 70 >> Date: Wed, 15 Aug 2012 19:12:09 GMT >> CSeq: 102 REFER >> User-Agent: Cisco-CP7940G/8.0 >> Contact: <sip:[email protected]:5060;**transport=udp> >> Route: <sip:192.168.2.2:5060;lr;**sipXecs-CallDest=AL%2CINT> >> Refer-To: <sip:[email protected]?**Replaces=000f34d7-05120006-** >> 1e13d7f6-68b8447a%40192.168.2.**215%3Bto-tag%** >> 3D001da21a556300f5674f3198-**2a615a19%3Bfrom-tag%** >> 3D000f34d70512009a5d3e90f4-**22cea73f<http://sip:[email protected]?Replaces=000f34d7-05120006-1e13d7f6-68b8447a%40192.168.2.215%3Bto-tag%3D001da21a556300f5674f3198-2a615a19%3Bfrom-tag%3D000f34d70512009a5d3e90f4-22cea73f> >> > >> Referred-By: <sip:[email protected]> >> Content-Length: 0 >> >> >> This REFER will be rejected by sipXbridge because it's as funky as it >> could get. >> >> >> >> >> On 08/16/2012 03:43 AM, Ly Tran wrote: >> >>> 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----- >>> From: Joegen Baclor [mailto:[email protected]] >>> 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. >>> >>> On 08/15/2012 05:22 AM, Ly Tran wrote: >>> >>>> 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----- >>>> From: >>>> sipx-users-bounces@list.**sipfoundry.org<[email protected]> >>>> [mailto:sipx-users-bounces@**list.sipfoundry.org<[email protected]>] >>>> On Behalf Of Joe >>>> Micciche >>>> Sent: Tuesday, August 14, 2012 1:06 PM >>>> To: [email protected] >>>> Subject: Re: [sipx-users] Cisco Hold/Resume >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 08/14/2012 12:00 PM, >>>> sipx-users-request@list.**sipfoundry.org<[email protected]>wrote: >>>> >>>>> 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? >>>> >>>> Do you have any traces, logs, tcpdump of the problem? >>>> >>>> Does the problem occur only with internal calls? external? >>>> >>>> - -- >>>> ==============================**==============================**====== >>>> Joe Micciche [email protected] >>>> 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 >>>> [email protected] >>>> List Archive: >>>> http://list.sipfoundry.org/**archive/sipx-users/<http://list.sipfoundry.org/archive/sipx-users/> >>>> ______________________________**_________________ >>>> sipx-users mailing list >>>> [email protected] >>>> List Archive: >>>> http://list.sipfoundry.org/**archive/sipx-users/<http://list.sipfoundry.org/archive/sipx-users/> >>>> >>>> >> > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- Michael Picher, Director of Technical Services eZuce, Inc. 300 Brickstone Square**** Suite 201**** Andover, MA. 01810 O.978-296-1005 X2015 M.207-956-0262 @mpicher <http://twitter.com/mpicher> linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro> www.ezuce.com ------------------------------------------------------------------------------------------------------------ There are 10 kinds of people in the world, those who understand binary and those who don't.
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
