SIP call ports

[iptsupport]

Hi ,

My setup is calls that come from PSTN to isr 4451 through PRI the call is forwarded through sip to other PBX (NOT CISCO ).
The customer asked to enable the option that the rtp will come back from another port that the one I send it to his PBX .
For example I call to the PBX, call go from cisco port 1000 to the other PBX to port 1500 . They want to return the rtp through port 2000
to cisco port 1000 is it possible ?

[Ayodeji Okanlawon]

RTP is sent to whatever port the PBX indicates it want to use for RTP during media negotiation in SDP. So I dont understand what they are trying to do. There is no returning of RTP. Did the PBX not indicate what port it want use for RTP initially?

[Vivek Batra]

Just to add a point besides my friend Deji has mentioned, RTP ports during SDP exchange is negotiated as listening port, not sending ports. Sender can choose any source port to send RTP packets. Lets take an example,

A calls B

A publish 8000 port in SDP offer.

B answers and publish 9000 in SDP answer.

Since A has published 8000 as its RTP port, this means that B is restricted to send RTP to A on port 8000. At this moment, B is independent to choose any source port, but destination port should be 8000.

From B's perspective, since it has published 9000 as its RTP port hence A must send RTP to B on port 9000 but A can choose any source port here.

Ideally in most of the implementations, SIP devices use the same port for sending what they have published for sending, but it is not restricted.

Coming back to your question, if the RTP from Cisco goes with source port as 1000 and destination port as 1500, this implicitly means that OP has published its RTP port as 1500. Now there should not be any issue when OP sends RTP from port 2000 but destination port should be what Cisco has published in SDP offer or answer as the case may be.

- Vivek

[iptsupport]

Hi, 

Thank you for the response .

"Coming back to your question, if the RTP from Cisco goes with source port as 1000 and destination port as 1500, this implicitly means that OP has published its RTP port as 1500. Now there should not be any issue when OP sends RTP from port 2000 but destination port should be what Cisco has published in SDP offer or answer as the case may be."

Is it possible that the destination port won't be what Cisco published ? 

[Ayodeji Okanlawon]

No that is not possible. During SDP negotiation, each part will publish a port that it is willing to accept RTP on. The destination port is where the other end wants to receive its RTP. You cant send RTP to a different port, otherwise the other end will not be able to listen to the RTP stream

[iptsupport]

Ok now I understand . Right now the issue is  the customer send  the RTP stream from another port I sent to , when he does that the calls drop. How can I troubleshoot this issue ? 

[Ayodeji Okanlawon]

Its very simple. Take a trace of the signalling using debug ccsip messages. Once audio is established do a " show voip rtp connection"

You can then see the ports that the customer is sending rtp to and compare to what you have during signalling setup.

[iptsupport]

During the call we hear silence.

I have some error in log ccsip.

Can anyone help me with errors?


LOG:


*Apr  7 08:35:51.430: //415530/91E81B24AC0F/SIP/Info/critical/1/sipSPIOutgoingCallSDP: Failure in creating outbound streams

*Apr  7 08:35:51.430: //415530/91E81B24AC0F/SIP/Info/critical/32768/ccsip_ipip_media_forking_update_preferred_codec: MF: Not a Forked SIP leg..
*Apr  7 08:35:51.430: //415530/91E81B24AC0F/SIP/Info/verbose/8192/sipSPICheckFAAnatAssymetricOrDO2EO: Not a SIP-SIP call or not in FA mode

[Ayodeji Okanlawon]

please post the full debug..

debug ccsip messages

show voip rtp connection

[iptsupport]

we added log in file .

[Ayodeji Okanlawon]

The logs look okay please do the following so we can look further. Is there IP connectivity between the devices? Ensure that the ip address used for media can be reachable by both devices

service sequence-numbers
service timestamps debug datetime localtime msec
logging buffered 10000000 debug
no logging console
no logging monitor
default logging rate-limit
default logging queue-limit

Then..

<Enable debugs, then test again.>

debug ccsip all

<Enable session capture to txt file in terminal program.> (such as Putty)

then do the ff:

terminal length 0
show logging