On Tue, Dec 23, 2008 at 4:57 PM, Melcon Moraes <[email protected]> wrote:
> 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.
Please use sipxconfig to configure your "ITSP" account.
<itsp-account>
................
<use-global-addressing>true</use-global-addressing>
................
</itsp-account>
>
>>
>>>
>>> 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?
Yes it does. I will look at my code. There is possibly a bug.
>
> -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
>>
>
--
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
