The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Jun> msg00406



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

RE:

  • From: Eric Gray <EGray@zaffire.com>
  • Date: Mon, 19 Jun 2000 09:15:58 -0700
  • Cc: "'MPLS Mailing List'" <mpls@UU.NET>



> -----Original Message-----
> From: Ramanjaneyulu Y T [mailto:ytr@csa.iisc.ernet.in]
> Sent: Friday, June 16, 2000 10:05 PM
> To: mpls@UU.NET
> Subject: 
> 
> 
> Respected all,
> 
>    At present we are developing voice over IP router with 
> MPLS and RSVP protocols. I got one doubt in that. 
> 
>       At edge routers (ingress, egress LSR) many phones (are)
> attached. When ever a user wants (to) talk to other party he
> /she rings number, SIP will verify other party is ready to 
> accept call or not . If it ready to accept RSVP will establish 
> path. This will (be the) same ... if multiple party (which 
> phones are attached to same edge) want to communicate to (the) 
> same destination edge. 

Whether or not RSVP signaling will be used on a per call
basis is a topic still very much in the air.  Many people
speaking/writing on this subject pretty much assume that
RSVP-like signaling will be used to establish trunks over
which multiple services will be carried.

> 
> Once path is (established) when conversation starts, voice 
> (packets start) coming to ingress LSR. Now (the problem) is how 
> to map IP addr. to MPLS (label) on  destination IP because more 
> than one destination RSVP paths established. 

This depends on the types of conversations established.  If 
this is a multiparty call, then packets from different sources
will need to be reassembled to produce voice information at a
destination independent of similar packets from other sources.
The result of re-assembling packets from several speakers should 
be no worse than the experience of hearing multiple speakers 
talking at the same time in a "normal" conversation.

Because the application needs to sort out packets per source,
there should be no problem with merging packets toward the
destination.

On the other hand, if there are multiple individual calls for
a given destination (or source and destination), then whatever
signaling is used to establish the individual calls needs to
allow the application at each end to easily demux packets for
each of the individual calls - e.g. - via different source or
destination port numbers.

Does this help?

> 
> 
> 
>                                                               
>                                          
>                                           With  Regards
>                                         Ramanajaneyulu Y.T. 
> 
>  "Everyone hears what you say. Friends listen to what you say. Best
>   friends listen to what you don't say."

Can't figure out if this is incredibly optimistic or just
mildly so.  Everyone within earshot MAY notice that you
are making noise.  Some of them, perhaps sharing a common
language and being close enough MAY recognize your words.
People who listen MAY hear what you say.  People who think
MAY infer what you don't say.

If you expect that:

	(friends <==> listeners) 

		and 

	(best friends <==> thinkers)

then perhaps you set standards for friends too high and
standards for everyone else too low... :-)

>   
> --------------------------------------------------------------
> ---------------- 
> Y.T.RAMANJANEYULU                        |   My other mail Ids:
> E-70,INDIAN INSTITUTE OF SCIENCE         |         ytr@rediffmail.com
> BANGALORE - 560012                       |         kingytr@excite.com
> PH: 0091 - 080 - 3092622 ( HOSTEL )      |
>     0091 - 080 - 3092906 ( LAB )         |
>                    visit my home page:www2.csa.iisc.ernet.in/~ytr
> --------------------------------------------------------------
> ------------------
> 
> 

Eric Gray