Hi JR You stumbled of a very serious SIP Problem here I think. I also fighting with a Carrier Switch Vendor on what the correct way to send the destination phone number is. The Problem is, the SIP RFCs involved are not precise enough. One interpretation of them is, the To: header should never be altered, no matter if that call got forwarded, because the destination address of the call is in the invite header. Another RFC states, that in a scenario with a dynamic subscription, the content of the Invite Header to the dynamic subscriber has to contain the contact information user for the registration. Example: Register From: Alice(a)example.com Contact: FooBar(a)example.com Now if a call is directed to that subscriber, the Invite which should be generated would look like: INVITE: FooBar(a)example.com From: Bob(a)example.com To: Alice(a)example.com Now consider a forwarding scenario without altering the To Heder: Bob => Charlie (forwarded to Alice) INVITE: Foobar(a)example.com From: Bob(a)example.com To: Charlie(a)example.com Diversion: Charlie(a)example.com,reason=busy Well, as long as you have single extension subscribers, this still works, as the phone will ring withing checking the content of the invite or to header. But now comes the World of SIP Trunk and PBX. A PBX registers with one Contact Header for one or even multiple DDI Ranges. So if the Voice Switch is sending back the Register Contact in the INVITE, the PBX cannot use this field to determine which extension to ring. So it has to use the To: Header. Well, not in a forwarding scenario, the To: header does not contain a valid extension, and the PBX will either invoke a catch-all or simple reply with 404. So how to work around this? Well, you cannot send the Registration Contact in your INVITE Request, but the INVITE has to contain the called extension behind the PBX. All PBX which I know can work this way, this is even mostly the default. BUT, if you have an SBC in between, this is getting tricky, as the SBC usually identifies an dynamic endpoint by the user sent as register contact and expects the invite to contain that contact. So well, if so, the SBC can be instructed to copy the To: user to the Invite User, but again this will fail in forwarded call situations. So from my point of view, the only way to make this work is to ensure that the INVITE header, contains the destination phone number and to ignore the content of the To: header. Of course this makes SBC implementations very tricky, like then you have to start dynamically allocating a IP port for every 'trunk' user you have because the SBC cannot rely on getting the Request Contact in an Invite to a trunk customer. But try to persuade commercial vendors to do this right. Even after they could reproduce and see the problem them self, the reply I got was: "But we have to rely on the RFC and have implemented this the RFC way even if it's broken we cannot fix it". Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________