[Freeswitch-users] in/outbound-use-uuid-as-callid as channel variables

[Jeff Pyle]

I spoke too soon.  Exporting sip_call_id doesn't throw an error, but it
doesn't seem to do anything either.  I'm not sure what I was looking at the
first time.

Your second recommendation of setting the origination_uuid and having the
outbound param set does indeed work for.  Triple checked.  :)


Thanks,
Jeff


On Wed, Aug 21, 2013 at 1:22 PM, Jeff Pyle <jpyle at fidelityvoice.com> wrote:

> You're right, I had quite a bit wrong.  This is very helpful.
>
> Exporting sip_call_id works.  Thanks!
>
>
>
> - Jeff
>
>
>
> On Wed, Aug 21, 2013 at 9:53 AM, Steven Ayre <steveayre at gmail.com> wrote:
>
>> They didn't seem to have any effect - I still saw a new SIP callid on the
>>> b-leg INVITE
>>
>>
>> Perhaps you're misunderstanding the purpose of them.
>>
>> Every channel in FreeSWITCH has a UUID. On a bridge you have two
>> different channels (inbound & outbound). Their UUIDs -must- be different,
>> to tell them apart.
>>
>> The setting you found sets the UUID from the Call-ID on the inbound
>> channel, and visa versa for the outbound channel. That mostly makes it
>> easier to match up packet traces to calls, and your CDRs to a customers
>> (since they know the Call-ID but not your internal UUID).
>>
>> If you set both the UUID of the incoming channel will be the incoming
>> Call-ID, the outgoing UUID will be generated by FreeSWITCH and the outgoing
>> Call-ID will match the outgoing UUID. You cannot set the same UUID for both.
>>
>> Have you tried exporting the sip_call_id variable from the aleg to the
>> bleg? I don't know if that variable is read-only though. If sofia will read
>> from that should be sufficient, you won't need to tweak the UUIDs of the
>> channels.
>>
>> If that doesn't work you could also try setting origination_uuid to
>> sip_call_id in the bridge dialstring, along with the outgoing parameter you
>> found.
>>
>> -Steve
>>
>>
>>
>> On 21 August 2013 13:21, Jeff Pyle <jpyle at fidelityvoice.com> wrote:
>>
>>> I was afraid of that on the inbound side.  It makes sense.
>>>
>>> The short answer is sometimes I want full topology-hiding, other times I
>>> want the same SIP callid all the way through.  Managing it per-profile
>>> could work.  It has to do with correlating voice-quality monitoring on the
>>> private side with other measurements from the public side.  In cases where
>>> this happens, the same callid on both sides makes things much, much easier.
>>>
>>> Yesterday I tried enabling both inbound-use-callid-as-uuid and
>>> outbound-use-uuid-as-callid on both the public and private profiles.  They
>>> didn't seem to have any effect - I still saw a new SIP callid on the b-leg
>>> INVITE.  I wasn't sure how to debug it from there.
>>>
>>>
>>> - Jeff
>>>
>>>
>>> On Wed, Aug 21, 2013 at 6:17 AM, Steven Ayre <steveayre at gmail.com>wrote:
>>>
>>>> It would be too late for inbound in the dialplan as the channel already
>>>> exists, therefore already has a uuid. Though you can change the uuid, you'd
>>>> still have issues whenever a call hung up so quickly it never reached the
>>>> dialplan (yes, I've seen that happen).
>>>>
>>>> Outbound you may have a chance with - but I don't know if such a
>>>> variable exists.
>>>>
>>>> Is there a reason you can't just set it on the profile?
>>>>
>>>>
>>>>
>>>> On Tuesday, August 20, 2013, Jeff Pyle wrote:
>>>>
>>>>>  Hello,
>>>>>
>>>>> Is it possible to set the equivalent of inbound-use-uuid-as-callid
>>>>> or outbound-use-uuid-as-callid per channel from within the dialplan?
>>>>>
>>>>>
>>>>> - Jeff
>>>>>
>>>>>
>>>>
>>>> _________________________________________________________________________
>>>> Professional FreeSWITCH Consulting Services:
>>>> consulting at freeswitch.org
>>>> http://www.freeswitchsolutions.com
>>>>
>>>> 
>>>> 
>>>>
>>>> Official FreeSWITCH Sites
>>>> http://www.freeswitch.org
>>>> http://wiki.freeswitch.org
>>>> http://www.cluecon.com
>>>>
>>>> FreeSWITCH-users mailing list
>>>> FreeSWITCH-users at lists.freeswitch.org
>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>> UNSUBSCRIBE:
>>>> http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>> http://www.freeswitch.org
>>>>
>>>>
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> 
>>> 
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130821/e2eb6dfd/attachment.html