Sayan,
After sending an INVITE you need either a 200OK or 183 Session progress with
SDP to open your RTP ports and start receiving media. With out a response how
do you know if you are getting data from intended UA or not? I might be wrong
but my understanding of ready to receive media is to keep the port open for
media.
Regarding data coming from different IP Address, there is a section in RFC
3246 that states that its application signalling protocols job to authenticate
the UAs.
11 Security Considerations
There are numerous attacks possible if an attacker can modify offers
or answers in transit. Generally, these include diversion of media
streams (enabling eavesdropping), disabling of calls, and injection
of unwanted media streams. If a passive listener can construct fake
offers, and inject those into an exchange, similar attacks are
possible. Even if an attacker can simply observe offers and answers,
they can inject media streams into an existing conversation.
Offer/answer relies on transport within an application signaling
protocol, such as SIP. It also relies on that protocol for security
capabilities. Because of the attacks described above, that protocol
MUST provide a means for end-to-end authentication and integrity
protection of offers and answers. It SHOULD offer encryption of
bodies to prevent eavesdropping. However, media injection attacks
can alternatively be resolved through authenticated media exchange,
and therefore the encryption requirement is a SHOULD instead of a
MUST.
Replay attacks are also problematic. An attacker can replay an old
offer, perhaps one that had put media on hold, and thus disable media
streams in a conversation. Therefore, the application protocol MUST
provide a secure way to sequence offers and answers, and to detect
and reject old offers or answers.
Coming to recipient UA using different IP address and port to send media, I
can suggest a solution but I dont know how good it is. It is up for a debate
and i would be happy to see some one throwing some light on that.
RTP packets has a unique Sync Source ID in RTP header. If UAs can exchagne
this sync source id in SDP body in INVITE and 200OK. Once the media session
starts, decode RTP packets with matching Sync Source ID only and drop other
packets. you will know for sure you are decoding media only form the confirmed
UA.
Hope this helps.
-Sid
[EMAIL PROTECTED] wrote:
Hello Siddhardha/All ,
The offer answer RFC says that you should be ready to receive media as soon
as you send the offer.
That is where my doubt comes in ...
If I start receiving my media before any answer from the other side , how do
I know for sure that it's actually the intended called party who is sending me
the packets.
Also ,after I receive the answer if the called party plays the media from a
different IP address than the one he is using to receive media , how do I know
that it's actually the called party who is playing me the media , I looked into
SRTP , but that does not seem to have a solution for this ...
Regards ,
Sayan
---------------------------------
From: Siddhardha Garige [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 25, 2006 8:17 PM
To: Sayan Chowdhury (WT01 - IP-Multimedia Carrier & Ent Networks);
[email protected]
Subject: Re: [Sip-implementors] Query on when to open RTP ports during
offer/answer
Sayan,
Dont you have to wait for a response 183 or 200 OK before you open your RTP
ports?
Siddhardah
[EMAIL PROTECTED] wrote:
Hello All ,
Once I send an offer in in INVITE I am supposed to be ready to listen to
media.
However If I start getting media packets before getting the answer , I
do not know for sure whether the called
Party is playing me the media or somebody else is playing me the media.
What do I do in this case ? Should I be rejecting the media packets till
I get an answer ?
Also if the called party plays the media from a different IP address
from the one which he provides in the the SDP (for receiving media)how
can I be sure it's not some kind of attack on my UA ?
Regards ,
Sayan
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not the
intended recipient, you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately and destroy all copies of this message and
any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should
check this email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by this
email.
www.wipro.com
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
*******************************************************
Siddhardha N. Garige
Tampa, FL.
Ph: (813)-298-4236.
www.pbase.com/garige
*******************************************************
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates
starting at 1ยข/min.
*******************************************************
Siddhardha N. Garige
Tampa, FL.
Ph: (813)-298-4236.
www.pbase.com/garige
*******************************************************
---------------------------------
Feel free to call! Free PC-to-PC calls. Low rates on PC-to-Phone. Get Yahoo!
Messenger with Voice
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
