Hi, Ranga.

On Tue, Dec 23, 2008 at 6:45 PM, M. Ranganathan <[email protected]> wrote:
> On Tue, Dec 23, 2008 at 2:43 PM, Melcon Moraes <[email protected]> wrote:
>> Hello, list.
>>
>> I was wondering if Mr. Ranga or any other sipXbridge/sipXrelay guru
>> would take a look at this and shed some light on it.
>>
>> My scenario is: Incoming call from ITSP -> Gateway -> sipXbridge ->
>> sipXproxy -> UA
>>
>> sipXproxy: 10.0.0.17:5060
>> sipXbridge Internal: 10.0.0.17:5090
>> sipXbridge External:10.0.0.17:5080
>> Polycom 330: 10.0.0.146 - extension 9461
>> Gateway: 10.0.0.19:5060
>>
>> In merged_in_9461.xml
>> Frame #9: Call Starts from 1194753430 to 9461
>> Frame #28: 200 back to the gateway, with Public Address as Media
>> Description(201.7.98.234) instead of 10.0.0.17
>
> You should set up to use private addressing if thats what you want.
> There is a setting in the ITSP page that allows you to specify that.
>

Would that be "Use public address for call setup" unckeched, which is
<register-on-initialization>false</register-on-initialization> on
sipxbridge.xml?

I tried both ways and the results were the same.

>
>>
>> In sipxbridge.log, lines #29 and #30 shows SDP after fixup, which
>> seems to be the place where the changes are happenning.
>>
>>
>> I'm running sipxecs 3.11.9-014285 on FC8.
>>
>>
>> I have also another question regarding the CallerID for outgoing
>> calls. In some earlier versions of sipXbridge(r13002) there was an
>> option <use-registration-for-caller-id>false</use-registration-for-caller-id>
>> inside <itsp-account/> that set as false, sent the outgoing call
>> CallerID as the extension making the call. The scenario is  the same
>> as above.
>>
>> For instance, extension 200 would reach the ITSP side as:
>>
>> <snip>
>>  From: "User Name Here" <sip:2...@sipx_domain>;tag=4701580298343723172
>
>
>
> That would not be what ITSPs want to see in general. Which ITSP wants
> your sipx-domain in the From header?
>

Sorry, I think I didn't make myself clear. The sipXbridge is talking
to a gateway, not a real ITSP. It really don't care about the sipx
domain. What matters the most to it is the user part, like 200 in the
above sample.

>
>> ...
>> Contact: <sip:itsp_accountn...@sipxbridge_ipaddr:ext_port;transport=udp>
>> </snip>
>>
>> Now, there is no such option to set and no matter which extension you
>> have, all the INVITES come as:
>>
>> <snip>
>>  From: "User Name Here" <sip:itsp_accountn...@ipaddr>;tag=4701580298343723172
>> ...
>
>
>
> Even if you set your gateway caller ID, the From headers will ALL have
> the same value. They will all be the caller-ID you set in the trunking
> gateway configuration.
>
>
>
>
>> Contact: <sip:itsp_accountn...@sipxbridge_ipaddr:ext_port;transport=udp>
>> </snip>
>>
>> I've tried to play with Caller ID Transformation for the Sip
>> Trunk/Caller ID but without success. Any thougths on this too?
>
>
> If you set the caller-ID it ought to use that in the From header of
> the outbound call for all calls that are routed to the ITSP via that
> trunking gateway.
> If this behavior is not the case, there is a bug and I'll look into it.
>

What I did for caller-ID Transformatios was:
 1 - Checked  "Transform extension"
 2 - Put number 2 inside "Caller ID Prefix"
 3 - Kept "Keep Digits" as 0

The From header was changed to what was set by transformation, on the
"internal side". The external INVITE had same format as before.

What I want is to set the From header of the outbound calls routed
through sipXbridge/SipTrunk as the extension making the call.

Does all this make any sense?

-MM

>>
>> Please let me know if you need more info.
>>
>> Thanks in advance for your time.
>>
>> -MM
>>
>> _______________________________________________
>> sipx-dev mailing list
>> [email protected]
>> List Archive: http://list.sipfoundry.org/archive/sipx-dev
>> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
>>
>
>
>
> --
> M. Ranganathan
>
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

Reply via email to