date:20120703

Re: [SR-Users] uac module From header rewriting problems

2012-07-03 Thread Daniel-Constantin Mierla


Hello,

On 7/3/12 8:02 AM, Timo Teras wrote:

Hi,

I fixed some uac From rewriting issues in commit e1d1c774c9ac0b4d,
however even with the latest versions I'm still seeing corruption in
 From headers when they are rewritten for the whole dialogue
(from_restore_mode=auto, the default).

I spent some time analyzing the problem and the problem seems to be
connected with the fact that only the bitwise difference of the
original and modified URI are stored (XOR).  The only purpose for this
appears to be the idea to save only the difference in the rr params
instead of two full URIs.

However, it appears that in many cases (especially call transfer) the
 From header will be altered during dialogue. This is explicitly allowed
in RFC 3261 § 20.20:
The From header field indicates the initiator of the request.  This
may be different from the initiator of the dialog.

I've seen this in practise with few commercial SIP stacks. Sometimes
the changes are minor, or even trivial - but with the difference
encoding having even one character changed (e.g. case), being deleted or
added will result in the whole header being corrupted.

I'm now wondering if we should just store both URIs in the rr params.
While taking little more space, it should fix us sending garbage to the
wire (which usually results in dropped call as the remote will reject
the garbage messages).

Any better ideas?


it makes sense storing the entire value. Not sure if anyone else will 
want to be made configurable via mod param, I will go for simplest 
approach and have only the correct option, it will help in code maintenance.


Cheers,
Daniel

--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - 
http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - 
http://asipto.com/u/kpw


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Releasing v3.1.6 - end of packaging maintenance for 3.1 branch

2012-07-03 Thread Daniel-Constantin Mierla


Hello,

in the near future I will package 3.1.6 to mark the end of releasing 
from 3.1 branch. Of course, patches can still go into that branch, but 
there is no intent to package again from it.


If anyone is willing to push other commits before the packages, please 
do it in then next 1-2 days. I will do it when I get enough spare time 
for it, with a short notice before it in that day.


Cheers,
Daniel

--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - 
http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - 
http://asipto.com/u/kpw


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Event when location expires?

2012-07-03 Thread Niklas Larsson

Hi all,

is there a way to get a event / log / something when an registry expires?

/niklas

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] uac module From header rewriting problems

2012-07-03 Thread Timo Teras

On Tue, 03 Jul 2012 12:16:38 +0200 Daniel-Constantin Mierla
 wrote:

> Hello,
> 
> On 7/3/12 8:02 AM, Timo Teras wrote:
> > Hi,
> >
> > I fixed some uac From rewriting issues in commit e1d1c774c9ac0b4d,
> > however even with the latest versions I'm still seeing corruption in
> >  From headers when they are rewritten for the whole dialogue
> > (from_restore_mode=auto, the default).
> >
> > I spent some time analyzing the problem and the problem seems to be
> > connected with the fact that only the bitwise difference of the
> > original and modified URI are stored (XOR).  The only purpose for
> > this appears to be the idea to save only the difference in the rr
> > params instead of two full URIs.
> >
> > However, it appears that in many cases (especially call transfer)
> > the From header will be altered during dialogue. This is explicitly
> > allowed in RFC 3261 § 20.20:
> > The From header field indicates the initiator of the request.
> > This may be different from the initiator of the dialog.
> >
> > I've seen this in practise with few commercial SIP stacks. Sometimes
> > the changes are minor, or even trivial - but with the difference
> > encoding having even one character changed (e.g. case), being
> > deleted or added will result in the whole header being corrupted.
> >
> > I'm now wondering if we should just store both URIs in the rr
> > params. While taking little more space, it should fix us sending
> > garbage to the wire (which usually results in dropped call as the
> > remote will reject the garbage messages).
> >
> > Any better ideas?
> 
> it makes sense storing the entire value. Not sure if anyone else will 
> want to be made configurable via mod param, I will go for simplest 
> approach and have only the correct option, it will help in code
> maintenance.

Sounds good. Should probably do it for the stable branches too. I can
help with some of this, if needed. You have any estimate for the fix?

