With reference to the merged.xml.bz2 attached to the message to sipx-users... (and not to the *different* merged.xml.bz2 attached to the message to sipx-dev -- don't use the same name for two different files, the confusion will be endless!)
On Mon, 2010-03-01 at 10:40 -0600, Josh Patten wrote: > 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. Looking at merged.xml.bz2, I don't see any dialog with the Call-Id you mention above. In regard to the trace you sent, a call is made *from* an outside number (9795745699) via the Mediant *to* 6003. (BTW, always give the extension numbers so readers can correlate your narrative to the trace. Ideally, provide the frame numbers.) One phone puts it on hold, and 3 attempts are made to retrieve it, all of which fail. Then the phone un-holds the call and hangs up. The three retrieval attempts are the INVITEs at frames 173, 201, and 229. They all fail in the same way, the Registrar rejects the request-URIs as unknown. In all cases, the request-URI is <sip:[email protected];user=phone>, which is odd, since that URI is not given as any part of the description of the call in the NOTIFY that informs the phone about the call it is attempting to retrieve. (For example, NOTIFY frame 80.) So the phone has no reason to synthesize such a URI. So it looks to me like a phone error in implementing the retrieval feature. But this is really an SA implementation question, so I'll have to pass it to an expert. Dale _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
