Subject: Re: RTP crosstalk; Re: [Megaco] Validating RTP stream

From: Shobhit Bansal <[email-masked]>
Date: Thu, 17 Aug 2006 01:14:23 +0530

Hi Albrecht,

There are three causes mentioned in the document H.248.RTPcrosstalk

The first two talk about avoiding any RTP termination to go in a hanging state so that they don't keep on generating the RTP when they should not be.

The third one actually talks about a solution as to how a termination can delay a situation of receiving two media streams. A waiting period can avoid situations where signal (megaco) processing is delayed but not those situations where a RTP termination is malfunctioning.

In my opinion there should be some way at the receiving side to validate or filter the media stream it is receiving like exchanging the ssrc value which will be part of the RTP stream.

Thanks and regards

Shobhit Bansal

Technical Leader

Flextronics Software Systems

[email-masked] wrote: -----

To: B Venkat S.R Swamy/HSS@HSS
From: [email-masked]
Date: 08/16/2006 07:12AM
cc: [email-masked]
Subject: Re: RTP crosstalk; Re: [Megaco] Validating RTP stream

In my opinion:

a) provisioning => Not possible.

b) implicit "signalling" by 'symmetry assumptions' => possible
[Note: this is then an underlying operations requirement for all RTP
equipment in such a RTP domain.]

