[OpenSIPS-Users] B2BUA Ripping/Truncating Callid

Ovidiu Sas osas at voipembedded.com
Mon Dec 12 15:05:25 CET 2011 

Yes, indeed.  Thanks for pointing out.

Regards,
Ovidiu Sas

On Mon, Dec 12, 2011 at 1:26 AM, Ryan Bullock <rrb3942 at gmail.com> wrote:
> I think this is related to a bug that is already open:
> http://sourceforge.net/tracker/?func=detail&aid=3316230&group_id=232389&atid=1086410
>
>
> On Fri, Dec 9, 2011 at 5:46 PM, Ovidiu Sas <osas at voipembedded.com> wrote:
>> Yeah, it's the first request after the modified INVITE that is
>> malformed (I reproduced this running a snapshot from trunk).  Please
>> open a bug report.
>>
>> Regards,
>> Ovidiu Sas
>>
>> --
>> VoIP Embedded, Inc.
>> http://www.voipembedded.com
>>
>>
>> On Fri, Dec 9, 2011 at 1:52 PM, Logan <voipmaster at me.com> wrote:
>>> I added the log and everything looks fine. It's only adding the PAI to the
>>> initial invite which is what I want. The odd thing is there are no issues
>>> with the invites, it just looks like the Cancel messages that are being
>>> mangled. I posted a separate issue to the list prior to this report but no
>>> one responded, I'm not sure it went through correctly but resulting cancel
>>> coming out of the B2BUA looked like this:
>>>
>>>  Reference:
>>>
>>> 192.168.1.146 = Opensips Proxy
>>> 192.168.1.145 = Opensips B2BUA
>>> 10.2.3.245 = Carrier
>>>
>>>
>>>
>>> U 2011/12/01 22:51:11.558887 192.168.1.146:5060 -> 192.168.1.145:5090
>>> CANCEL sip:9993512125551212 at 192.168.1.145:5090 SIP/2.0.
>>> Via: SIP/2.0/UDP 192.168.1.146;branch=z9hG4bK2df7.78db1d81.0.
>>> From: "James Logan" <sip:8884442222 at 192.168.1.137>;tag=as06eabdcd.
>>> Call-ID: 40c30c6459b3eaa4683991082381cadb at 192.168.1.137.
>>> To: "12125551212" <sip:12125551212 at 192.168.1.146>.
>>> CSeq: 102 CANCEL.
>>> Max-Forwards: 70.
>>> User-Agent: Opensips.
>>> Content-Length: 0.
>>> .
>>>
>>>
>>> U 2011/12/01 22:51:11.559378 192.168.1.145:5090 -> 192.168.1.146:5060
>>> SIP/2.0 200 canceling.
>>> Via: SIP/2.0/UDP 192.168.1.146;branch=z9hG4bK2df7.78db1d81.0.
>>> From: "James Logan" <sip:8884442222 at 192.168.1.137>;tag=as06eabdcd.
>>> Call-ID: 40c30c6459b3eaa4683991082381cadb at 192.168.1.137.
>>> To: "12125551212"
>>> <sip:12125551212 at 192.168.1.146>;tag=3330ae74b9cf9aed85afbc9203dd6238-715f
>>> CSeq: 102 CANCEL.
>>> Server: B2BUA.
>>> Content-Length: 0.
>>> .
>>>
>>>
>>> U 2011/12/01 22:51:11.559527 192.168.1.145:5090 -> 10.2.3.245:5060
>>> CANCEL ............i...............i.. SIP/2.0.
>>> Via: SIP/2.0/UDP 192.168.1.145:5090;branch=z9hG4bK5421.22999dd2.0.
>>> ........B2B.256.3572553sip:+12125551212 at 10.2.3.245sip:8884442222 at 192.168.1.1379120d3`.....p..i...........................................q.i............
>>> ........ CANCEL.
>>> User-Agent: OpenSIPS (1.7.1-notls (x86_64/linux)).
>>> Max-Forwards: 70.
>>> User-Agent: Opensips.
>>> Init-CallID: 40c30c6459b3eaa4683991082381cadb at 192.168.1.137.
>>> Contact: <sip:192.168.1.145:5090>.
>>> .
>>>
>>> On Dec 07, 2011, at 05:18 PM, Ovidiu Sas <osas at voipembedded.com> wrote:
>>>
>>> Add a log and print out what are you adding before adding it and you
>>> will see if it's good or not.
>>>
>>> On Wed, Dec 7, 2011 at 5:13 PM, Logan <voipmaster at me.com> wrote:
>>>> This is the extent of my local route. If the $var is not present, I do not
>>>> add it. Do you see any issue with what I'm doing here?
>>>>
>>>>
>>>> local_route {
>>>>         #xlog("L_INFO","***** IN LOCAL ROUTE ********\n");
>>>>
>>>>         if (is_method("INVITE")) {
>>>>                 if($var(pai_userpart)) {
>>>>                         append_hf("P-Asserted-Identity:
>>>> \"$var(pai_display)\" <sip:$var(pai_userpart)@$Ri>\r\n");
>>>>                 }else{
>>>>                         xlog("L_INFO","PAI is not present, not adding\n");
>>>>                 }
>>>>         }
>>>>
>>>>
>>>> }
>>>>
>>>> On Dec 07, 2011, at 04:57 PM, Ovidiu Sas <osas at voipembedded.com> wrote:
>>>>
>>>> You need to be careful when you alter requests in B2B mode (the
>>>> received INVITE and the sent INVITE belong to different transactions).
>>>> Make sure that you have something valid in those vars before applying
>>>> any changes to the outgoing message.
>>>>
>>>> Regards,
>>>> Ovidiu Sas
>>>>
>>>> On Wed, Dec 7, 2011 at 4:49 PM, Logan <voipmaster at me.com> wrote:
>>>>> I'm storing some $vars in route[0] prior to calling b2b_init_request("top
>>>>> hiding");
>>>>>
>>>>> Then in my local route Im appending a P-Asserted-Identity header.
>>>>>
>>>>> I can't use the custom_headers modparam because it's going to preserve
>>>>> the
>>>>> PAI as it comes in. Most of the time it's not present, or is in the wrong
>>>>> format so I'm adding it in local route.
>>>>>
>>>>>
>>>>> On Dec 07, 2011, at 04:31 PM, Ovidiu Sas <osas at voipembedded.com> wrote:
>>>>>
>>>>> Are you trying to perform any msg manipulations during b2b scenarios?
>>>>> Also, keep in mind that the b2b server functionality must be kept
>>>>> isolated from the proxy server functionality (proxy mode is not
>>>>> compatible with b2b mode).
>>>>>
>>>>> Regards,
>>>>> Ovidiu Sas
>>>>>
>>>>> -- VoIP Embedded, Inc.http://www.voipembedded.com
>>>>> On Wed, Dec 7, 2011 at 3:41 PM, Logan <voipmaster at me.com> wrote:
>>>>>> Hello list this is the second odd thing I've seen with b2bua in opensips
>>>>>> 1.7.1 It looks like the b2bua module is mangling the cancel message and
>>>>>> is
>>>>>> ripping out the callid when sending upstream:
>>>>>>
>>>>>>
>>>>>> U 2011/12/07 20:15:05.895915 192.168.1.143:5060 -> 192.168.1.145:5090
>>>>>>
>>>>>> CANCEL sip:9993518045551212 at 192.168.1.145:5090 SIP/2.0.
>>>>>>
>>>>>> Via: SIP/2.0/UDP 192.168.1.143;branch=z9hG4bKac0e.5a3d2bf1.0.
>>>>>>
>>>>>> From: "8669800222" <sip:8669800222 at 192.168.1.1>;tag=3532277698-944952.
>>>>>>
>>>>>> Call-ID: 494823-3532277698-944947 at 192.168.1.1.
>>>>>>
>>>>>> To: "18045551212" <sip:18045551212 at 192.168.1.143>.
>>>>>>
>>>>>> CSeq: 1 CANCEL.
>>>>>>
>>>>>> Max-Forwards: 70.
>>>>>>
>>>>>> User-Agent: Opensips.
>>>>>>
>>>>>> Content-Length: 0.
>>>>>>
>>>>>> .
>>>>>>
>>>>>>
>>>>>>
>>>>>> U 2011/12/07 20:15:05.896027 192.168.1.145:5090 -> 192.168.1.143:5060
>>>>>>
>>>>>> SIP/2.0 200 canceling.
>>>>>>
>>>>>> Via: SIP/2.0/UDP 192.168.1.143;branch=z9hG4bKac0e.5a3d2bf1.0.
>>>>>>
>>>>>> From: "8669800222" <sip:8669800222 at 192.168.1.1>;tag=3532277698-944952.
>>>>>>
>>>>>> Call-ID: 494823-3532277698-944947 at 192.168.1.1.
>>>>>>
>>>>>> To: "18045551212"
>>>>>>
>>>>>>
>>>>>> <sip:18045551212 at 192.168.1.143>;tag=3330ae74b9cf9aed85afbc9203dd6238-e6b7.
>>>>>>
>>>>>> CSeq: 1 CANCEL.
>>>>>>
>>>>>> Server: Opensips.
>>>>>>
>>>>>> Content-Length: 0.
>>>>>>
>>>>>> .
>>>>>>
>>>>>>
>>>>>>
>>>>>> U 2011/12/07 20:15:05.896097 192.168.1.145:5090 -> 10.2.3.210:5060
>>>>>>
>>>>>> CANCEL sip:+18045551212 at 65.211.120.23 SIP/2.0.
>>>>>>
>>>>>> Via: SIP/2.0/UDP 192.168.1.145:5090;branch=z9hG4bK0299.252f8e61.0.
>>>>>>
>>>>>> .
>>>>>>
>>>>>> From: <sip:7324812444 at 66.29.74.37>;tag=418802140f6308e008db76a1e1de765b.
>>>>>>
>>>>>> CSeq: 2 INVITE54.7172739.
>>>>>>
>>>>>> Content-Lengt
>>>>>>
>>>>>> To: sip:+18045551212 at 65.211.120.237.
>>>>>>
>>>>>> Call- CANCEL.
>>>>>>
>>>>>> User-Agent: OpenSIPS (1.7.1-notls (x86_64/linux)).
>>>>>>
>>>>>> Max-Forwards: 70.
>>>>>>
>>>>>> Init-CallID: 494823-3532277698-944947 at 192.168.1.1.
>>>>>>
>>>>>> Contact: <sip:192.168.1.145:5090>.
>>>>>>
>>>>>> .
>>>>>>
>>>>>>
>>>>>>
>>>>>> U 2011/12/07 20:15:05.910842 10.2.3.210:5060 -> 192.168.1.145:5090
>>>>>>
>>>>>> SIP/2.0 400 Missing Mandatory Header Call-Id.
>>>>>>
>>>>>> v: SIP/2.0/UDP
>>>>>> 192.168.1.145:5090;branch=z9hG4bK0299.252f8e61.0;received=192.168.1.145.
>>>>>>
>>>>>> l: 0.

More information about the Users mailing list