On Tue, 2010-03-02 at 10:21 -0600, Josh Patten wrote: > [repost from sipx-users] > Running 4.1.6-018117 > > Is there anything special I have to set on an Audiocodes Mediant 1000 > gateway to make Shared Call Appearance work with it? > > Here is the scenario I have: > > User initializes shared line and dials an outside number via Mediant > 1000 > User places call on hold > Shared line is not able to be retrieved on any phone except the one > that made the original call. > > When I press the button to retrieve the call I notice it is attempting > to pick up a call with the number 100000000xx where xx is a random > number. It appears that the Audiocodes is inserting a random number in > in the INVITE contact as seen from the Audiocodes log: > > 1d:9h:57m:54s SIP/2.0 180 Ringing Via: SIP/2.0/TCP > 10.200.128.93;branch=z9hG4bK-XX-0328uJgO9HTbnFCoD3kJsqECMQ Via: > SIP/2.0/UDP > 10.200.128.93;branch=z9hG4bK-XX-0325DfZYWRi6jY2SkJh9zhqBTA~`WvTjDDfj7QR0ThyzOXqbw > Via: SIP/2.0/UDP 10.200.129.49;branch=z9hG4bKa96e8187E1A88DEC From: "Shared > Line" <sip:[email protected]>;tag=847C1108-3DB450F9 To: > <sip:[email protected];user=phone>;tag=1c620922335 > Call-ID: [email protected] CSeq: 2 INVITE Contact: > <sip:[email protected]:5060;transport=tcp> Record-Route: > <sip:10.200.128.93:5060;lr;sipXecs-CallDest=LOCL;sipXecs-rs=%2Aauth%7E.%2Afrom%7EODQ3QzExMDgtM0RCNDUwRjk%60%214599e79536b33a11436e0d9a69768533> > Supported: em,timer,replaces,path,early-session,resource-priority Allow: > REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE > Require: 100rel RSeq: 1 Server: Audiocodes-Sip > > I have attached a merge log but it seems pretty obvious what the issue > is here, just need some insight on how to fix it.
OK, *this* merged.xml.bz2 matches your description. The first (failing) retrieval attempt is the INVITE at frame 154. The request-URI is <sip:[email protected];user=phone>, which has the same problem as in the previous trace, the phone has never been informed of that URI, so it has no reason to use it. Compare with the description of the call in the NOTIFY at frame 127. I suspect the phone (PolycomSoundPointIP-SPIP_550-UA/3.2.2.0477) is trying to use the "remote target" URI (which it should), but apply an outbound proxy specification, so it is turning <sip:[email protected]:5060> (which would work) into <sip:[email protected];user=phone> (which doesn't work and there is no reason to expect that it would). If the phone wants to apply an outbound proxy it should use a request-URI of <sip:[email protected]:5060?Route=pbxtest.co.brazos.tx.us>, or simply use a request-URI of <sip:[email protected]:5060> and send the message to <sip:pbxtest.co.brazos.tx.us>. But I might be wrong about this in regard to SA. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