c) explicit signalling, e.g. via gm package (gm properties saf, sam, spf,
spr) => possible
[Note: implies of course that the MGC has access on such information,
from call/session control signalling; or from a database in case of "static
configurations"]

- Albrecht

PS
Venkat: if you've still concerns/question, then I would appreciate
contributions against Draft ITU-T H.Sup.RTPXtalk.

"B Venkat S.R Swamy"
ftware.com>                    cc:      [email-masked]
Subject: Re: RTP crosstalk; Re: [Megaco] Validating RTP stream
16.08.2006 10:25

Hi

Regarding "Source address/port filtering", how does Session controller know
the RTP
source address/port to be used for filtering, since Remote Descriptor only
specifies what port remote is listening.
Is it a provisioning data or there is some other signalling mechansim.

regards
B Venkat S.R Swamy
Senior Technical Leader
Flextronics Software Systems
Phone: +91-124- 4176213
Fax: +91-124-4300247
web: www.flextronicssoftware.com
(Embedded image moved to file: pic09542.gif)[email-masked]

Albrecht.S
chwarz@alc
atel.de
(Embedded image moved to file:
pic26157.gif)
08/16/2006                                     To
01:13 PM              (Embedded image moved to
file: pic18290.gif)
Shobhit Bansal/HSS@HSS
(Embedded image moved to file:
pic02576.gif)
cc
(Embedded image moved to
file: pic14905.gif)
[email-masked]
(Embedded image moved to file:
pic04288.gif)
Subject
(Embedded image moved to
file: pic24019.gif)
RTP crosstalk; Re: [Megaco]
Validating RTP stream

(Embedded image moved to file:
pic03378.gif)
(Embedded image moved to file:
pic11584.gif)

Shobhit:

>1:
Depends on symmetrical or asymmetrical RTP/IP.
You cannot per se suppose symmetry.

>2:
via "source address/port filtering"

See e.g.
Draft H.248 Series Supp. X RTPXtalk (H.248.43 (ex. H.248.RTPXtalk))
Guidelines for Resource Management of Resources for H.248 RTP
Terminations

Note: this Supplement is particularly discussing "... malfunctioning
and keeps on generating RTP stream ...", called "RTP crosstalk".

ETSI H.248 gm package in ETSI TS 102 333
Work item on Draft H.248.gmgc

- Albrecht

Shobhit Bansal

[email-masked]

ftware.com>                           cc:

Subject:
[Megaco] Validating RTP stream

16.08.2006 01:27

Hi all,

I have some basic questions regarding the media streams.

Lets say we have an ephemeral termination with valid local descriptor (ip
addr 192.168.1.100, port 5004) and remote descriptor (ip addr 10.10.4.5,
port 6010).

1> I understand that remote descriptor means that the RTP going out will
have the destination ip address as 10.10.4.5 and port 6010 but can we
assume that the RTP stream that will be coming from the other end with have
the source ip as 10.10.4.5 and port 6010 ?

2> If not, is there a parameter by which we can confirm that the RTP stream
is valid or not. Consider a scenario where a termination is malfunctioning
and keeps on generating RTP stream towards this ephemeral. How can we
reject this RTP stream ?

Thanks and regards
Shobhit Bansal
Technical Leader
Flextronics Software Systems

*****FSS-Unclassified *****" DISCLAIMER: This message is proprietary to
Flextronics Software Systems Limited (FSS) and is intended solely for the
use of the individual to whom it is addressed. It may contain privileged or
confidential information and should not be circulated or used for any
purpose other than for what it is intended. If you have received this
message in error, please notify the originator immediately. If you are not
the intended recipient, you are notified that you are strictly prohibited
from using, copying, altering, or disclosing the contents of this message.
FSS accepts no responsibility for loss or damage arising from the use of
the information transmitted by this email including damage from virus."
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

*********************** FSS-Restricted ***********************
"DISCLAIMER: This message is proprietary to Flextronics Software
Systems Limited (FSS) and is intended solely for the use of the
individual to whom it is addressed. It may contain privileged or
confidential information and should not be circulated or used for
any purpose other than for what it is intended. If you have received
this message in error, please notify the originator immediately.
If you are not the intended recipient, you are notified that you are
strictly prohibited from using, copying, altering, or disclosing
the contents of this message. FSS accepts no responsibility for
loss or damage arising from the use of the information transmitted
by this email including damage from virus."
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

*****FSS-Unclassified ***** " DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 16 Aug 2006 16:03:58 -0400

It seems to me that this is an SDP problem, not an H.248 problem.
Remember that H.248 operates between the MGC and the MG.  The problem
you describe is a potential interworking problem between two end MGs.
H.248 is not directly involved here.
 
How is this potential issue solved by other SDP-dependent protocols?
Keep in mind that we CANNOT force symmetry here, as there are many
reasons why asymmetrical RTP streams could occur -- including having a
firewall in the middle or some other middlebox regulating traffic.
 
Kevin

________________________________

From: Shobhit Bansal [mailto:[email-masked]] 
Sent: Wednesday, August 16, 2006 3:44 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: RTP crosstalk; Re: [Megaco] Validating RTP stream

Hi Albrecht,
 
There are three causes mentioned in the document H.248.RTPcrosstalk
The first two talk about avoiding any RTP termination to go in a hanging
state so that they don't keep on generating the RTP when they should not
be.
The third one actually talks about a solution as to how a termination
can delay a situation of receiving two media streams. A waiting period
can avoid situations where signal (megaco) processing is delayed but not
those situations where a RTP termination is malfunctioning.
 
In my opinion there should be some way at the receiving side to validate
or filter the media stream it is receiving like exchanging the ssrc
value which will be part of the RTP stream.
 
Thanks and regards
Shobhit Bansal
Technical Leader
 
[email-masked] wrote: ----- 

	In my opinion: 

	b) implicit "signalling" by 'symmetry assumptions' => possible 
	  [Note: this is then an underlying operations requirement for
all RTP 
	equipment in such a RTP domain.] 
	
	c) explicit signalling, e.g. via gm package (gm properties saf,
sam, spf, 
	spr) => possible 
	  [Note: implies of course that the MGC has access on such
information, 
	from call/session control signalling; or from a database in case
of "static 
	configurations"] 
	
	- Albrecht 
	
	PS 
	Venkat: if you've still concerns/question, then I would
appreciate 
	contributions against Draft ITU-T H.Sup.RTPXtalk. 

	                     "B Venkat S.R Swamy"

	                     ftware.com>                    cc:
[email-masked]

	                                                    Subject: Re:
RTP crosstalk; Re: [Megaco] Validating RTP stream

	                     16.08.2006 10:25

	
	Hi 
	
	Regarding "Source address/port filtering", how does Session
controller know 
	the RTP 
	source address/port to be used for filtering, since Remote
Descriptor only 
	specifies what port remote is listening. 
	Is it a provisioning data or there is some other signalling
mechansim. 

	regards 
	B Venkat S.R Swamy 
	Senior Technical Leader 
	Flextronics Software Systems 
	Phone: +91-124- 4176213 
	Fax: +91-124-4300247 
	web: www.flextronicssoftware.com 
	(Embedded image moved to file:
pic09542.gif)[email-masked] 

	                        Albrecht.S

	                        chwarz@alc

	                        atel.de

	                                   (Embedded image moved to
file:         
	                                   pic26157.gif)

	                        08/16/2006
To 
	                        01:13 PM              (Embedded image
moved to     
	                                              file:
pic18290.gif)         
	                                              Shobhit
Bansal/HSS@HSS       
	                                   (Embedded image moved to
file:         
	                                   pic02576.gif)

cc 
	                                              (Embedded image
moved to     
	                                              file:
pic14905.gif)         
	                                              [email-masked]

	                                   (Embedded image moved to
file:         
	                                   pic04288.gif)

Subject 
	                                              (Embedded image
moved to     
	                                              file:
pic24019.gif)         
	                                              RTP crosstalk; Re:
[Megaco] 
	                                              Validating RTP
stream       

	                                   (Embedded image moved to
file:         
	                                   pic03378.gif)

	                                          (Embedded image moved
to file:   
	                                          pic11584.gif)

	

	
	
	See e.g. 
	    Draft H.248 Series Supp. X RTPXtalk (H.248.43 (ex.
H.248.RTPXtalk)) 
	    Guidelines for Resource Management of Resources for H.248
RTP 
	    Terminations 
	
	    Note: this Supplement is particularly discussing "...
malfunctioning 
	    and keeps on generating RTP stream ...", called "RTP
crosstalk". 

	- Albrecht 

	
	                    Shobhit Bansal 

	[email-masked] 
	
	                    ftware.com>                           cc: 

Subject: 
	
	                    16.08.2006 01:27 

	
	Hi all, 

	Lets say we have an ephemeral termination with valid local
descriptor (ip 
	addr 192.168.1.100, port 5004) and remote descriptor (ip addr
10.10.4.5, 
	port 6010). 
	
	1> I understand that remote descriptor means that the RTP going
out will 
	have the destination ip address as 10.10.4.5 and port 6010 but
can we 
	assume that the RTP stream that will be coming from the other
end with have 
	the source ip as 10.10.4.5 and port 6010 ? 
	
	2> If not, is there a parameter by which we can confirm that the
RTP stream 
	is valid or not. Consider a scenario where a termination is
malfunctioning 
	and keeps on generating RTP stream towards this ephemeral. How
can we 
	reject this RTP stream ? 
	
	Thanks and regards 
	Shobhit Bansal 
	Technical Leader 
	
	*****FSS-Unclassified *****" DISCLAIMER: This message is
proprietary to 
	Flextronics Software Systems Limited (FSS) and is intended
solely for the 
	use of the individual to whom it is addressed. It may contain
privileged or 
	confidential information and should not be circulated or used
for any 
	purpose other than for what it is intended. If you have received
this 
	message in error, please notify the originator immediately. If
you are not 
	the intended recipient, you are notified that you are strictly
prohibited 
	from using, copying, altering, or disclosing the contents of
this message. 
	FSS accepts no responsibility for loss or damage arising from
the use of 
	the information transmitted by this email including damage from
virus." 
	_______________________________________________ 
	Megaco mailing list 
	[email-masked] 
	https://www1.ietf.org/mailman/listinfo/megaco 

	

	confidential information and should not be circulated or used
for 
	any purpose other than for what it is intended. If you have
received 
	this message in error, please notify the originator immediately.

	If you are not the intended recipient, you are notified that you
are 
	strictly prohibited from using, copying, altering, or disclosing

	loss or damage arising from the use of the information
transmitted 

*****FSS-Unclassified ***** " DISCLAIMER: This message is proprietary to
Flextronics Software Systems Limited (FSS) and is intended solely for
the use of the individual to whom it is addressed. It may contain
privileged or confidential information and should not be circulated or
used for any purpose other than for what it is intended. If you have
received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified
that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. FSS accepts no responsibility
for loss or damage arising from the use of the information transmitted
by this email including damage from virus."