SIP INVITE Request Port getting messed up

Question

Developing a NAT traversal solution, using resiprocate, it works fine, but often SIP INVITE get's failed particularly on cisco routers

1. SIP REGISTER is sent out by port 1024

Source: 107.108.188.26

Destination:107.108.188.52

User Datagram Protocol, Src Port: 1024 (1024), Dst Port: sip (5060)

enter image description here

2. SIP status 200 OK

Source: 107.108.188.52

Destination:107.108.188.26

User Datagram Protocol, Src Port: sip (5060), Dst Port: 1024 (1024)

3. SIP/SDP INVITE

Source: 107.108.188.52 Destination:107.108.188.26 User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)

enter image description here

Ideally, the sent-by port should be 1024 in step 1 and step 3. Please point me to for any possible reason behind the same

Which machine is yours? The machine sending the REGISTER/INVITE? — Frank Shearar, Mar 22 '13 at 09:36
windows 7 is the machine, INVITE get's failed as port exposed by router becomes default one.. — Rohit, Mar 22 '13 at 09:38
So yours is 107.108.188.26 and the router's on 107.108.188.52? — Frank Shearar, Mar 22 '13 at 09:55

score 0 · Answer 1 · edited Oct 07 '21 at 06:31

0

The To and Contact fields in your REGISTER request both specify port 5060: sip:192.168.5.2@107.108.188.26:5060.

This expresses that you want to receive calls (i.e. INVITEs) on this port. See the rfc.

Change the host part of the uri to 107.108.188.26:1024 instead if you wish to receive the INVITEs on port 1024.

edited Oct 07 '21 at 06:31

Community

1
1

answered Apr 01 '13 at 21:38

Thierry

376
1
6

I realize now that you're complaining about the source port of the INVITE, not the destination. This is not something you can control in the SIP protocol when receiving a first INVITE AFAIK. I think the only way would be to configure your cisco router to use this port. – Thierry Apr 01 '13 at 21:57

score 0 · Accepted Answer · answered Apr 02 '13 at 03:57

Discussed the same and got following conclusion

If RFC5626 (Outbound) is not used on the client side, then resip will route INVITEs to the user based on the information in their Path or Contact headers of the registration request.  You want to try out a repro setting that forces RFC5626 behaviour in the proxy even if the clients to no support it:
# Enable use of flow-tokens in non-outbound cases
# WARNING: Before enabling this, ensure you have a RecordRouteUri setup, or are using
# the alternate transport specification mechanism and defining a RecordRouteUri per
# transport: TransportXRecordRouteUri
EnableFlowTokens = true

SIP INVITE Request Port getting messed up

2 Answers2