Re: [OpenSIPS-Users] B2BUA Ripping/Truncating Callid
Out of curiosity, based on the feedback in this bug; is this something that's being fixed? I notice this bug was for 1.6.4, but my experience is in 1.7.1. so I want to make sure if this was fixed, I report a new bug for 1.7.1Hi Bogdan,
This bug fix requires further work in tm module, in local_route processing,
so as to update the shortcuts in tm when lumps are applied for headers
also. The fix that was committed last week solved this problem only when
body lumps were applied.
Unfortunately, I don't have time to work on this, so I have removed the
assignation to me for this bug report.
Regards,
AncaOn Dec 12, 2011, at 09:05 AM, Ovidiu Sas o...@voipembedded.com wrote:Yes, indeed. Thanks for pointing out. Regards, Ovidiu Sas On Mon, Dec 12, 2011 at 1:26 AM, Ryan Bullock rrb3...@gmail.com wrote: I think this is related to a bug that is already open: http://sourceforge.net/tracker/?func=detailaid=3316230group_id=232389atid=1086410On Fri, Dec 9, 2011 at 5:46 PM, Ovidiu Sas o...@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.comOn Fri, Dec 9, 2011 at 1:52 PM, Logan voipmas...@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@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:888444@192.168.1.137;tag=as06eabdcd. Call-ID: 40c30c6459b3eaa4683991082381cadb@192.168.1.137. To: "12125551212" sip:12125551212@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:888444@192.168.1.137;tag=as06eabdcd. Call-ID: 40c30c6459b3eaa4683991082381cadb@192.168.1.137. To: "12125551212" sip:12125551212@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@10.2.3.245sip:888444@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@192.168.1.137. Contact: sip:192.168.1.145:5090. . On Dec 07, 2011, at 05:18 PM, Ovidiu Sas o...@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 voipmas...@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 o...@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 voipmas...@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 o...@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
Re: [OpenSIPS-Users] B2BUA Ripping/Truncating Callid
It was not fixed. It is the same bug.
Regards,
Ovidiu Sas
On Thu, Dec 15, 2011 at 3:20 PM, Logan voipmas...@me.com wrote:
Out of curiosity, based on the feedback in this bug; is this something
that's being fixed? I notice this bug was for 1.6.4, but my experience is in
1.7.1. so I want to make sure if this was fixed, I report a new bug for
1.7.1
Hi Bogdan,
This bug fix requires further work in tm module, in local_route processing,
so as to update the shortcuts in tm when lumps are applied for headers
also. The fix that was committed last week solved this problem only when
body lumps were applied.
Unfortunately, I don't have time to work on this, so I have removed the
assignation to me for this bug report.
Regards,
Anca
On Dec 12, 2011, at 09:05 AM, Ovidiu Sas o...@voipembedded.com wrote:
Yes, indeed. Thanks for pointing out.
Regards,
Ovidiu Sas
On Mon, Dec 12, 2011 at 1:26 AM, Ryan Bullock rrb3...@gmail.com wrote:
I think this is related to a bug that is already open:
http://sourceforge.net/tracker/?func=detailaid=3316230group_id=232389atid=1086410
On Fri, Dec 9, 2011 at 5:46 PM, Ovidiu Sas o...@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 voipmas...@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@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:888444@192.168.1.137;tag=as06eabdcd.
Call-ID: 40c30c6459b3eaa4683991082381cadb@192.168.1.137.
To: 12125551212 sip:12125551212@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:888444@192.168.1.137;tag=as06eabdcd.
Call-ID: 40c30c6459b3eaa4683991082381cadb@192.168.1.137.
To: 12125551212
sip:12125551212@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@10.2.3.245sip:888444@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@192.168.1.137.
Contact: sip:192.168.1.145:5090.
.
On Dec 07, 2011, at 05:18 PM, Ovidiu Sas o...@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 voipmas...@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 o...@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 voipmas...@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
Re: [OpenSIPS-Users] B2BUA Ripping/Truncating Callid
Yes, indeed. Thanks for pointing out.
Regards,
Ovidiu Sas
On Mon, Dec 12, 2011 at 1:26 AM, Ryan Bullock rrb3...@gmail.com wrote:
I think this is related to a bug that is already open:
http://sourceforge.net/tracker/?func=detailaid=3316230group_id=232389atid=1086410
On Fri, Dec 9, 2011 at 5:46 PM, Ovidiu Sas o...@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 voipmas...@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@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:888444@192.168.1.137;tag=as06eabdcd.
Call-ID: 40c30c6459b3eaa4683991082381cadb@192.168.1.137.
To: 12125551212 sip:12125551212@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:888444@192.168.1.137;tag=as06eabdcd.
Call-ID: 40c30c6459b3eaa4683991082381cadb@192.168.1.137.
To: 12125551212
sip:12125551212@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@10.2.3.245sip:888444@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@192.168.1.137.
Contact: sip:192.168.1.145:5090.
.
On Dec 07, 2011, at 05:18 PM, Ovidiu Sas o...@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 voipmas...@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 o...@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 voipmas...@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 o...@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 voipmas...@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@192.168.1.145:5090 SIP/2.0.
Via: SIP/2.0/UDP 192.168.1.143;branch=z9hG4bKac0e.5a3d2bf1.0.
From: 8669800222
Re: [OpenSIPS-Users] B2BUA Ripping/Truncating Callid
I think this is related to a bug that is already open:
http://sourceforge.net/tracker/?func=detailaid=3316230group_id=232389atid=1086410
On Fri, Dec 9, 2011 at 5:46 PM, Ovidiu Sas o...@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 voipmas...@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@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:888444@192.168.1.137;tag=as06eabdcd.
Call-ID: 40c30c6459b3eaa4683991082381cadb@192.168.1.137.
To: 12125551212 sip:12125551212@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:888444@192.168.1.137;tag=as06eabdcd.
Call-ID: 40c30c6459b3eaa4683991082381cadb@192.168.1.137.
To: 12125551212
sip:12125551212@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@10.2.3.245sip:888444@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@192.168.1.137.
Contact: sip:192.168.1.145:5090.
.
On Dec 07, 2011, at 05:18 PM, Ovidiu Sas o...@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 voipmas...@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 o...@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 voipmas...@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 o...@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 voipmas...@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@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@192.168.1.1;tag=3532277698-944952.
Call-ID: 494823-3532277698-944947@192.168.1.1.
To: 18045551212 sip:18045551212@192.168.1.143.
CSeq: 1 CANCEL.
Re: [OpenSIPS-Users] B2BUA Ripping/Truncating Callid
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@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:888444@192.168.1.137;tag=as06eabdcd.
Call-ID: 40c30c6459b3eaa4683991082381cadb@192.168.1.137.
To: "12125551212" sip:12125551212@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:888444@192.168.1.137;tag=as06eabdcd.
Call-ID: 40c30c6459b3eaa4683991082381cadb@192.168.1.137.
To: "12125551212" sip:12125551212@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@10.2.3.245sip:888444@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@192.168.1.137.
Contact: sip:192.168.1.145:5090.
.On Dec 07, 2011, at 05:18 PM, Ovidiu Sas o...@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 voipmas...@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 o...@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 voipmas...@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 o...@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 voipmas...@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@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@192.168.1.1;tag=3532277698-944952. Call-ID: 494823-3532277698-944947@192.168.1.1. To: "18045551212" sip:18045551212@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@192.168.1.1;tag=3532277698-944952. Call-ID: 494823-3532277698-944947@192.168.1.1. To: "18045551212" sip:18045551212@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
Re: [OpenSIPS-Users] B2BUA Ripping/Truncating Callid
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 voipmas...@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@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:888444@192.168.1.137;tag=as06eabdcd.
Call-ID: 40c30c6459b3eaa4683991082381cadb@192.168.1.137.
To: 12125551212 sip:12125551212@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:888444@192.168.1.137;tag=as06eabdcd.
Call-ID: 40c30c6459b3eaa4683991082381cadb@192.168.1.137.
To: 12125551212
sip:12125551212@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@10.2.3.245sip:888444@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@192.168.1.137.
Contact: sip:192.168.1.145:5090.
.
On Dec 07, 2011, at 05:18 PM, Ovidiu Sas o...@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 voipmas...@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 o...@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 voipmas...@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 o...@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 voipmas...@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@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@192.168.1.1;tag=3532277698-944952.
Call-ID: 494823-3532277698-944947@192.168.1.1.
To: 18045551212 sip:18045551212@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
[OpenSIPS-Users] B2BUA Ripping/Truncating Callid
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@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@192.168.1.1;tag=3532277698-944952. Call-ID: 494823-3532277698-944947@192.168.1.1. To: "18045551212" sip:18045551212@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@192.168.1.1;tag=3532277698-944952. Call-ID: 494823-3532277698-944947@192.168.1.1. To: "18045551212" sip:18045551212@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@65.211.120.23 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.145:5090;branch=z9hG4bK0299.252f8e61.0. . From: sip:7324812444@66.29.74.37;tag=418802140f6308e008db76a1e1de765b. CSeq: 2 INVITE54.7172739. Content-Lengt To: sip:+18045551212@65.211.120.237. Call- CANCEL. User-Agent: OpenSIPS (1.7.1-notls (x86_64/linux)). Max-Forwards: 70. Init-CallID: 494823-3532277698-944947@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. . ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] B2BUA Ripping/Truncating Callid
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 voipmas...@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@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@192.168.1.1;tag=3532277698-944952. Call-ID: 494823-3532277698-944947@192.168.1.1. To: 18045551212 sip:18045551212@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@192.168.1.1;tag=3532277698-944952. Call-ID: 494823-3532277698-944947@192.168.1.1. To: 18045551212 sip:18045551212@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@65.211.120.23 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.145:5090;branch=z9hG4bK0299.252f8e61.0. . From: sip:7324812444@66.29.74.37;tag=418802140f6308e008db76a1e1de765b. CSeq: 2 INVITE54.7172739. Content-Lengt To: sip:+18045551212@65.211.120.237. Call- CANCEL. User-Agent: OpenSIPS (1.7.1-notls (x86_64/linux)). Max-Forwards: 70. Init-CallID: 494823-3532277698-944947@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. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] B2BUA Ripping/Truncating Callid
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 o...@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 voipmas...@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@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@192.168.1.1;tag=3532277698-944952. Call-ID: 494823-3532277698-944947@192.168.1.1. To: "18045551212" sip:18045551212@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@192.168.1.1;tag=3532277698-944952. Call-ID: 494823-3532277698-944947@192.168.1.1. To: "18045551212" sip:18045551212@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@65.211.120.23 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.145:5090;branch=z9hG4bK0299.252f8e61.0. . From: sip:7324812444@66.29.74.37;tag=418802140f6308e008db76a1e1de765b. CSeq: 2 INVITE54.7172739. Content-Lengt To: sip:+18045551212@65.211.120.237. Call- CANCEL. User-Agent: OpenSIPS (1.7.1-notls (x86_64/linux)). Max-Forwards: 70. Init-CallID: 494823-3532277698-944947@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. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] B2BUA Ripping/Truncating Callid
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 voipmas...@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 o...@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 voipmas...@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@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@192.168.1.1;tag=3532277698-944952. Call-ID: 494823-3532277698-944947@192.168.1.1. To: 18045551212 sip:18045551212@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@192.168.1.1;tag=3532277698-944952. Call-ID: 494823-3532277698-944947@192.168.1.1. To: 18045551212 sip:18045551212@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@65.211.120.23 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.145:5090;branch=z9hG4bK0299.252f8e61.0. . From: sip:7324812444@66.29.74.37;tag=418802140f6308e008db76a1e1de765b. CSeq: 2 INVITE54.7172739. Content-Lengt To: sip:+18045551212@65.211.120.237. Call- CANCEL. User-Agent: OpenSIPS (1.7.1-notls (x86_64/linux)). Max-Forwards: 70. Init-CallID: 494823-3532277698-944947@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. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] B2BUA Ripping/Truncating Callid
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 o...@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 voipmas...@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 o...@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 voipmas...@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@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@192.168.1.1;tag=3532277698-944952. Call-ID: 494823-3532277698-944947@192.168.1.1. To: "18045551212" sip:18045551212@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@192.168.1.1;tag=3532277698-944952. Call-ID: 494823-3532277698-944947@192.168.1.1. To: "18045551212" sip:18045551212@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@65.211.120.23 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.145:5090;branch=z9hG4bK0299.252f8e61.0. . From: sip:7324812444@66.29.74.37;tag=418802140f6308e008db76a1e1de765b. CSeq: 2 INVITE54.7172739. Content-Lengt To: sip:+18045551212@65.211.120.237. Call- CANCEL. User-Agent: OpenSIPS (1.7.1-notls (x86_64/linux)). Max-Forwards: 70. Init-CallID: 494823-3532277698-944947@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. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] B2BUA Ripping/Truncating Callid
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 voipmas...@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 o...@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 voipmas...@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 o...@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 voipmas...@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@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@192.168.1.1;tag=3532277698-944952.
Call-ID: 494823-3532277698-944947@192.168.1.1.
To: 18045551212 sip:18045551212@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@192.168.1.1;tag=3532277698-944952.
Call-ID: 494823-3532277698-944947@192.168.1.1.
To: 18045551212
sip:18045551212@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@65.211.120.23 SIP/2.0.
Via: SIP/2.0/UDP 192.168.1.145:5090;branch=z9hG4bK0299.252f8e61.0.
.
From: sip:7324812444@66.29.74.37;tag=418802140f6308e008db76a1e1de765b.
CSeq: 2 INVITE54.7172739.
Content-Lengt
To: sip:+18045551212@65.211.120.237.
Call- CANCEL.
User-Agent: OpenSIPS (1.7.1-notls (x86_64/linux)).
Max-Forwards: 70.
Init-CallID: 494823-3532277698-944947@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.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
VoIP Embedded, Inc.
http://www.voipembedded.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