- Timo

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] ACK and BYE messages uses wrong socket.

2012-07-03 Thread Gary Chen

Kamailio 3.2.0
I am trying to setup kamailio to do the sip trunking. It  receive the sip 
traffic from customer and then send it to carrier.
I have two NIC interface's assigned with three IP's:
Interface 1: ( Public IP's)
x.x.130.34
x.x.130.36  floating IP
interface 2: (private IP's)
10.10.1.31

.36 is a floating IP  assigned by Linux-HA (heartbeat/pacemaker).

I only want to use .36 to receive and send sip traffic.
I uses  force_send_socket() to send INVITE with .36 IP.  But the ACK message 
always want to use .34 IP even the Route header has .36 in it unless I force it 
with force_send_socket() .

How can I fix this problem?
See below for the SIP messages: (x.x.128.205 is customer IP, x.x.129.200 is 
PSTN gateway IP)
U x.x.128.205:51694 -> x.x.130.36:5060
  INVITE sip:5033441174@x.x.130.36:5060 SIP/2.0..Via: SIP/2.0/UDP  
x.x.128.205:5060;branch=z9hG
  4bK1D3CD1..From: ;tag=24513088-D59..To: 
..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 
1887588D-C44B11E1-BE38D697-98A3E39A@x.x.128.20
  5..Supported: 100rel,timer,replaces..Min-SE:  1800..Cisco-Guid: 
411443261-3293254113-3191264919-256
  0877466..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, 
CANCEL, ACK, PRACK, CO
  MET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 101 
INVITE..Max-Forwards: 70..Remote-P
  arty-ID: 
;party=calling;screen=no;privacy=off..Timestamp: 
1341322661
  ..Contact: ..Expires: 180..Allow-Events: 
telephone-event..Conte
  nt-Type: application/sdp..Content-Length: 
366v=0..o=CiscoSystemsSIP-GW-UserAgent 9094 579 IN IP
  4 x.x.128.205..s=SIP Call..c=IN IP4 x.x.128.205..t=0 0..m=audio 19312 RTP/AVP 
125 0 18 100 10
  1..c=IN IP4 x.x.128.205..a=rtpmap:125 X-CCD/8000..a=rtpmap:0 
PCMU/8000..a=rtpmap:18 G729/8000..a
  =fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100 
192-194..a=rtpmap:101 telephone-event/8000
  ..a=fmtp:101 0-16..
#
U x.x.130.36:5060 -> x.x.128.205:51694
  SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP  
x.x.128.205:5060;branch=z9
  hG4bK1D3CD1;rport=51694..From: 
;tag=24513088-D59..To: ..Call-ID: 
1887588d-c44b11e1-be38d697-98a3e...@x.x.128.205..cseq: 101 INVITE..Se
  rver: LVS Proxy 1.0..Content-Length: 0
#
U x.x.130.36:5060 -> x.x.129.200:5060
  INVITE sip:15033441174@x.x.129.200:5060 SIP/2.0..Record-Route: 
..Via: S
  IP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0..Via: SIP/2.0/UDP  
x.x.128.205:5060;rport
  =51694;branch=z9hG4bK1D3CD1..From: 
;tag=24513088-D59..To: ..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 
1887588D-C44B11E1-BE38D697-98A3
  E39A@x.x.128.205..Supported: 100rel,timer,replaces..Min-SE:  
1800..Cisco-Guid: 411443261-3293254
  113-3191264919-2560877466..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: 
INVITE, OPTIONS, BYE, CANC
  EL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, 
REGISTER..CSeq: 101 INVITE..Max-Forw
  ards: 69..Remote-Party-ID: 
;party=calling;screen=no;privacy=off..Tim
  estamp: 1341322661..Contact: ..Expires: 
180..Allow-Events: tel
  ephone-event..Content-Type: application/sdp..Content-Length: 
375v=0..o=CiscoSystemsSIP-GW-UserA
  gent 9094 579 IN IP4 10.200.1.51..s=SIP Call..c=IN IP4 10.200.1.51..t=0 
0..m=audio 20464 RTP/AVP 12
  5 0 18 100 101..c=IN IP4 10.200.1.51..a=rtpmap:125 X-CCD/8000..a=rtpmap:0 
PCMU/8000..a=rtpmap:18 G7
  29/8000..a=fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100 
192-194..a=rtpmap:101 telephone-
  event/8000..a=fmtp:101 0-16..a=nortpproxy:yes..
U x.x.129.200:5060 -> x.x.130.36:5060
  SIP/2.0 100 Trying..Via: SIP/2.0/UDP 
x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/UDP  216.4
  9.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: 
;tag=24513088
  -D59..To: ;tag=F0695368-74F..Date: Tue, 03 Jul 
2012 13:37:41 GMT..Cal
  l-ID: 1887588D-C44B11E1-BE38D697-98A3E39A@x.x.128.205..Timestamp: 
1341322661..Server: Cisco-SIPG
  ateway/IOS-12.x..CSeq: 101 INVITE..Allow-Events: 
telephone-event..Content-Length: 0
#
U x.x.129.200:5060 -> x.x.130.36:5060
  SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 
x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/
  UDP  x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: 
;ta
  g=24513088-D59..To: ;tag=F0695368-74F..Date: Tue, 
03 Jul 2012 13:37:4
  1 GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3E39A@x.x.128.205..Timestamp: 
1341322661..Server:
  Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Require: 100rel..RSeq: 
6708..Allow: INVITE, OPTIONS, B
  YE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, 
REGISTER..Allow-Events: tele
  phone-event..Contact: ..Record-Route: 
..Content-Disposition: session;handling=required..Content-Type: 
application/sdp..Content-Length: 2
  90v=0..o=CiscoSystemsSIP-GW-UserAgent 2387 2116 IN IP4 x.x.129.200..s=SIP 
Call..c=IN IP4 216
  .49.129.200..t=0 0..m=audio 18480 RTP/AVP 0 101 100..c=IN IP4 
x.x.129.200..a=rtpmap:0 PCMU/8000.
  .a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=rtpmap:100 
X-NSE/8000..a=fmtp:100 192-194..
#
U x.x.130.36:5060 -> x.x.128.2

Re: [SR-Users] uac module From header rewriting problems

2012-07-03 Thread Daniel-Constantin Mierla



On 7/3/12 3:49 PM, Timo Teras wrote:

On Tue, 03 Jul 2012 12:16:38 +0200 Daniel-Constantin Mierla
 wrote:


Hello,

On 7/3/12 8:02 AM, Timo Teras wrote:

Hi,

I fixed some uac From rewriting issues in commit e1d1c774c9ac0b4d,
however even with the latest versions I'm still seeing corruption in
  From headers when they are rewritten for the whole dialogue
(from_restore_mode=auto, the default).

I spent some time analyzing the problem and the problem seems to be
connected with the fact that only the bitwise difference of the
original and modified URI are stored (XOR).  The only purpose for
this appears to be the idea to save only the difference in the rr
params instead of two full URIs.

However, it appears that in many cases (especially call transfer)
the From header will be altered during dialogue. This is explicitly
allowed in RFC 3261 § 20.20:
 The From header field indicates the initiator of the request.
This may be different from the initiator of the dialog.

I've seen this in practise with few commercial SIP stacks. Sometimes
the changes are minor, or even trivial - but with the difference
encoding having even one character changed (e.g. case), being
deleted or added will result in the whole header being corrupted.

I'm now wondering if we should just store both URIs in the rr
params. While taking little more space, it should fix us sending
garbage to the wire (which usually results in dropped call as the
remote will reject the garbage messages).

Any better ideas?

it makes sense storing the entire value. Not sure if anyone else will
want to be made configurable via mod param, I will go for simplest
approach and have only the correct option, it will help in code
maintenance.

Sounds good. Should probably do it for the stable branches too. I can
help with some of this, if needed. You have any estimate for the fix?


I just expressed my opinion on how to fix it, but there is no plan for 
me to work on it in the near future, being caught in other tasks and 
traveling. So you can go ahead and make a patch to fix it for master, 
then later, based on the impact, it can be backported.


Cheers,
Daniel

--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - 
http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - 
http://asipto.com/u/kpw


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] ACK and BYE messages uses wrong socket.

2012-07-03 Thread Vitaliy Aleksandrov


Have you specified interfaces with "listen" command ?
I had a problem as you described and have fixed it by moving a listen 
directive with a "floating ip" to the top of the list.
So you can try to specify interfaces you will use for SIP and set a 
"virtual ip" at the top of that list.



Kamailio 3.2.0

I am trying to setup kamailio to do the sip trunking. It  receive the 
sip traffic from customer and then send it to carrier.


I have two NIC interface's assigned with three IP's:

Interface 1: ( Public IP's)

x.x.130.34

x.x.130.36  floating IP

interface 2: (private IP's)

10.10.1.31

.36 is a floating IP  assigned by Linux-HA (heartbeat/pacemaker).

I only want to use .36 to receive and send sip traffic.

I uses  force_send_socket() to send INVITE with .36 IP.  But the ACK 
message always want to use .34 IP even the Route header has .36 in it 
unless I force it with force_send_socket() .


How can I fix this problem?

See below for the SIP messages: (x.x.128.205 is customer IP, 
x.x.129.200 is PSTN gateway IP)


U x.x.128.205:51694 -> x.x.130.36:5060

  INVITE sip:5033441174@x.x.130.36:5060 SIP/2.0..Via: SIP/2.0/UDP  
x.x.128.205:5060;branch=z9hG


  4bK1D3CD1..From: ;tag=24513088-D59..To: 


  6>..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 
1887588D-C44B11E1-BE38D697-98A3E39A@x.x.128.20


  5..Supported: 100rel,timer,replaces..Min-SE:  1800..Cisco-Guid: 
411443261-3293254113-3191264919-256


  0877466..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, 
OPTIONS, BYE, CANCEL, ACK, PRACK, CO


  MET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 101 
INVITE..Max-Forwards: 70..Remote-P


  arty-ID: 
;party=calling;screen=no;privacy=off..Timestamp: 
1341322661


  ..Contact: ..Expires: 
180..Allow-Events: telephone-event..Conte


  nt-Type: application/sdp..Content-Length: 
366v=0..o=CiscoSystemsSIP-GW-UserAgent 9094 579 IN IP


  4 x.x.128.205..s=SIP Call..c=IN IP4 x.x.128.205..t=0 0..m=audio 
19312 RTP/AVP 125 0 18 100 10


  1..c=IN IP4 x.x.128.205..a=rtpmap:125 X-CCD/8000..a=rtpmap:0 
PCMU/8000..a=rtpmap:18 G729/8000..a


  =fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100 
192-194..a=rtpmap:101 telephone-event/8000


  ..a=fmtp:101 0-16..

#

U x.x.130.36:5060 -> x.x.128.205:51694

  SIP/2.0 100 trying -- your call is important to us..Via: 
SIP/2.0/UDP  x.x.128.205:5060;branch=z9


  hG4bK1D3CD1;rport=51694..From: 
;tag=24513088-D59..To: 

  4@x.x.130.36>..Call-ID: 
1887588d-c44b11e1-be38d697-98a3e...@x.x.128.205..cseq: 101 INVITE..Se


  rver: LVS Proxy 1.0..Content-Length: 0

#

U x.x.130.36:5060 -> x.x.129.200:5060

  INVITE sip:15033441174@x.x.129.200:5060 SIP/2.0..Record-Route: 
..Via: S


  IP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0..Via: 
SIP/2.0/UDP  x.x.128.205:5060;rport


  =51694;branch=z9hG4bK1D3CD1..From: 
;tag=24513088-D59..To: 

  41174@x.x.130.36>..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 
1887588D-C44B11E1-BE38D697-98A3


  E39A@x.x.128.205..Supported: 100rel,timer,replaces..Min-SE:  
1800..Cisco-Guid: 411443261-3293254


  113-3191264919-2560877466..User-Agent: 
Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, CANC


  EL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, 
REGISTER..CSeq: 101 INVITE..Max-Forw


  ards: 69..Remote-Party-ID: 
;party=calling;screen=no;privacy=off..Tim


  estamp: 1341322661..Contact: 
..Expires: 180..Allow-Events: tel


  ephone-event..Content-Type: application/sdp..Content-Length: 
375v=0..o=CiscoSystemsSIP-GW-UserA


  gent 9094 579 IN IP4 10.200.1.51..s=SIP Call..c=IN IP4 
10.200.1.51..t=0 0..m=audio 20464 RTP/AVP 12


  5 0 18 100 101..c=IN IP4 10.200.1.51..a=rtpmap:125 
X-CCD/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:18 G7


  29/8000..a=fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100 
192-194..a=rtpmap:101 telephone-


  event/8000..a=fmtp:101 0-16..a=nortpproxy:yes..

U x.x.129.200:5060 -> x.x.130.36:5060

  SIP/2.0 100 Trying..Via: SIP/2.0/UDP 
x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/UDP  216.4


  9.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: 
;tag=24513088


  -D59..To: ;tag=F0695368-74F..Date: Tue, 
03 Jul 2012 13:37:41 GMT..Cal


  l-ID: 1887588D-C44B11E1-BE38D697-98A3E39A@x.x.128.205..Timestamp: 
1341322661..Server: Cisco-SIPG


  ateway/IOS-12.x..CSeq: 101 INVITE..Allow-Events: 
telephone-event..Content-Length: 0


#

U x.x.129.200:5060 -> x.x.130.36:5060

  SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 
x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0,SIP/2.0/


  UDP  x.x.128.205:5060;rport=51694;branch=z9hG4bK1D3CD1..From: 
;ta


  g=24513088-D59..To: 
;tag=F0695368-74F..Date: Tue, 03 Jul 2012 
13:37:4


  1 GMT..Call-ID: 
1887588D-C44B11E1-BE38D697-98A3E39A@x.x.128.205..Timestamp: 
1341322661..Server:


  Cisco-SIPGateway/IOS-12.x..CSeq: 101 INVITE..Require: 100rel..RSeq: 
6708..Allow: INVITE, OPTIONS, B


  YE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, 
UPDATE, REGISTER..Allow-Events: tele


  phone-event..Contact: 
..Record-Route:

Re: [SR-Users] Event when location expires?

2012-07-03 Thread Daniel-Constantin Mierla


Hello,

On 7/3/12 2:34 PM, Niklas Larsson wrote:

Hi all,

is there a way to get a event / log / something when an registry expires?


do you want for timer based expiration or for un-registration as well?

iirc, the is a log message, but printed as debug, you can change the 
sources is you need. Then, maybe using pua_usrloc could be useful, as it 
triggers a PUBLISH with each usrloc event...


Cheers,
Daniel

--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - 
http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - 
http://asipto.com/u/kpw


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] ACK and BYE messages uses wrong socket.

2012-07-03 Thread Gary Chen

Yes, I did the same thing as you mentioned and it still doing the same thing. 
Here is my setup:
mhomed=1
listen=udp:x.x.130.36:5060 # external IP
listen=udp:x.x.130.34:5060 # external IP
listen=udp:10.200.1.31:5060 # internal IP

If I removed .130.34, I got error saying no socket found.

Gary Chen
From: sr-users-boun...@lists.sip-router.org 
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Vitaliy Aleksandrov
Sent: Tuesday, July 03, 2012 10:27 AM
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users 
Mailing List
Subject: Re: [SR-Users] ACK and BYE messages uses wrong socket.

Have you specified interfaces with "listen" command ?
I had a problem as you described and have fixed it by moving a listen directive 
with a "floating ip" to the top of the list.
So you can try to specify interfaces you will use for SIP and set a "virtual 
ip" at the top of that list.


Kamailio 3.2.0
I am trying to setup kamailio to do the sip trunking. It  receive the sip 
traffic from customer and then send it to carrier.
I have two NIC interface's assigned with three IP's:
Interface 1: ( Public IP's)
x.x.130.34
x.x.130.36  floating IP
interface 2: (private IP's)
10.10.1.31

.36 is a floating IP  assigned by Linux-HA (heartbeat/pacemaker).

I only want to use .36 to receive and send sip traffic.
I uses  force_send_socket() to send INVITE with .36 IP.  But the ACK message 
always want to use .34 IP even the Route header has .36 in it unless I force it 
with force_send_socket() .

How can I fix this problem?
See below for the SIP messages: (x.x.128.205 is customer IP, x.x.129.200 is 
PSTN gateway IP)
U x.x.128.205:51694 -> x.x.130.36:5060
  INVITE sip:5033441174@x.x.130.36:5060 
SIP/2.0..Via: SIP/2.0/UDP  x.x.128.205:5060;branch=z9hG
  4bK1D3CD1..From: 
;tag=24513088-D59..To:
 mailto:sip:5033441174@x.x.130.3>
  6>..Date: Tue, 03 Jul 2012 13:37:41 GMT..Call-ID: 
1887588D-C44B11E1-BE38D697-98A3E39A@x.x.128.20
  5..Supported: 100rel,timer,replaces..Min-SE:  1800..Cisco-Guid: 
411443261-3293254113-3191264919-256
  0877466..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: INVITE, OPTIONS, BYE, 
CANCEL, ACK, PRACK, CO
  MET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER..CSeq: 101 
INVITE..Max-Forwards: 70..Remote-P
  arty-ID: 
;party=calling;screen=no;privacy=off..Timestamp:
 1341322661
  ..Contact: 
..Expires:
 180..Allow-Events: telephone-event..Conte
  nt-Type: application/sdp..Content-Length: 
366v=0..o=CiscoSystemsSIP-GW-UserAgent 9094 579 IN IP
  4 x.x.128.205..s=SIP Call..c=IN IP4 x.x.128.205..t=0 0..m=audio 19312 RTP/AVP 
125 0 18 100 10
  1..c=IN IP4 x.x.128.205..a=rtpmap:125 X-CCD/8000..a=rtpmap:0 
PCMU/8000..a=rtpmap:18 G729/8000..a
  =fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100 
192-194..a=rtpmap:101 telephone-event/8000
  ..a=fmtp:101 0-16..
#
U x.x.130.36:5060 -> x.x.128.205:51694
  SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP  
x.x.128.205:5060;branch=z9
  hG4bK1D3CD1;rport=51694..From: 
;tag=24513088-D59..To:
 mailto:4@x.x.130.36>>..Call-ID: 
1887588d-c44b11e1-be38d697-98a3e...@x.x.128.205..cseq:
 101 INVITE..Se
  rver: LVS Proxy 1.0..Content-Length: 0
#
U x.x.130.36:5060 -> x.x.129.200:5060
  INVITE 
sip:15033441174@x.x.129.200:5060 
SIP/2.0..Record-Route: ..Via: S
  IP/2.0/UDP x.x.130.36;branch=z9hG4bKc2ce.17a955a3.0..Via: SIP/2.0/UDP  
x.x.128.205:5060;rport
  =51694;branch=z9hG4bK1D3CD1..From: 
;tag=24513088-D59..To:
 mailto:41174@x.x.130.36>>..Date: Tue, 03 Jul 2012 13:37:41 
GMT..Call-ID: 1887588D-C44B11E1-BE38D697-98A3
  E39A@x.x.128.205..Supported: 
100rel,timer,replaces..Min-SE:  1800..Cisco-Guid: 411443261-3293254
  113-3191264919-2560877466..User-Agent: Cisco-SIPGateway/IOS-12.x..Allow: 
INVITE, OPTIONS, BYE, CANC
  EL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, 
REGISTER..CSeq: 101 INVITE..Max-Forw
  ards: 69..Remote-Party-ID: 
;party=calling;screen=no;privacy=off..Tim
  estamp: 1341322661..Contact: 
..Expires:
 180..Allow-Events: tel
  ephone-event..Content-Type: application/sdp..Content-Length: 
375v=0..o=CiscoSystemsSIP-GW-UserA
  gent 9094 579 IN IP4 10.200.1.51..s=SIP Call..c=IN IP4 10.200.1.51..t=0 
0..m=audio 20464 RTP/AVP 12
  5 0 18 100 101..c=IN IP4 10.200.1.51..a=rtpmap:125 X-CCD/8000..a=rtpmap:0 
PCMU/8000..a=rtpmap:18 G7
  29/8000..a=fmtp:18 annexb=yes..a=rtpmap:100 X-NSE/8000..a=fmtp:100 
192-194..a=rtpmap:101 telephone-
  event/8000..a=fmtp:101 0-16..a=nortpproxy:yes..
U x.x.129.200:5060 -> x.x.130.36:5060
  SIP/2.0 100 T

Re: [SR-Users] uac module From header rewriting problems

2012-07-03 Thread Timo Teras

On Tue, 03 Jul 2012 16:23:45 +0200 Daniel-Constantin Mierla
 wrote:

> 
> On 7/3/12 3:49 PM, Timo Teras wrote:
> > On Tue, 03 Jul 2012 12:16:38 +0200 Daniel-Constantin Mierla
> >  wrote:
> >
> >> Hello,
> >>
> >> On 7/3/12 8:02 AM, Timo Teras wrote:
> >>> Hi,
> >>>
> >>> I fixed some uac From rewriting issues in commit e1d1c774c9ac0b4d,
> >>> however even with the latest versions I'm still seeing corruption
> >>> in From headers when they are rewritten for the whole dialogue
> >>> (from_restore_mode=auto, the default).
> >>>
> >>> I spent some time analyzing the problem and the problem seems to
> >>> be connected with the fact that only the bitwise difference of the
> >>> original and modified URI are stored (XOR).  The only purpose for
> >>> this appears to be the idea to save only the difference in the rr
> >>> params instead of two full URIs.
> >>>
> >>> However, it appears that in many cases (especially call transfer)
> >>> the From header will be altered during dialogue. This is
> >>> explicitly allowed in RFC 3261 § 20.20:
> >>>  The From header field indicates the initiator of the request.
> >>> This may be different from the initiator of the dialog.
> >>>
> >>> I've seen this in practise with few commercial SIP stacks.
> >>> Sometimes the changes are minor, or even trivial - but with the
> >>> difference encoding having even one character changed (e.g.
> >>> case), being deleted or added will result in the whole header
> >>> being corrupted.
> >>>
> >>> I'm now wondering if we should just store both URIs in the rr
> >>> params. While taking little more space, it should fix us sending
> >>> garbage to the wire (which usually results in dropped call as the
> >>> remote will reject the garbage messages).
> >>>
> >>> Any better ideas?
> >> it makes sense storing the entire value. Not sure if anyone else
> >> will want to be made configurable via mod param, I will go for
> >> simplest approach and have only the correct option, it will help
> >> in code maintenance.
> > Sounds good. Should probably do it for the stable branches too. I
> > can help with some of this, if needed. You have any estimate for
> > the fix?
> 
> I just expressed my opinion on how to fix it, but there is no plan
> for me to work on it in the near future, being caught in other tasks
> and traveling. So you can go ahead and make a patch to fix it for
> master, then later, based on the impact, it can be backported.

Ah. Ok. "I will go" just sounded like you'll do it. Sorry for
confusion. I'll try to take stab at it then when I get a minute for
it. :)

-Timo

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] uac module From header rewriting problems

[SR-Users] Releasing v3.1.6 - end of packaging maintenance for 3.1 branch

[SR-Users] Event when location expires?

Re: [SR-Users] uac module From header rewriting problems

[SR-Users] ACK and BYE messages uses wrong socket.

Re: [SR-Users] uac module From header rewriting problems

Re: [SR-Users] ACK and BYE messages uses wrong socket.

Re: [SR-Users] Event when location expires?

Re: [SR-Users] ACK and BYE messages uses wrong socket.

Re: [SR-Users] uac module From header rewriting problems

10 matches

Site Navigation

Mail list logo

Footer information