" Interpreting the user-part (left of the '@') in a sip url is not possible unless you are authoritative for the domain part (the right side). Many implementations attempt to do this, but it's wrong - no matter what other attributes there are."
My experience is that the telecom community is obsessed with numbers, numbering plans and so on and does not want to grasp that SIP URIs have two parts, user and domain. They want to do everything based on "numbers" and forget the domain. >From the interoperability point of view, they are right as all the other systems they have are based on "numbers". Regards, Gabor -----Original Message----- From: Scott Lawrence [mailto:[email protected]] Sent: 25 February 2009 17:55 To: Gabor Paller Cc: [email protected] Subject: Re: [sipx-users] Best practices for transfer On Wed, 2009-02-25 at 08:55 +0000, Gabor Paller wrote: > Hi, > > I am curious about the best practices for transferring external incoming > calls. > > The scenario is very common: Source (an external number) calls target1 > (an internal number, SipX user). Target1 transfers the call to target2 > (another internal number). This models a common case of a secretary > transferring calls. > > I understand that SIP-wise, the scenario depends on REFER request sent > from target1 device to the device representing the source. As the source > is a PSTN number, the device representing the source is either a gateway > or a SIP trunking equipment which don't know about the target2 internal > number. What is the best way of getting the gateway/trunking equipment > to know about target2? The Refer-To url in the REFER request will be to sip:n...@sipxecs-domain so the device that gets that REFER should send the INVITE for the new call leg to the proxy for sipxecs-domain, which _will_ know what to do with the NNNN extension number. Interpreting the user-part (left of the '@') in a sip url is not possible unless you are authoritative for the domain part (the right side). Many implementations attempt to do this, but it's wrong - no matter what other attributes there are. _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
